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.
