Today is...
Tuesday, September 24, 2019
Welcome to Control.com, the global online
community of automation professionals.
Featured Video...
Featured Video
A demonstration of EtherCAT control of linear motors using the CTC EtherCAT master.
Our Advertisers
Help keep our servers running...
Patronize our advertisers!
Visit our Post Archive
Modbus Communication Issue
PLC and weighing indicator communicate with Modbus. Once a while, the communication is jammed. Require to restart the indicator.

Hi all,

I have a system which using Panasonic PLC, FP0R to read 3 weighing indicators via Modbus and display back the reading in PC monitor. In the system, I am using a receive command to send to indicator, then indicator will feedback the weighing reading to PLC.

According to user, once in a while the reading that is display on the screen is jamming, the reading in the screen is not updating compare to the one in indicator.

The PLC comes with auto COM Port reset in certain time frame (according to programmer setting). I had set to 40ms but even PLC had reset the port, the reading is still not updating in the PLC.

May I know for Modbus, if master (PLC) did not receive any feedback from indicator, it will just treat it as success and jump to next step?

Further information:

The communication is using shielded cable. the looping length is not more than 2m.

Weighing indicator manufacturer suggest to remove termination resistor in the indicator since the communication length is short but I wondering does this really help.

Does anyone have any advice for me on this issue?

1 out of 1 members thought this post was helpful...

I'm not sure, from your description, which device reads and which device writes or whether you've gotten the network to operate normally at some point.

I'm not sure what 'auto COM port reset' is, but that sounds like something that shouldn't need messing with, once things are running, at least not something occurring every 40mS.

The 'jamming' is due to stale, out-of-date, old data. A Modbus master/client reads a value from a slave/server device and puts it somewhere in the master/client's memory. It might write the value to slave/server.

If the Modbus master/client cannot read from the slave for any reason, the old, 'stale', out-of-date data remains in the master's memory. I have seen trend data of slave data that flat-lines - at some point in time the slave/server went off-line and the master could not read from it. So the data shown for that device is the same old, stale, out-of-date data value, over and over and over, which looks like a flat line when displayed in a trend chart.

If that data gets written to another device, it's the old data that get written because there is no new, updated value to write, because the read operation that is supposed to get new data has failed.

Stale data is not uncommon in battery powered wireless slaves when the battery dies.
Stale data is not uncommon when a device is replaced and not configured properly, like the wrong Modbus slave address.
Stale data is not uncommon when a device is disconnected for service and is not re-connected properly.
Stale data sometimes happens when the slave's firmware chokes for some reason and a power cycle is needed to restore slave operation.

As to what the Modbus master does when it fails to 'receive any feedback' (meaning get a reply/response to its Modbus query/poll), there is always a 'time-out' setting value in the master, so that if there is no valid reply received from the slave within the timing period, then the master 'times out' and does whatever it is programmed to do on time-out, which could be retry, flag an error, or quit and go to the next step. Otherwise, it would get stuck waiting forever for an reply that might not ever come.

Many slaves have slow Modbus routines and might take 10's or even hundreds of milliseconds to reply/respond. If I had a stale data situation I'd try increasing time-out period to see if that solves the issue.

If the master reads data correctly at some point, then that's 'normal operation'. It would be an unusual for a terminating resistor to allow normal operation sometimes and not-normal operation (fail to reply) at other times. If the master manages to read data for a period of time, that's normal operation and a terminating resistor is not likely the problem. At 2 meter's cable length and 19.2k baud rate, having or removing the terminating resistor is not likely to change anything, so give it a try.