MODBUS RTU and PLC address

[ccdubs]

Hello again.

I am having some difficulty using MODBUS RTU where I have 20 remote PLCs connected to a SCADA system running DAQFactory.

All comms works OK apart from the PLC's with addresses in the A to F range. It seems that when these PLC's are addressed for reading that all the others on the line also try and respond as if they all had the same address! This doesn't happen when polling the other PLC's.

Any ideas on why this may be?

[support]

Note that the address 0A to 0F is hexadecimal and on the scada they may expressed these in decimal (10 to 15).

I don't think the PLC who are not addressed tried to respond. You could try by connecting only to one PLC (say one with address 0A) and then try sending host link command using ID other than "@0A" and the PLC should not respond to the messages not specifically addressed to it.

[ccdubs]

Hi Support,

All the addresses entered in the SCADA are in decimal and I have queried the SCADA suppliers who have said it makes no difference as far as MODBUS is concerned. To prove this I monitored the port with HEX coding and the addresses being requested were 0A, etc.

The PLC's are all connected via radio, when I poll addresses 0D and 0E all PLC's try and respond. I can tell this by the transmit light on all the radios going on. If I disconnect a PLC from the radio, the transmit light no longer flashes when 0D or 0E are polled.

I will be talking to the radio supplier today but everything seems to be pointing to the PLC's. Under what conditions will a PLC force data down com1?

Many thanks.

[ccdubs]

I have since spoken to the radio supplier who is adament that the radio is just a transparent link. He did mention that some modbus devices allow group addressing. I haven't seen any mention of this in the TriPLC manual.

Is this something that may be causing the issue?

[ccdubs]

After much testing I have come to the following results which I hope make some sense to you.

It seems that the PLC is interpreting datagrams meant for addresses: 1,2,4,5,7,8,11,13,14 (DECIMAL) as something other than MODBUS. When any of these addresses are transmitted to, all PLC's try and respond. Address numbers higher than this seem to be unaffected.

If I force a PLC to only use MODBUS via the setprotocol command the PLC does not respond to any address request apart from its own. This may sound like a solution but I would like to be able to program the PLC's via radio and hence don't want to force MODBUS.

The above also holds when I try and communicate with a TriPLC rather than the SCADA package.

Do you have any idea why these address values seem to be problematic?

[support]

What character is being sent to the PLC? And what returned character did the PLC send? If the PLC receive a Ctrl-E (0x05) character it will always send back a 0x05 as a response because that is interpretted as the beginning of a point-to-point protocol.

You could use the SETPROTOCOl to fix the PLC's protocol for MODBUS when you want to use MODBUS, and then you could use an internal relay to trigger another custom function to switch it back to native protocol or automatic protocol when you want to use TRiLOGI to program the PLC. The PLC can be forced back to Fixed MODBUS RTU using another internal relay. That way it is possible to change the protocol that the PLC supports by forcing the corresponding internal relay.

[ccdubs]

What do you mean by "what character is being sent to the PLC?". As far as I know all I am sending is a typical MODBUS RTU readholding register command. With a typical format of: \x0D\x03\x04\x4C\x00\x0A\x05\xE6. This is as monitored on the tx port of the PC in HEX. I note that there is a x05 charecter in this string and according to the T100MD manual and what it shows as the MODUBS RTU structure this would be the 1st byte of the CRC. This may explain why certain addresses are problematic as the rest of the datagram is the same for all other PLC's.

FYI, the response from the PLC's when "faulted" was 005.

Does this mean that if I was to send a MODBUS set function and transmit a value of 5 to the PLC that the PLC will interpret the communication as something other than modbus?

[support]

When the PLC is in Auto protocol mode it does not know what incoming communication protocol to expect  and it will guess the incoming protocol.  The first time it receive a partial MODBUS message that contains 0x05 it doesn't know that it is going to receive an RTU Protocol, so it will echo a 0x05 when it sees a 0x05 among the incoming characters since this is necessary to respond to native point-to-point protocvol.

Only when the PLC has successfully received a complete MODBUS RTU message then it knows that it is communicating in MODBUS RTU protocol, so will temporarily fix itself in RTU protocol mode and will not echo the 0x05 characters from then ON. So this might result in a comm failure to the RTU master for the first message received, but a repeat send by the RTU master will be responded to properly. This is a trade off to pay when using the PLC in auto protocol sensing mode. Thus for application where you know for sure only the RTU protocol is to be used it is always better to fix the protocol using the SETPROTOCOL command.  As mentioned in previous post you can use SETPROTOCOL to change the protocol from one type to another repeatedly.

[ccdubs]

Thanks Support.

I have written some code that sets the protocol from MODBUS (default as set on 1stScan) to AUTO when a certain MODBUS code is sent. This then times out back to MODBUS after 5 mins.

It works well and is a good solution that has made the comms far more robust.

Thanks