Understand feasibility of Ethercat protocol communication with Ignition

Hello Team,
We are looking for interface ignition with device which support Ethercat protocol.
Could you please let us know feasibility of Ethercat communication with Ignition?

Regards,
Dhiraj Pawar

  1. What's the device?
  2. Does it have a standard Ethernet port?
  3. Does it have an OPC server built-in?
  4. Is there an OPC-UA driver available for it?

perhaps @Christofer_Dutz who is developping a driver for Profinet IO, a communication protocole for Input/Output modules, not yet for Ignition but in Java, could bring some answer to that

or @pturmel who developped for Igntiion a 3rd party EtherNet/IP driver
https://www.automation-pros.com/modulesales.html

EtherCat is a nightmare. It requires a complete hijack of an Ethernet port for dedicated use, and uses bare Ethernet frames. Java cannot generate or receive bare Ethernet frames without help from a JNI library written in native code (C).

(ProfiNet paced data traffic is also bare Ethernet frames, so I'm curious how Christofer will accomplish this.)

He's using pcap4j (native), and on Linux you additionally need to give the Java executable CAP_NET_RAW and CAP_NET_ADMIN.

1 Like

Yeah I'm using pcap4j in all Java drivers that need to be "slightly" closer to the hardware ... and also: Yes implementing a driver on the base levels of raw ethernet frames is definitely a joy closely related to SM ... not quite as close as implementing DCOM communication on basis of raw sockets (Which Profinet requires me to do and which OPC-DA would also have me do), but still.

I do have EtherCat support in Apache PLC4X on my Todo list, however I'm doing most of the development in my free time and it feels like the list is growing quicker than I'm able to work it off.

3 Likes

And generally my Profinet driver seems to be working under lab conditions (Still need to figure out some bits of the publish part) ... turns out the problems I was having with my demo devices were related to all models of that device having issues with keeping the send clock stable (the problem was with the devices not with my dirver :wink: )

1 Like

What's your experience with PLC4X about the IO read/write speed?

I tried PLC4X with Go on communicating with Siemens 1500 PLC, to read 100 DB blocks, it takes 8 sec to complete the read cycle, which is too slow to us.

I also tried Modbus TCP to read/write the generic IO modules, it's 50ms per module, but each module is limited to only max 32 IOs.
If we need 300+ signals, it will need at least 10 modules with 10 different Modbus TCP nodes, which is not cost effective.

I haven't found any Modbus TCP IO expansion module on the market, which can allow each Modbus TCP module to add IO expansion card, just like the PLC RIO module.

I also tried multiple Modbus RTU to a Modbus RTU/TCP gateway, to ignition, it worked but also very slow speed.

There are Ethercat IO expansion module on the market, but looks like the PLC4X does not support Ethercat yet.

Not sure what could be the cost effective and stable solution to allow ignition/python to rea/write field IO modules up to 500+ signals within 500ms.

Is it not possible to bring those IO signals into a Beckhoff PLC and expose them as tags that you can access over OPC UA?

1 Like

I don't want to use PLC as the intermediate interface. Some of the projects, we don't have a PLC, just IO direct to ignition.

Actually, you made a good point.
I can install a cheap PLC to collect the IO data and send it to ignition. But it's just not a neat solution.

It's neater than any other option you seem to have so far.

I hope PLC4X could be the ultimate solution to allow direct connection to the field IOs, a few hundred IOs within 0.5s scan cycle.