Question about using unitronics PLC as Modbus TCP Master/Slave

[Joe Tauser]

A little late to the party, but I have found that the ID of the TCP Master and TCP Slave don't matter.  Most of the time.

Technically, the Slave ID is part of the transmit and return packets so it should matter.  But I've had many instances of one Unitronics PLC talking to another where the Slave ID seems to be ignored; only the IP address matters.  So the Unitronics implementation of Modbus TCP doesn't seem to care.

I had one project where we were communicating with some Modbus TCP level sensors that allowed "chaining" of additional RS-485 slave sensors to the master Ethernet sensors.  The master acted as a gateway and each slave sensor did have a unique Slave ID.  The slave sensors could be accessed at the same IP as the master as long as you also specified the correct ID.  So it was multiple objects at the same IP address. 

So you can't totally disregard the slave ID, depending on the devices involved.

For some really interesting bedtime reading, the current Modbus TCP protocol specification can be found here-

https://modbus.org/docs/Modbus_Messaging_Implementation_Guide_V1_0b.pdf

If you look at page 5/46 you'll see that the 'slave address' is now the 'Unit Identifier' and is used in a gateway device such as I described above.  So if the device you're communicating with has some kind of hidden gateway or bridge functionality then the Slave ID does matter.

2 hours ago, Flex727 said:

There are so many different items that must be configured, and they must all be configured exactly right, and it's very easy to get a bit confused as to what's what. Even after hundreds of projects using MODBUS TCP I still have to stop and go through it all very carefully before it works perfectly.

That is exactly my experience.  You have to hook it up and test everything and not count on it working out of the box.  

I call this phase of the project "V'Ger wants to touch the Creator".

 

 

Joe T.

 

P. S. - If you look through the Official Specification you'll see that 32 bit objects such as Floating Point and Long Integers are nowhere to be found.  Which is why we have so many problems reading these from other devices - no mention of byte order or endianness.   There is no defined standard.

[Fernando Castro]

On 8/5/2022 at 6:35 PM, Joe Tauser said:

P. S. - If you look through the Official Specification you'll see that 32 bit objects such as Floating Point and Long Integers are nowhere to be found.  Which is why we have so many problems reading these from other devices - no mention of byte order or endianness.   There is no defined standard.

I know... haha I have struggled a lot with that part too... once I needed to transfer 8+ string characters on a single "package" basically 2 x 32 bits as a single 64 bit... and oh boy the other end (a data base open source software)  was modbus capable but there wasn't of course any 64bit  implementation.