ethercat | EPICS support to read/write to ethercat based hardware

In order to enable this functionality all you need to do is Enable ADS Server on the EtherCAT device that you are trying to access.

There are a few setup steps that are required to make this work, but it is reasonably straight-forward.

1. Scan in IO from EtherCAT chain
2. Add a new 'Twincat Task with Image'
   • Added from the context menu of 'System>Tasks'
3. Create and link variable from added task to IO
   • Force the sync-unit updates and allow control of EtherCAT timing
   • I added a variable that linked to the SlaveCount with a UINT, very basic
4. For EtherCAT master enable 'Enable ADS Server' and 'Create Symbols'
5. Access Symbols as you would any other on the controller
   • Only oddity around this is that you need to access the CONTROLLER net ID, not the EtherCAT master, But you still use the port from the EtherCAT master

Where to find 'Enable ADS Server', 'Create Symbols' and ADS Port

Example Symbol path in the IO device list

The answer to your question is: "No, only in a multi-threaded context."

In a multi-threaded context almost anything you cannot imagine will happen. The background and context you provided is extensive but not sufficient to study this.

One thing Conv_shouldread = false; //If true, Conv_ReadAvail returns true apparently modifies (or determines) the outcome of if(ThreadSync.Conv_ReadAvail()) and it seem obvious that other threads are also interfering with this. I would, thus, clearly put the Conv_shouldread = false; inside the mutex protection.

But besides this, I must confess the problem could be clearly somewhere else and there can be a lot of side effects between different threads.

You will need two different tasks running at different speeds, determined by the baud rate of your communications and how often you want to process the data present on the buffer.

If you examine the example included in your reference link then you will see that then then there is two different tasks (2ms, 10ms cycle times). The high-speed task retrieves data directly from the serial port and loads it onto the message buffer, and the low-speed task processes the data.

Fixed problem by linking variable from PLC code to DevState-input of the device. Linking to plain InfoData doesn't seem to work though.

Each of the EtherCAT Coupler and its Terminals have Vendor ID, Product Code and Revision number. I don't know what do you mean by referring to IP address here. Also PDO entries if you want to write data or read data to/ from a very specific position.

No they don't have two IP addresses.

As many number of terminals can be connected to a EtherCAT Coupler, each of the Coupler and terminal information (in fact, how the bus is configured has to be know by the EtherCAT Master before hand). So there might be multiple addresses of each terminal connected to the coupler.

Hope I did not confuse you.

Regards.

This is not really a average Programmer Problem.

Driver Programming - as a subset of Realtime Programming - is a highly specialized field. The average C# or C++ .NET Programmer will rarely have to deal with stuff like pointers and neer with assembler level code. But for those two, it is their daily bread and butter. I can not give you little more then general advice:

My first advice for you is to get somebody elses code to make that decision and installation. Usually drivers of one Manufacturer are distributed in packages. Wich do understand how to deal with idenitifcation of the hardware. Usually those installers also have a silent mode. So it comes down to calling them and intercepting the console output/looking for the return value.

My second advice, is to use their name as listed in the Device Manager. Optionally get them renamed manually. It is not that reliable as strings are quite patient and easily changed/missmatched, but it would get you somewhere to start from.

But as I understand it your problem is worse then just general driver updates. You have two instances of the same Hardware, and want to use different drivers for each. Wich is a order worse:

1. I am not even sure this is possible. Since the driver folder still uses the good old "only one file of each name" approach, it is propable that you can not use different drivers for different instances of the same hardware. Unless you define your own driver storage location.

2. I have no idea why you would do that. The average enduser programm does not need to worry about even selecting wich interface it will use. It just hands it's request off the to network stack and does not deal with layer 3 or below. Servers may have to pick a specific adapter to listen on, or just listen on both in paralell. But even those do not care for the driver version in use. They do not even care if it is a real, physical interface - after all missclassification like with early Bluetooth and Virtual Devices like for Virtual Machine Monitors/PDF printers are a thing.

So it honestly sounds like you got a XY Problem, with this idea being the (propably wrong) Y, to your real X.

If you are not programming this just for fun or with educational purposes in mind but for professional use, I suggest you analyze the Ethercat packets of your machines with Wireshark and an additional hardware called ET2000.

The ET2000 adds a timestamp, with a max. delay of 40ns, to the mirrored packet sent to the pc, which you will be able to read thanks to the EtherCAT Stack Link dissector in wireshark.

Your answer appears to be right there in the message: Intel CPU required, but you stated you're trying to run it on an ADM (I assume AMD) processor.

There are various ways for you to communicate with a CX2020 from Linux, it all depends on your requirements and what the usage is for.

Without knowing anything about those, one option is to use the Beckhoff ADS protocol. All Beckhoff PLCs have by default ADS installed on them and you can (with the right credentials setup for ADS) communicate with the ADS-library. The good thing about ADS is that it is open-source, and thus it's possible to get the code for Linux.

The ADS sourcecode is available at: https://github.com/Beckhoff/ADS

You basically need to:
1. Compile/Install the library on your Linux machine
2. Create an ADS/AMS-route to your CX2020
3. Create a program that uses this route to communicate with the PLC With ADS you can access the variables directly in the CX2020 memory (both read and write!).

There are many finished wrapper libraries available for all common programming languages that you can use directly in Linux. If you're up to Python, I would recommend checking out PyADS (https://github.com/stlehmann/pyads), which has a good user base and many examples available all around the net.