News:

  • August 15, 2026, 05:20:34 AM

Login with username, password and session length

Author Topic: COMM error  (Read 6077 times)

davidbgtx

  • Hero Member
  • *****
  • Posts: 215
  • Host be the Most
COMM error
« 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
« Last Edit: September 12, 2019, 12:34:22 PM by davidbgtx »

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 6170
  • Yes Pinky, Do-more will control the world!
Re: COMM error
« Reply #1 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.
"It has recently come to our attention that users spend 95% of their time using 5% of the available features. That might be relevant." -BobO

davidbgtx

  • Hero Member
  • *****
  • Posts: 215
  • Host be the Most
Re: COMM error
« Reply #2 on: September 18, 2019, 09:20:08 AM »
No more problems after swapping out the CPU