Studio 5000 + HMS EIP X-gateways

Is it preferable to now install these with the EDS or as AB_Generic_Ethernet modules?


We have six in total and the latest was setup successfully with the EDS whilst the early ones are AB_generic. Is it worth converting these over as a matter of best practices?


This would remove the config array tags which are not cross-referenced in the program. ie AB:ETHERNET_MODULE:C:0 is an empty array of 400SINTS.

Otherwise, beyond the module properties dialog box having more tabs and options, are there any benefits beneath the hood?

For my part this seems to be a worthy exercise just in getting to grips with these modules - they are a fundamental part of my system converting CAN messages from battery and hydraulic systems onto the EIP network.


Any reasons not to go for it? Thoughts/comments very welcome.

I personally wouldn't bother if they are up and running already.

Yes, they are all running fine, i.e. both with the AB_generic and EDS profiles.

Arguably there is little value to the system in trying to fix what isn't broken, however, this is likely the only way for me to gain valid experience.

Sinking a couple of hours doesn't cost my employer and the system is in a dormant state so can be interrupted a few times to work the bugs out as necessary.

What is the best practice going forward? Always use the EDS? Or does the AB_generic allow for more flexibility?

OWEN.DAVID said:

this is likely the only way for me to gain valid experience.

Click to expand...

Valid experience in what? Developing? Maintaining? Getting to know the system?
I'b be ten times more worried about the configuration in the HMS modules than how they're connected to the PLC.

Also, changing the way they're used may or most likely will break the logic down the line and you won't catch it in a dormant state... i.e. there is a serious potential for downtime. I'm not sure how exactly the data is spat out from the module, but there's a potential for bytes to be inverted or not perhaps shifted.

If it's training you're looking for, getting a smaller PLC or whatever you have as spares is much better than risking stopping or messing up a working piece of machinery.

yes, agree, there are significant risks to be mitigated here.

I suppose the best approach would be to plan out the procedure, identify all the likely points of failure, and then rigorously test each module one at a time. Fortunately there are only a handful of bytes being rx/tx in each module so taking a survey of the logic, byte orders, etc, will be straightforward.

The HMS config in the modules is backed up and isn't directly modified by the changes in the PLC. However, I do agree that this may break compatibility and should be checked.

So for any interested parties, I set out to explore the benefits of using the EDS for these HMS communicators instead of the AB_generic profile.


One immediately obvious difference is that the input array has an extra bit to determine if the ethernet connection to the communicator has faulted. On first inspection this does not appear to be so readily available in the AB_generic profile.

Would that bit not be included in the data from the generic profile?

cardosocea said:

Would that bit not be included in the data from the generic profile?

Click to expand...

A good question. From what I have seen from comparing the AB generic and anybus EDS input arrays - I don't think so. We can however poll ethernet module data using GSV and MEQ to determine the same or similar status.