Modbus RTU comm issue

[Bill]

I am having a communication problem between HMI and MD1616 PLC when monitoring online and using the HMI simultaneously.

I suspected the issue is caused by data collision resulting from the presence of two masters trying to poll the PLC at the same time on RS485 line, the PC and the HMI.

My setup is:

1. MD1616 sending data to VFD over RS485, through Com3 of PLC, Modbus RTU.
2. HMI reading and writing to memory registers in PLC, Modbus RTU through com1 of PLC RS232.
3. PC using online monitor through PC com port using Auto 485.

There is no problem until I press the HMI screen to set the motor in motion. I loose comms between HMI and PLC. Only by closing the PC com port in TLserver does communication restore.

Thanks for any input

[support]

If you program the PLC to send command out of COMM3 to the VFD, that means that that comm port can no longer be used for communication with the TRiLOGI software. This is because when the PC send a command string to the PLC's COMM3, it expects a correctly formatted response string to be returned by the PLC. If during this time the PLC happens to send data to the VFD the data will be received by both the VFD as well as the PC and therefore it is considered a corrupted response data and the communication broke.

You may want to program an input to control the PLC so that the PLC will only send data to the VFD when the control input is turned ON (or OFF, which ever way you prefer). When you want to perform online monitoring, turn OFF the input so that the PLC stop sending data to the VFD and now you will be able to perform online monitoring properly.

[Bill]

Thanks for your reply.

Would this corrupted data on com 3 also affect com 1 on the PLC?

If I disable the message being sent to VFD the process will be interrupted. I recall reading about the NETCMD$ function to manage communication between several PLC. Will this function work for other devices as well?

Thanks

[support]

Corrupted data on COMM3 shouldn't affect COMM1 on the PLC unless the PLC is locked within a dead loop controlled by GOTO statement (in order to rectify the VFD communication failure issue), then the CPU does not spend time servicing the serial port and that could lead to failure on COMM1.

Are you using stepper motor? What's the stepping rate? When stepper motor is in action it actually would send out a XON/XOFF handshake via COMM1 which is normally connected to the PC. This inform the TRiLOGI that the stepper motor is in action and to reduce the communication loading on the PLC in order reduce the effect on stepper motor output waveform at high stepping rate. This may however confuse the MODBUS master and cause the communication to drop.

If that the case, it would be better to connect the PC/TLServer to the PLC via COMM1 and connect the HMI to the PLC via COMM3.

As for the VFD, this is more difficult to solve on a T100MD+ PLC since you have both comm ports already controlled by two masters where the PLC could not tell them to temporarily stop sending commands (except to actually switch out their communication  by relay controlled by a digital output) so that the PLC can send data to the VFD. The easiest solution would be to use the T100MX-3224R+ PLC insead. This model has a second RS232 port which can be connected to the VFD up to 9600 bps, 8,n, 1.

[Bill]

Thanks for your reply. I will check with customer to get approval to purchase suggested hardware.