However, I do not understand completely why would you make a system composed of both a SOM/PC and a PLC when using only a SOM/PC is simpler.
This really depends on what you’re doing. If you’re turning a couple things on/off and reading a few inputs via GPIO then it’s fine to do however you want. If you’re making a higher volume product and need to bring BOM cost down it makes sense too. If you’re working on a project that involves connecting to industrial manipulators, dozens of remote IO modules, and servo drives, you’re going to need an industrial fieldbus with rock solid reliability.
I’ve made some of the work I’ve done on internal projects with OPCUA and PLCs available. The code isn’t the cleanest and it’s not well documented, but it might help explain things. There is also a presentation I gave when other ROS developers at SwRI were asking the same questions as you. The project is titled pushcorp_opcua, but it’s more generic now and is a template for talking ROS1 to opcua to anything.
ROS part
PLC part
Presentation
The code was developed around controlling a servo driven spindle and force control device from Pushcorp. The only interface I had available was Ethernet/IP. As it was only 1 component in a system, I didn’t have time to read the entire spec and implement Ethernet/IP code that would run on a PC. Having never used Ethernet/IP or Beckhoff before, being familiar with Codesys was enough to get things communicating effortlessly. I was able to begin the real work right away instead of wasting time trying to get things to talk.
The presentation shows some images of the process, but basically you right click in the device tree and pick add, maybe fill out a few fields. For nice protocols like EtherCAT you just hook everything up and tell it to scan and it will add all the devices for you. After mapping the variables, you can just read and write to them everywhere without having to worry about copying them from the field bus at the start of a cycle and writing it back to the fieldbus at the end.
The ROS code will create topics and services automatically for structs defined on the PLC. Your ROS nodes can interact with local/remote devices on different networks the same way. OPCUA is much simpler to deal with than worrying about mapping PDOs on Ethercat and setting up implicit IO connections via CIP.
Could you please expand on that, perhaps with a dummy system like 2 actuators, 2 sensors and the controller, or similar? What would you have to do if your controller is a SOM + PLC versus only a SOM?
I started writing a specific response to this, but it got really long and sounded too much like a sales pitch. Basically, if you’re hooking a couple ins/outs directly to GPIOs in a product, just use your SOM. But try and think of everything that would be involved in communicating with multiple industrial devices over multiple realtime industrial networks, and what the goal of your project really is. This is something that has been solved well in PLCs.
If you wanted more details I could possibly do a phone call.