Well then, thanks to @kclenden too! And, thanks to @Guy Lavoie and @paulbates who helped get the ball rolling.

The time frame of that errant code insertion, does match up with the observed faulting issue, so good circumstantial evidence.

I'm going to sit with just the few devices I have restored for now, and confirm that they stay fully working -- a day should do it. There are only 32 PLM table entries right now, so easy to download/compare.

If no further resets/issues, will do a full PLM restore, and as you suggest, follow that up with a DEVICE RESTORE on each device, for good measure!

Thanks again.

And, will report back.

Orest

Edited 9 hours ago9 hr by oskrypuch

35 minutes ago, oskrypuch said:

Well then, thanks to @kclenden too! And, thanks to @Guy Lavoie who helped get the ball rolling.

The time frame of that errant code insertion, does match up with the observed faulting issue, so good circumstantial evidence.

I'm going to sit with just the few devices I have restored for now, and confirm that they stay fully working -- a day should do it. There are only 32 PLM table entries right now, so easy to download/compare.

If no further resets/issues, will do a full PLM restore, and as you suggest, follow that up with a DEVICE RESTORE on each device, for good measure!

Thanks again.

And, will report back.

Orest

@oskrypuch , hope it helps. Please do report back. As I said, this is the 1st time I've seen this. Likely will not be the last.

And, I'll keep the device event viewer/log rolling for now.

Orest

Edited 9 hours ago9 hr by oskrypuch

Oh yes, looking forward to the conclusion on this. Kind of surprised that you can get communications errors between the Polisy and the PLM. I'd venture that it's more about message timing or buffering than actual comms, since serial or USB ports aren't a collision domain.