Does Slave ID field have significance in MODBUS TCP

A

Thread Starter

Anonymous

Hi All,
In case of MODBUS TCP should the Slave ID be checked by a slave when it receives a frame? I am asking this question because in case of MODBUS TCP (unlike MODBUS Serial), the Slave is already addressed by the IP Address. In this case is the Slave ID field in the MODBUS frame ignorable? I have noticed that the MODBUS drivers of some HMI applications like Intellution FIX 32, Wonderware Intouch do not have any field to provide the Slave ID parameter but simply transmit '1' as the Slave ID.
 
M

Mark Hensley (Kepware)

The Slave ID plays a considerably important role in the Modbus TCP protocol. Simply ignoring could come at a high price in terms of system flexibility and general operation.

In purely Ethernet/(TCP/IP) terms the IP address of a Modbus TCP/IP device could be considered the actual address of the slave. The problem is that many new products are being developed that use the slave ID that is part of the Modbus TCP header. From a legacy standpoint, the Slave ID is in the same position relative to the function byte of standard Modbus RTU protocol. It is however still in the header and not the body of a Modbus TCP packet.

There are a couple of ways this internal Slave ID is being used in the market. First and foremost is its use in Modbus TCP to Modbus RTU bridge products like Schnieder's own gateway products. Like Schnieder's, there are many vendors that have created these gateway products. In each case they take a Modbus TCP packet, look at the internal Slave ID then they reformulate a new Modbus RTU packet that is sent out the serial port of the gateway to the intended target device. This is by far the most common usage you will see.

That's not to say that a device that supports Modbus TCP and does not act a gateway is ignoring this field. Many devices expect this field to be set to some value and in most cases it is 1. There are some newer devices that are also using this Slave ID to allow them to segregate data within a single device. In these cases the use of the Slave ID is needed to access different areas of memory within the same machine.

I know I said a lot when all that was needed was YES it's important.
 
L

Lynn at Alist

Yes it is very important for MASTERS/CLIENTS to generate properly (due to the MB/TCP -> MB+ or RTU bridge functions).

However, if you are creating a slave-only product, you should ignore it and not expect it to be any particular value. Do NOT force/require it to be zero or one!

For example:
1) the average MB/TCP OPC tool will send it as zero or one, but users can usually set it to any value they desire.

2) a Modbus serial master going through a bridge product will likely set it to match the RTU "slave" address used in the request - meaning if the Modbus/RTU master were polling you as Slave Address #7 (ie: the bridge looks into a mapping table at index #7 to find your IP), then the Unit ID will *MOST LIKELY* show up as 7 & 7 will be expected in the response. At least that is now the Schneider CEV, DigiOne-IA-RP, and LTX DR1-IAP all will behave, which represents the majority of products sold for this function.

Assuming you desire your MB/TCP slave to properly respond in all of these cases, just accept and echo the same Unit Id in the response. So if the
Unit Id comes as 0 or 1 or 7 or ??, just echo that in the response.

Best Regards

Lynn August Linse
IA Firmware Specialist, Digi Int'l (www.digi.com)
 
ID of SLAVE in headline very important. Because MASTER MODBUS TCP must send request to SLAVE MODBUS RS-485, through bridge.

Also, developer of SLAVE MODBUS TCP has a possibility install many logical nodes in one physical controller. This is good for change old SLAVE MODBUS serial network RS-485 on new one controller to integrate in MODBUS TCP.
Yan
[email protected]
http://www.fiord.com
 
The later versions of Intouch's I/O Servers do have a field called "Dest_Index or Unit_ID". The MBEnet version I'm using is 7,5,0,9.
 
L

Lynn at Alist

Most "first-generation" HMI/OPC drivers forced the Unit/Slave ID to zero (0). That is what early MB/TCP documents suggested. This zero works fine with PLC and direct TCP slaves, but causes problems when bridged to RTU or MB+.

Many "next-generation" HMI/OPC drivers used a trick with the IP, so you'd enter "192.168.1.23,12" or "192.168.1.23:12" for a Slave Id of 12. It's a bit ugly, but a very quick & bug-less way to 'add' user settable Unit/Slave Id with minimum driver changes or retesting needs. If your HMI app is smart enough to default the Unit/Slave ID to 1, then it clearly is NOT a first-generation effort and likely has some trick to change the Unit/Slave Id. Check the help files carefully.

Newer HMI/OPC drivers add an explicit field - it cuts down on tech support calls ;^] Most would have had this on the "to do" list for when ever they did a serious driver update.

Regards

Lynn August Linse IA Firmware Specialist, Digi Int'l (www.digi.com)
 
G

Gary Robertson

I have a question concerning serial to ip bridges.

Can a serial to ip bridge allow com between a serial master and a ip slave device using modbus protocol? If so, what device do you recommend using?

[email protected]
 
Top