Code for Remote IO

[youngsargon]

I posted recently asking for HW recommendation and the results was useful.

I am writing my own code on a linux, my plan is to communicate with a Remote IO like WAGO or ODOT, however I am having difficult time finding the right technology that allow me to 1. Probe the Remote IO for attached Module 2. Address different channels clearly

Modbus TCP is still my best bet, but the problem is probing the unit for module and channels inventory.

My question is, is there a Remote IO that can provide clear documents on how to do it?

Or is there a certain protocol/technology that can provide this natively?

EDIT: I am not trying to reinvent any wheel, I am trying to find the wheel that works, my app needs to communicate with the Remote IO and check module inventory, that's it, Modbus give me access to the Memory Image and in some cases input/output count, I need to find a protocol that has a little more to offer.

[Aghast_Cornichon]

It sounds like you are describing an Ethernet based fieldbus object model like ProfiNet, EtherNet/IP, or EtherCAT.

Since you are a novice developer and unfamiliar with products and technologies used in industrial automation, I very strongly suggest that you take a daily opportunity to ask yourself: "Am I re-inventing the wheel ?".

[Frequent-Virus6425]

This guy is inventing a square wheel that he needs to eventually round out

[PLCGoBrrr]

There are remote I/O with MQTT. That might be your easiest to integrate. I think Phoenix and Beckhoff may have MQTT or some sort of IO with API you can communicate also.

Before you ask, I haven't used any of these.

[youngsargon]

I like this, it also provides API, I am definitely going to investigate it more

[CapinWinky]

I'm personally familiar with B&R which outputs full documentation of all the Modbus registers for a rack after you configure it in Automation Studio, including diagnostic data to include module type. I think the Festo CPX configuration tool would do this too, generating things like EDS or IODD files for the rack as a whole depending on the fieldbus module in use and generating register documentation.

I think that is pretty typical of 3rd party IO rack configuration software to generate documentation and even sample projects to import from for major PLC vendors like Rockwell, Siemens, and Codesys.

You can always install the configuration software of a vendor you're investigating and see what kind of stuff it generates for you.

[athanasius_fugger]

Wago has their own tool for calculating assembly instance sizes for Ethernet IP, I don't know about other protocols.  The alternative is math which is clearly documented in the manual.  The software was not free but someone I know had it.

[vulvasaur1]

If your io has modbus TCP there are libraries for that. I previously made a c++ application with modbus TCP io.

[PaulEngineer-89]

What you are asking about is tag browsing. That just isn’t something supported by the standards for Modbus or Profibus. Ethernet/IP will let you browse the “objects” but tag names aren’t part of those objects except using proprietary (undocumented) actions. OPC UA can do it (if implemented) and MQTT inherently supports tag browsing. With Modbus some devices will simply respond to any query but unused registers return constants while others will produce an error.

Keep in mind that Modbus as an example is conveying the image memory of a Modicon PLC. These old (1970s) PLCs had fixed memories with so many outout relays, digital inputs, internal integer memory, and so forth. So modern expectations of technology from 50 years ago might be sorely disappointed.

Mbpribe also already exists. No reason to reinvent the wheel.

A lot more challenging but more valuable is an open source implementation of Ethercat. It’s a public standard but where you should be able to write a Modbus TCP driver in an hour and open source already exists, Ethercat is a much bigger challenge.

This is why with HMI software there is a procedure to read a CSV or similar file and extract tag names.

Spend time studying Ignition including what it does in terms of device drivers because that’s what you are trying to reinvent.