ControlToolbox.com

When we were working on the design of NetProModServe family of products , we had the following goals in mind:

-          Implement Modbus TCP Server

-          A plug and play DLL that the developer can integrate into his application is three steps

-          Be able to push/pull data into/from the server virtual RTUs from anywhere in the network or outside of the network domain to cover distributed applications

-          Be able to add/remove RTUs to the database seamlessly and dynamically

-          Communicate to the core event base

-          Stateless communication to the remotes so that break in the communication can be covered with minimum impact

-          Allow unlimited Modbus TCP connections to a single RTU on the same IP port

-          Allow all Modbus TCP connections to all the RTUs on the same IP port of a single machine

At the time, we were sure this design covers many features developers may need. Recently we were contacted by an international client. They were using our code library in an interesting setup. The application was receiving data on its holding register from remote terminals. One possible solution was to have the terminals to communicate to different Modbus RTUs with different UIDs. This is necessary because at the receiver side, they must to differentiate between the traffic received from different terminals. However, since they had to manage a large number of terminals, they did not want to have different configuration files in the terminals. So, they came up with a great idea: How about if NetPro interprets the last segment of the terminal IP address as the UID of the destination RTU?

We found the idea very useful. Not only did we implement it for the client, we added it to our standard code since it makes sense that there would be other people looking into this option. A great example as how a product evolves with the users’ feedback.

Take care for now,

Rod