Host Engineering Forum

General Category => Do-more CPUs and Do-more Designer Software => Topic started by: RBPLC on September 30, 2022, 07:22:21 AM

Title: Error Message Time Stamp
Post by: RBPLC on September 30, 2022, 07:22:21 AM
Is there a timestamp anywhere within DmD associated with error messages generated within System Information?
Title: Re: Error Message Time Stamp
Post by: BobO on September 30, 2022, 08:34:50 AM
Is there a timestamp anywhere within DmD associated with error messages generated within System Information?

Only if they are also logged.
Title: Re: Error Message Time Stamp
Post by: RBPLC on October 03, 2022, 08:25:15 AM
I haven't looked through the documentation yet but is there an easy way to log these errors? I'm mainly getting a "random" EIPMSG failure.
Title: Re: Error Message Time Stamp
Post by: BobO on October 03, 2022, 09:56:45 AM
I haven't looked through the documentation yet but is there an easy way to log these errors? I'm mainly getting a "random" EIPMSG failure.

Every time there is a comm failure, the "On Error" bit or stage will activate. Use that to trigger logic immediately after the EIPMSG instruction to store ERR and $LastError1 somewhere. At that moment, those should contain something useful. If you want a list of them with timestamps, store in a FIFO.
Title: Re: Error Message Time Stamp
Post by: RBPLC on October 06, 2022, 08:03:16 AM
I suspect there's still something in the comms stack that's not quite right (I'm referring to the same Modbus/EIP comms issue that was identified some time ago). I have 1 BRX master communicating with 2 BRX slaves over EIP. I started getting random/not persistent comms errors with one of the slaves. Then last week, I had full blown persistent comms failures with one slave. I power cycled both slaves and comms were not restored. I power cycled the master and comms came back immediately. I've got a process running and didn't have time to really troubleshoot.
Title: Re: Error Message Time Stamp
Post by: BobO on October 06, 2022, 11:36:27 AM
I suspect there's still something in the comms stack that's not quite right (I'm referring to the same Modbus/EIP comms issue that was identified some time ago). I have 1 BRX master communicating with 2 BRX slaves over EIP. I started getting random/not persistent comms errors with one of the slaves. Then last week, I had full blown persistent comms failures with one slave. I power cycled both slaves and comms were not restored. I power cycled the master and comms came back immediately. I've got a process running and didn't have time to really troubleshoot.

I don't know of any issue with masters of any variety, at least not since 2.9.x. There was definitely an issue in TCP-based masters in 2.8.x.

The only outstanding issue we know about right now is two users have had issues with Modbus/TCP server (slave). Both use radios, and it appears to be a really narrow problem related to network instability.