Modbus/TCP Server Configuration

[Gummi Ben]

Hi, I'm constructing a project with Do-more CPU that connects to a remote I/O via Modbus.  I'm using the onboard ethernet plug to connect to the I/O through ethernet switch.  I saw in the help that the limit is 16 concurrent Modbus/TCP Server connections.  I was wondering what this means?  Can I only talk to 16 different devices ? Can I talk to more devices if I don't execute more than 16 MRX and MWX at the same time ?


Best regards
Guğmundur Ben

[BobO]

That is referring to the Modbus/TCP Server (Slave)...the end of the conversation that listens and responds to requests, and is specifying how many concurrent connections it supports. The Modbus/TCP Client (Master) is the end that does the requesting. There is no (practical) limit to those.

For best efficiency, consider creating one "Modbus TCP Client" device per remote device that you want to talk to. If the requests are very slow and infrequent, you can get away with using the built-in client device @IntModTCPClient to talk to more than one remote device...but I personally wouldn't. It's a little more work to set up clients for each, but I think the benefits outweigh the cost.

You can create additional Modbus TCP Client devices by selecting the "New Device" button on the Device Configuration page of the System Configuration.

[Gummi Ben]

Thanks BobO for your quick reply.  So if I wanted to read values from 20 different modbus devices, each with special IP-address, I could do that by setting up special modbus client per address.  In other words I could set upp 20 rungs that execute a MRX instruction without breaking any limits ?

Best regards
Guğmundur Ben

[plcnut]

Yes,
Set up a device for each one in system configuration.
Reference each one with a MRX/MWX, preferably using Stage programming so that each instruction can complete without being terminated.
Write your program so that you limit the system to only having 16 of the connections open at once.
After you are finished communicating with a device use CLOSE to free up the system resources, so that you can open more connections.

[franji1]

After you are finished communicating with a device use CLOSE to free up the system resources, so that you can open more connections.

No need to use CLOSE with MRX/MWX.  CLOSE is useful when doing custom TCP via OPENTCP or TCPLISTEN.

[BobO]

Set up a device for each one in system configuration.
Reference each one with a MRX/MWX, preferably using Stage programming so that each instruction can complete without being terminated.

Depends. In many cases this will be true...well, the termination requirement is always true...but MRX/MXW/DLRX/DLWX all can be used from $Main with any additional code for enabling or interlocking if all you need to do is read or write recurrently.

Write your program so that you limit the system to only having 16 of the connections open at once.

This is not necessary or beneficial. The only 16 limit is related to the server side, not client, and even for the server there is no programming required or even possible.

After you are finished communicating with a device use CLOSE to free up the system resources, so that you can open more connections.

Not required.

[plcnut]

Sounds like I need to shut-up

You guys are making things way to simple!

[BobO]

Sounds like I need to shut-up

Nah. Just don't get offended if we set the record straight. You have done lots of work with custom protocols, but the rules for standard stuff like Modbus are greatly simplified...since we can. For custom stuff it will always be a bit more complicated because it must be more flexible.

You guys are making things way to simple!

Throughout my 25 years of making automation products, the single biggest design challenge I have consistently faced is in balancing flexibility against simplicity. Almost anybody can make a powerful product, fewer can make a simple product, and fewer still can balance the two. It looks good for Do-more so far, although some would argue that there is a learning curve for it, but only time will tell how effectively we struck the balance. Personally I would rather apologize for a moderate learning curve and virtually no forward limits, than to constantly defend the walls people hit by saying "...but it's easy to use!" In truth, 'easy' should be evaluated in terms of how well the job finished...not how well it started.

[Controls Guy]

Exactly.  I'd rather pay the learning curve once, provided the mfgr did what they could to ease it as much as possible, then be more productive forever.

I want the software to empower me, vs. doing the work for me.

IOW, all that stuff you said, BobO!   

[plcnut]

No offense Bob, I try to give back a little of what has been given to me on the forums, and sometimes get my foot in my mouth... But always learn something