Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: Henryp on November 05, 2018, 07:12:49 PM
-
I'm getting a Modbus Exception Response Code of 08 Memory Parity Error on most if not all of the DM PLCs at my plant. Am I asking for too many registers at once? What are the max numbers of registers that can be read from a DM at once and what are the max number of digitals that can be read at once?
-
Between PLC's or other devices talking to the PLC's? is there any supervisory control for the com's or is it every PLC for himself? Assuming this Modbus TCP/IP?
-
This sounds familiar. If I'm remembering correctly, we had something that was returning the wrong exception code. I think it has been fixed. Let me see If I can get someone with more knowledge to answer here.
-
I know that poling from PLC more than 125 registers via modbus tcp will cause my BRX to freeze up for a minute or so. I don't remember if there was an exception code. I quickly stopped doing that.
-
I know that poling from PLC more than 125 registers via modbus tcp will cause my BRX to freeze up for a minute or so. I don't remember if there was an exception code. I quickly stopped doing that.
That is over the protocol limit, but the controller rebooting was a bug. It's already fixed and will be in the next release.
-
I'm getting a Modbus Exception Response Code of 08 Memory Parity Error on most if not all of the DM PLCs at my plant. Am I asking for too many registers at once? What are the max numbers of registers that can be read from a DM at once and what are the max number of digitals that can be read at once?
Are all these Do-more PLCs talking to an MB-GATEWAY? If so, if you asked for an address that was out of range, the MB-GATEWAY would incorrectly report a 08 Memory Parity Error instead of a 02 Illegal Data Address. This was corrected in MB-GATEWAY firmware v1.0.681 (03-Nov-2017).
-
I know that poling from PLC more than 125 registers via modbus tcp will cause my BRX to freeze up for a minute or so. I don't remember if there was an exception code. I quickly stopped doing that.
That is over the protocol limit, but the controller rebooting was a bug. It's already fixed and will be in the next release.
Does this bug also affect the T1H-DM1E cpu's causing reboots?
-
Does this bug also affect the T1H-DM1E cpu's causing reboots?
Yes. Modbus/TCP does have an issue where a non-standard oversized request can cause the PLC to reboot. We just learned about it a few weeks ago (it's been there since 2012) and it's already fixed and will be part of our next release. I haven't confirmed that all three platforms fail, but the code is the same, so yes I expect that T1H could do it as well.
-
Any eta on the fix, I believe that we may have few cpu's suffering from this that we have not been able to figure out why they occasionally reboot.
-
Any eta on the fix, I believe that we may have few cpu's suffering from this that we have not been able to figure out why they occasionally reboot.
This bug isn't random. It's very repeatable. If fails instantly in response to an invalid Modbus/TCP request. If you don't have devices sending these requests to the PLC, then that isn't your issue.
-
I had one reboot a couple days ago with DST385 incremented and this attached message, could it be related?
-
I had one reboot a couple days ago with DST385 incremented and this attached message, could it be related?
No. As BobO indicated, the failure he's talking about fails 100% of the time when you do it.
"Illegal data in response" sounds more like data corruption (noise). Is this over Modbus TCP on the T1H-DM1E? Or Modbus RTU over its serial port? Is this still with that system we were troubleshooting a year ago where I was guessing the PLC was exposed to radiated noise and/or X-rays? Can you get a Wireshark trace that captures the failure? (That may be very difficult to catch especially if it is random and a one-off kinda thing).
-
This is a brand new system in the lab with no field I/O connected yet, no radiation and no xray's. This is similar setup to the one I was having trouble with. The write was a RTU write to an other DoMore PLC. The data in that write would come from moving bits using the mover box and come from ladder rungs and from a Cmore data some of which is modbus coils. My thought was if you have noise and it corrupts the data could it randomly corrupt the number of coils or registers asked for and cause the crash? We just had 7 large plc cabinets built and are starting work on the programming and have had a few reboots on these and I am getting worried because we are not sure of what is causing it. I had though our other systems issue were power related but these new cabinets are in a different building on different power, we have 6 T1H-DM1E powered up right now on the same power and have had 3 reboot in the last few weeks, and not at the same time or days. This seems to happen at random, we though we had the other system fixed as it ran for 4 months without a hiccup and then started to reboot once or twice a week and is now has been running again with no issues for the last month or so. I have a new inquiry in right now and will be providing more info via email. Just about an hour ago I had one of the three plc's in the cabinet drop it's ethernet connection to Do more and the HMI but it was still running ladder code, is there any debug info that can be dumped from these PLC's that would help trace this?
-
I don't know of any RTU transaction that would crash it. Doesn't mean it can't happen though. The error you showed is definitely garbage data, but that shouldn't be a problem at the RTU level.
The TCP failure is actually not related the Modbus request itself, it's that the TCP header length was not being validated, and when an client sends a request that is longer than permitted by the protocol, it can cause a buffer overrun. It only affected Modbus/TCP, not RTU.
Are the Ethernet ports connected to a higher level network? If so, is it possible that there is some rogue data getting on that? It really is impossible to test for every possible network condition, since network content is constantly changing. We don't know of anything that might crash it (other than the Modbus thing) but we're always listening for new things that might show up.
As for debugging, yes. The contents of DST400-409 can be helpful following a reboot. It's a push down stack of the last 5 power cycles, so the regs get lost over time.
-
Yes we are on a much larger network that is in a state of transition right now and a lot of new device testing is going on, it is certainly possible for garbage data to get in. We will transition to a locked down subnet once we are done commissioning. Attached is a pic of a data view showing DST400-409. Looking at the syslog it looks like only one power cycle after the watchdog reboot and that was to get the ethernet port going again.
-
That all looks fine. Mostly that just allows me to see the system initialization, but I wanted to make sure there was nothing weird there.
$DebugTrapAddr (DST411) might also shed light.
-
DST411 shows ???? in the data view window, how do you properly view the contents? The PLC rebooted itself twice over the weekend as well DST400-DST409 now is full of the same pattern repeating 806 followed by 1075183616 repeating 5 times now.
-
DST411 can show the address that caused an exception. The value may or may not be useful depending on what happened. If it is constantly the same value, that can indicate a specific firmware bug and can be very useful. If it is a different value, or not set at all, that could point to a random failure like noise or some kind of comm fault.
There are other diagnostics we can do, but they require custom firmware builds. It may be prudent to continue this discussion via email. Give us a shout at support@hosteng.com.