Host Engineering Forum

General Category => Do-more CPUs and Do-more Designer Software => Topic started by: davidbgtx on September 12, 2019, 08:22:05 AM

Title: COMM error
Post by: davidbgtx on September 12, 2019, 08:22:05 AM
Recently a Do-More DM1E has been dropping out of run mode. Can't remember the first error but it stated most likely a slave offline. So I set all 3 slaves to
CPU remains in Run on slave error
Slave must be online to enter run Mode
Hold Last State
Timeout 5000
Retries 10

Each slave goes to an individual oven and if 1 slave faulted/lost comm whatever, didn't want cpu to stop and all 3 ovens halt
Sooo last night the error was st143,st146,st145, cpu still in run when I arrived this morning, but my ovens had halted. Could the CPU drop out of run and then restart??  Divide by zero is non-critical error, correct?? This unit operated with no issues for a month, so I believe my settings are correct.
Swapped out CPU this morning, can't afford for my ovens to halting
Title: Re: COMM error
Post by: BobO on September 12, 2019, 12:54:28 PM
ST145 and ST146 are the clue.

There are a couple of possibilities:
1. There is so much comm traffic on the PLC's network that it is unable to keep up processing, and has overrun the IP stack's packet queues. This is probably bursts of broadcast traffic. We see switches do dumb things occasionally, like rapid bursts of gratuitous ARPs. We've also seen cameras broadcast a lot. Scan time affects the PLC's ability to process these, so it could be a combination.
2. You have created one or more UDP or TCP devices and something is sending traffic to the them, but the PLC program isn't processing them. This can eat the queues.

Unless you are doing any custom protocols, it is likely #1.

The first best answer is to prevent that kind of traffic. We do our best to handle it, but we have still seen occasions where a perfect (packet) storm can cause the IP stack some heartburn. If we can get details on how to dupe it, we're happy to try to harden things up further.

Barring elimination of offending traffic, if the PLC can tolerate a reboot, you could add some code to check the state of the remote slaves and if all of them stay logged out for too long, do the REBOOT command from the PLC. Be careful that you write the code in a way that the PLC don't get trapped in a reboot loop...be sure you clear the timer/counter/delay trigger before issuing the REBOOT.
Title: Re: COMM error
Post by: davidbgtx on September 18, 2019, 09:20:08 AM
No more problems after swapping out the CPU