Modbus Communication problem

[ssingh]

Hi There

I have strange problem.
We are using 8 T100MD1616+ PLC all connected on the RS485(comm 3).
Each of these PLC's has a Barcode scanner on Comm #1.

Initially we used a PC issuing native host-link commands on the 485 network to access the required data from each PLC. This worked fine for 2 year but proved very slow as the amount of data required increased quite substantially.

We therefore decided we needed to use the modbus ASCII protocol as this will allow us to access data in blocks.

We designed our own Modbus OLE server issuing modbus ASCII commands to all devices on the network.
The server issues each command using the modbus 03 function to read the modbus holding registers 40001-40030 and 41001-41030 with a block length of 30.
The timeout is set to 1 second, the time between reties is set to 0.5 second.

All works fine except for one thing, when use the barcode scanners connected on comm #1 we sometimes receive erroneous data.
There is nothing wrong with the barcode scanners. We are experiencing the same problem with all PLC's on the network.

On examining the data received on comm#1 we discovered that part of response frame to the modbus command from another PLC was present in comm#1 buffer. This seems to be happening on all the plc's.
Originally we thought the OLE Modbus server was issuing modbus commands requesting too big block length, this was reduced to a length of 30 (e.g. read 30 registers with each 03 function command).But this still did not correct the problem.

Do you any explanation how data arriving on comm#3 can also find its way to comm#1 buffer. Is there an overlap in the buffer/memory map.

Please suggeset a possible cause and cure to this problem.

Regards
Satpal Singh
Systems Engineer

[support]

Thank you for the very detailed description of the problem you have encountered. That make it easier for us to try to understand what was going on and I think you may have stumbled upon a condition that we did not anticipate.

The PLC employs a separate ASCII command buffer from the 256 ring buffer that are used to keep incoming characters. That way it can process the incoming commands while still let those command characters be available for the reading by INPUT$(n) command. However, the ASCII command buffer only has a length of 80 characters while response buffer has 256 bytes.
This mean that the PLC can accept incoming ASCII command of no more than 80 characters but can send response longer than 80 characters. This is normally not a problem if there is only one PLC connected to the PC.

However, in a network environment as in your case, the response string from other PLCs are also received by the incoming command buffer and if the string is longer than 80 bytes that means that it overflows the incoming ASCII command buffer. Ideally the firmware should check the character count and stop accepting characters once more than 80 characters has been received. Unfortunately this was not done and the incoming ASCII command buffer for COMM3 happens to occupy ajacent memory prior to the 256 byte ring buffer for COMM1, so when incoming command buffer for COMM3 overflow it writes into the COMM1 ring buffer. That's why you start seeing "ghost remains" of those response strings by other PLCs.

If you don't use the COMM1 data this would not be problem but in this case you need to read scanner data on COMM1 and that's why you see this problem.

For now I can think of few ways to tackle this situation:

1) To ensure that the total number of response ASCII strings is no more than 80 characters. Since each 16-bit register you read occupies 4 bytes, hence you have to limit the amount of registers read in you MODBUS 03 command so that the total number of response string including the header, LCS and CR-LF does not exceed 80 characters.

2) Alternatively, you could clear up the comm1 buffer by performing an INCOMM(1) until no more characters is received before you trigger the bar code scanner to receive ASCII characters.

3) Use the MODBUS RTU protocol instead of ASCII. Modbus RTU does not use the ASCII command buffer and that would not have the same problem. If ?you do use MODBUS RTU, you should execute PMON 1 to enable a system timer overflow interrupt to increase the reliability of th MODBUS RTU.

We have reported this observation to our development personnel and future firmware release will likely to include an overflow check on the incoming ASCII commands to stop accepting ASCII command beyond 80 characters in order to tackle this uncommon problem.