EGX100 Maximum Practical number of meters connected

[Anonymous user]

Hi,

I would like to know what has been done as maximum number of meters connected to EGX100 in a project (forget the documentation and standard Modbus rule of thumb that one can have 31 devices connected to a Modbus RTU master).

I need to know what has been achieved successfully in a project.

I have a project that will potentially have up to 26 meters connected to an EGX100 and back to PME. Ideally would like to achieve 4 seconds update rate, or faster. I've similar scenarios with other Modbus TCP/IP to Modbus RTU gateways in the past, but not with EGX devices, hence the open question.

Is the above achievable or am I going to face update/refresh issues during commissioning?

Thanks.

Goran

[Hal_Etheridge]

Do a search on here as there was another long thread talking about the device limitations on a RS485 bus.

The max update period possible is highly dependent on what you are doing (ie number of modbus frames per request) and the number of devices on the loop.

Roughly:  generally it will take between 100 and 200 msec per modbus frame.  Assuming device scan only takes a single modbus frame per SW request (more realistically it will take 2-10+ frames depending on what you are doing and the device's protocol map implementation) and with 26 devices per loop that is ~5 seconds assuming no errors and the devices respond exactly when they should (which never happens in the real world).

Add in more realistic conditions and the actual scan period is probably more like 10+ seconds for 26 simple devices.  Add in some margin for device complexity, errors and other issues and it becomes more like 20+ seconds.

And this is for a *single* master making requests.  Add in multiple masters like a dual PME and PSE system and it gets worse, much worse. 🙂

This is why we generally recommend limiting each loop to 10 devices (or less).

Additionally some devices are *extremely* inefficient in how the modbus requests can be structured.  Micrologic devices in general (for instance) are really bad due to their protocol map structure.  This is not a SW limitation but rather caused by the device implementation.

PME also has a daisy chain calculator spreadsheet which allows you to put in some basic assumptions and it will calculate the approximate update period possible for a given number of devices.  Check in the PME area of the SEC for this download.