Hello all,

I am curious what the ModbusTCP standard is when dealing with multiple masters polling one device.

What I have is a device that allows me to create multiple ModbusTCP servers (slaves), for each server (slave) I configure I have to also configure the IP address of the client (master) that will be polling the server (slave). This way each client (master) sees a slightly different ModbusTCP server (slave).

For example, for each ModbusTCP server I create a map of points and configure the IP address of its client. I can do this for as many servers as I want to create and all of this is supposed to happen through port 502.

I am running into some issues where the data destined for one server end up getting passed to the wrong server. I can remedy this by configuring the first server for port 502 and then the rest of the subsequent servers for port 1024, 1025, etc.

Is the ModbusTCP standard designed such that I should be able to have all of the data filtered by IP address through port 502 or is it common practice to use a different port for each ModbusTCP server?

Thank you for the help.

 

Hello,

You forgot about the slave ID in the message.

If you have one server listening on port 502 with one IP address then the only way it can route to different internal register sets is via the slave ID.

If the server has multiple IP addresses and listens on port 502 for each address then you have separation and the slave ID might not be an issue

Good luck,
Mark
http://www.peakhmi.com/

 

Default port according to specification is 502.

Some applications may dictate multiple servers running at the same IP.

You can have multiple servers running on different ports, but both client and server need the capability to specify alternate ports. So a client that strictly adheres to the standard may not be able to see the servers at alternate ports.

Unit ID is another workaround, but its intended use is for gateways.

Automated Solutions' master and slave products all allow alternate port selection.

-Mark
http://automatedsolutions.com

 

The Modbus/TCP spec doesn't define how ports and addresses are handled. The TCP/IP spec covers that. The Modbus/TCP spec just covers what the message looks like and how to decode it when it's received. It's up to TCP/IP to actually deliver it.

If your device has some sort of custom TCP/IP stack with non-standard behaviour, there is no real way for me to tell how it works. However, I would normally expect connections to the same port to go to the same instance of the software. That's how a lot of redundant servers work.

There is nothing to prevent you from running Modbus/TCP on any port you want, provided the software at each end will allow you to set the port number. I do that all the time with my own software.

However, the most common way of dealing with this seems to be to use the "unit id" (which Mark referred to as the "slave ID"). In RS-485 versions of Modbus this is used as the server (slave) address. Since TCP/IP takes care of that in Modbus/TCP, it doesn't have a direct role in delivering messages (however, it is used in Ethernet to serial converters).

Some software however will look at the unit ID and use that as a data table selector or offset to provide a larger effective register address range. That is, unit ID 1 will address one block of memory, unit id 2 will address another block, etc.

I have a program called MBLogic which does this to provide a larger number of holding registers (1 million actually). It does basically what you describe (multiple clients plus a server in one program), but the server also looks at the unit id and uses that to calculate an offset in the 1 million holding register range. The program's own clients of course can address that full register range because they don't need to use Modbus to talk to other parts of the same program.

This is the home page for the project:
http://sourceforge.net/projects/mblogic/

This page describes how I did what I call an "expanded register map":
http://mblogic.sourceforge.net/mblogichelp/communications/ComsExpRegs-en.html

Other programs (and embedded devices) may do some of the details differently. In particular, it is pretty common to duplicate the entire data table multiple times. In this case however, this feature was implemented as a user request and this technique worked better with the rest of the system.

 

All,

This particular piece of equipment was specifically written to not use the Slave/Unit ID, which in reading up on Modbus/TCP is how a purely Modbus/TCP server is supposed to act. The Slave/Unit ID is only used for Modbus/TCP-Modbus/RTU gateways.

I was hopeful that the device would allow multiple connection to port 502 and then just filter the connections by IP address and direct the request to the appropriate slave (you need to configure a client IP for each slave if you have more than one server setup). However, based on the discussion here, it seems that I will have to use a different port for each server to keep things segregated.

I do not have control of the clients programing, nor do I know what software they are using, but I guess I will have to be hopeful that at least one of them is flexible enough to change the port used for the Modbus/TCP connection (two different companies polling the server).

Thank you for the help everyone.

 

Hello,

You are correct.

A server/slave could be written that contained, as part of its configuration, a matrix of incoming IP addresses to slave devices. You could even right one that used the client's port number as the key for mapping.

I wrote what I did because that is the most common method I have seen to allow one server to host multiple unit IDs.

I used the unit ID in our (free) slave simulator which simulates all 255 devices.

Good luck,

Mark
http://www.peakhmi.com/

 

According to MODBUS Messaging on TCP/IP Implementation Guide V1.0b from Modbus Organization

Page 6/46:

"All MODBUS/TCP ADU are sent via TCP to registered port 502."

But, as long as client and server both support alternate ports, using an alternate port isn't a problem. Clients that don't offer port flexibilty would not be able to see servers at alternate ports.

-Mark
http://automatedsolutions.com

 

Hello,

> You could even right one...

DOH!

You could even write one...

Mark
http://www.peakhmi.com/

 

You're asking us if it is theoretically possible for a device to do something, but we don't even know what that device is. That's not the sort of question that I can answer.

I can think of several different ways to accomplish what you want, although perhaps not in exactly way you were thinking of doing it. However, I have no idea whether the device you bought is capable of doing it.

If you want to phrase the problem in terms of "here is my application, can anyone suggest a solution to it", then someone may be able to help you. If however the problem is that you already bought a device and it doesn't do what you need, then I'm not sure what I can do about that.

To to back to your original question, you asked:

> Is the ModbusTCP standard designed such that I should be able to have all of the data filtered by IP address through port 502 <

The "standard" port is 502, and many client (master) and server (slave) devices don't have a parameter setting to change it. The reason for having a "standard" port number however is just for user convenience (you know what to expect). It's the same reason that for example web servers normally run on port 80 but can actually run on any port if you specify a different one at both ends of the connection.

> or is it common practice to use a different port for each ModbusTCP server? <

It's not common to actually need to run more than one server on the same device. If you do need to do that however, then some devices (and software) do allow you to change the port number. The port number isn't part of the Modbus/TCP message itself. It's part of the TCP/IP "wrapper" that goes around the message. Changing the port number doesn't change the actual Modbus/TCP message.

The limitations are just in the vendor's configuration software. Since most people don't need to change the port number, most vendors simply don't put that option in. That undoubtedly saves them a lot of phone calls from people who set the port to the wrong number.

> I was hopeful that the device would allow
> multiple connection to port 502 and then just
> filter the connections by IP address and direct
> the request to the appropriate slave (you need
> to configure a client IP for each slave if you
> have more than one server setup).

That could probably be done (re-mapping by source IP) if the device was using Linux and you could change the netfilter configuration. I have done something similar by re-mapping port 502 to a higher port number (above 1024) on in-bound connections for security reasons. I don't know what your device is however, so I can't really answer that question.

 

Thank you Mark, that was what I was really hoping to see in my round about question asking. Sorry if I misdirected anybody.

As for the device selection, this was client driven I had no say in selecting a different device. It was sort of a, "The manufacturer says it will do what we want, so make it do what we want" statement from the client. I have a call into the manufacturer to see if their device is designed to filter multiple ModbusTCP masters through the same port or if it needs to use different ports for each master, it is not documented in their manual. It sounds like it is not uncommon for you guys to use a port other than 502 from time to time as the need arises, I was concerned that by changing the port I would be doing something that is against the norm for how the real ModbusTCP professionals, such as yourselves, setup their equipment.

Thank you for the help

 

Using "well known ports" is a convention but, only a convention. Using Linux/UNIX you can pretty much do whatever you want with some, few restrictions. But using software where the numbers are compiled in means you are pretty much limited to what the canned software does. If you want to bad enough, you can write something to translate.

Regards
cww

 

In reply to curt wuollet: I *think* this would work for iptables, but I haven't tried it:

iptables -t nat -I PREROUTING -p tcp --source 192.168.100.100 --dport 502 -j REDIRECT --to-port 10502

That (I think) would take any connections from IP 192.168.100.100 (as an example) on port 502 (change as appropriate), and redirect it to port 10502. Each client could have a rule specifically for it.

I'll say again however that I haven't actually tried this, but I'm pretty sure that it should be possible. This is just a variation on NAT, which is routinely done using iptables. This just forwards to local host instead of to another machine.

You can chain more rules together to do things like filter out connections that you want to reject, etc. There are GUIs to assemble iptables rules, but I haven't tried them so I can't say which ones would work the best for this.

That would do everything using off the shelf software.

As for having source, well I *have* a Modbus/TCP server that I think could be easily modified to do this (without using any iptables rules). It already checks to see where the connection is coming from, but currently it just prints the address on the screen. It wouldn't be too difficult however to calculate a data table offset based on source IP address instead of unit id.

The program is free, and comes with source code. If the original poster is interested we could talk about that.

 

Yes, but on Linux I would just change the port number and recompile. That way if someone changes machines, they don't tear their hair out trying figure out what happened. But you could likely do something like that with say, a plug computer and fool a hard coded app on a closed OS into working.

Regards
cww