PLC freezes temporarily

[k1w1]

Hi to all

Im having a problem with a control system we built for a bitumen sprayer. The trouble is that the system will freeze occasionally for about 0.5 to 1 second causing chaos on the spray run. The system uses two T100MDs connected in master/slave configuration via the RS485 connection. Both PLCs are fitted with  MX-RTC battery/data modules. The  Slave unit monitors bitumen pump speed and switches 10 selectable spray nozzles.  Master unit monitors ground speed, touch screen, and control switches, it also controls bitumen pump speed. It appears that some conflict is taking up all the master units time, when the fault occurs the numbers on the touch screen  also freeze. Both PLCs have  been replaced, but fault still happens. Could the MX-RTC module possibly cause this by being faulty or data storage full ?

Thanks for your time

[support]

It appears that there could be some problem in the RS485 communication between the master and the slave. When the master send the NETCMD$ command and the slave failed to respond properly it will retry 3 times and each time out is about 0.15s.  From your description the system seems to recover after a while. Is the slave using any EEPROM read/write command? These commands can affect communication from the master due to the interrupt being suspended and should be avoided during operation if the communication link is critical.

On the hardware side, are the master and the slave PLCs using the same power supply? If they are not then please tie the 0V of the two power supplies together to provide common ground signal. If the environment is noisy then you must use shielded twisted pair for RS485 bus.

For critical timing that cannot tolerate a temporary comm failure, you may want to shift the processing task to the slave. E.g. if there is a fixed spray time, let the slave hande the timing . The master can load the timing parameters into the slave before the spray begin but the critical tasks should be handled by the slave so that if there is a temporary comm failure the slave can continue to perform its task properly until the end of the cycle.

[k1w1]

What do you suggest is the best way to test RS485. The system has been working fine for about 2 years now but until 6 months ago it didn't have the MX -RTCs fitted. This may have been when the problem started but I,m not sure about that. I was informed that unless there is a lot of electrical noise due to the nature of the RS485  non twisted wires would be ok and up to now that seemed to be right. Shoud I run a temporary TP link. I'm making up 2 signal generators to substitute pump and ground speed ,as testing by spraying bitumen is not an option.

[support]

MX-RTC should not cause a problem since it's main purpose is to maintain the Real Time Clock and provide battery backup to data when power failure occur, unless the MX-RTC become faulty or lose connection. You mentioned that you changed the two PLCs but still face the same issue, did you re-use the MX-RTC?

Was there any changes to the PLC program before the problem started?

To confirm if it is due to comm failure or other problem, you can add in a test of the "Status(2)" after the master send a host link command or modbus command. Status(2) should return a "1" if successful and an "0" if communication failed. Then log the number of times the failure occur and maybe also either turn on an unused outputs or display on the LCD a message stating that comm failure encountered. When the stopping problem occur you can look at the LCD screen to determine if a comm failure had indeed taken place.

[k1w1]

Thanks will try that

[k1w1]

Back again, after testing RS485 wiring, ran temp cable between master and slave outside vehicle,  also tried with out MX RTC fitted, no improvement. The ground distance covered is also recorded and this appears to be inaccurate and erratic. I had a look at the program and I noticed that the ground speed signal ( around 100Hz at operating speed ) does not use the high speed counter. Could this be a problem ?

[support]

100Hz operating speed may be too high for non High Speed Counter input if the PLC has lots of time consuming custom functions (such as communication with slave). Do you mean you did not observe any bad communication between the master/slave and that the problem you faced does not appear to be related to the communication failure that I speculated?