MODBUS -> wire failure -> PLC reaction

Hello forum.

I'm running into a problem with my PLC-controlled system. I'm using AD DL-06 as the main PLC with another DL-06 as the remote PLC. The remote PLC on the carriage takes input from the operator and sets the coils on the solenoids. The main PLC on the non-moving part handles a similar interface and turns on the motors.

It's transporting people and thus has to be failsafe. There's a separate set of redundant safety Grade 3 controllers that take care of collisions. The system requires power from the estop relay to function.

The communication between the two PLCs is done with RS-485. The problem is that if that wire breaks, tests show that the PLCs continue along with the last received instruction. For example, if I press "go forward" and unplug the cable, it runs along as though I was still holding the button. How can I fix this? My options are to directly wire everything, but that will be impractical at best - with the communication wire I can cut down the umbilical cord from 20+ wires down to 4, making the wiring much easier and cheaper.

I've tried resetting the coils on each pass, but they end up just staying off all the time due to the lag in reading and writing over a serial line.

A heartbeat detection system seems incorrect - the system should stop if a wire breaks, not react to the broken wire and shut something down actively.

I can't post my code; not only is there an NDA, but it's thousands of lines. What I'd like is a general solution idea or any suggestions; I should be able to work out the details.

Thank you.

I'm guessing only one PLC communicates. reads and writes to the other.

SP113 On when port 1 has an error
SP115 On when port 2 has an error
one of these bits could stop the 'master' (depending on the port)
2 more wires would give you an output that would go away on a COM failure to the other PLC.

as far as a heartbeat. sending a bit with every transmission and clearing it you should be able to dectect and stop everything in a few tranmission cycles.
If you are constantly transmitting the detection time should be very short.

I can't tell without seeing your code, but it sounds like you are directly manipulating the outputs on the slave PLC. I don't remember when the communications are serviced, but if it is just prior to scanning the ladder, resetting the coils every scan _would_ have forced them off (remember, last one out wins.) Instead of resetting the coils every scan, why not condition the resets with a timer that is always active? The master PLC would keep resetting the timer's accumulated value to 0. If the master for whatever reason stops resetting the timer's accumulator, the timer times out (could be as short as .5 second depending on the particulars of your setup, maybe shorter) and all of the outputs are reset based on the timer's done bit. This would be called a watchdog type setup. The PLC has a similar setup for watching to make sure the ladder is scanned in a timely manner and does not hang.

I don't really see any way around using a heartbeat/watchdog type setup. If you are relying on a comm link, the only way to tell when that link has gone down (from the slave's point-of-view anyway) is to incorporate link diagnostics in your program.

Another thought...
Are you sending updates on an event basis or a timed basis? In other words, do you only send a message to the slave PLC when, say, a button is pressed or released? Or do you constantly send information? A watchdog system would be easiest to implement in a comm system that was updated on a timed basis.

Brian