Add new node-type for EtherCAT in order to connect CWD

[stv0g]

I think the fasted way to get CWD connected to our lab infrastructure would be the addition of a new interface to VILLASnode. This would require a software-based EtherCAT, like it is also used by Opal-RT. Lateron, we could consider moving this EtherCAT master also to the FPGA (VILLASfpga). But the FPGA development would take much longer. And before we are not sure that this is really required, I would advocate for going the software path first.

I found a simple guide which we could use to get started: http://www.ericlwilkinson.com/blog/2015/5/31/ethercat-development-guide-for-linux

Available EtherCAT master implementations for Linux:

• SOEM
• [EtherLab]()
  • Example code

/cc @n-eiling /cc @mstevic /cc @Alexander.Helmedag

What are you opinions? @n-eiling feel free to get started if you like. I am currently a bit busy with other things :(

• [x] Test ethercat connection
• [x] Have GE configure PCI slave
• [x] Test communication with PCI slave
• [ ] Define Interface
• [ ] Implement ethercat node interface in VILLASnode
• [ ] Connect OPAL-RT

For Opal-RT:

• Uses SOEM
• We should be able to use Etherlab. But will it be real-time capable?
• Can also be connected via a VILLASnode or Bachmann modules

[stv0g]

In GitLab by @n-eiling on Oct 17, 2018, 16:58

Sure I can look into that. I'd need access to the system that is supposed to run VILLASnode though (the Opal-RT system?). Also could you point me to where this would be integrated into VILLAS? I'm not really familiar with the code yet.

[stv0g]

I'd need access to the system that is supposed to run VILLASnode though (the Opal-RT system?)

Good question. I would suggest to use the system which Daniel used for his master thesis. We have to do a fresh setup of Fedora anyway.

Also could you point me to where this would be integrated into VILLAS? I'm not really familiar with the code yet.

I think it would be good if we have more people familiar with the code. I can give you an introduction.

[stv0g]

In GitLab by @ghost on Oct 18, 2018, 12:03

@stvogel I agree this gives us more flexibility and in this situation the fastest to test. Can we guarantee hard real-time interface in overall setup with RTDS and OPAL-RT if VILLASnode is used?

[stv0g]

Little update on our current progress:

• PCIe slave card of GE controller is detected
• We will go with the iGH Etherlab EtherCAT Master for building a little test tool
• We will do this testing with the acs-villas.eonerc.rwth-aachen.de machine
• I had to patch the EtherCAT master code for our newest Linux kernel 4.18
• The new Etherlab master code also detects the slaves :)
• The new Etherlab master code has so much more functions.. Have a loog the attached picture of the detected EtherCAT topology
• The PCIe Slave cards seems to be unconfigured. It does not advertise any PDO mappings. The master also detects it as unconfigured and in the "INIT" state in constrast to the other slaves which are in "PREOP" state.

[stv0g]

There is a good description of the CANopen protocol here: https://www.canopensolutions.com/english/about_canopen/pdo.shtml

[stv0g]

Some commands and attempts to read/write die ADC/DAC values:

# Show all slaves
ethercat slaves

# Cycle AIn slave into operational state
ethercat states -p4 OP

# Cycle AOut slave into operational state
ethercat states -p3 OP

# Set output value of AOut ch1
ethercat download -p3 -t int16 0x8000 0x13 0x0

# Read input value of Ain ch1
ethercat upload -p4 -t int16 0x6000 0x11

[stv0g]

@mstevic

Can we guarantee hard real-time interface in overall setup with RTDS and OPAL-RT if VILLASnode is used?

Not yet. Currently we only have the AsyncIP link between OPAL-RT and VILLASnode which uses UDP. UDP is not hard realtime capable.

I plan to start implementing the Aurora interface between OPAL-RTs FPGA and VILLASfpga soon. Once we have this link, we have hard real-time guarantees:

OPAL-RT CPU (RT-LAB) -> OPAL-RT FPGA (RT-XSG) -> VILLASfpga -> VILLASnode -> CWD PCIe EtherCAT slave

Its a more complex setup in the end but I think its worth the effort because we gain much flexibility to also attach RTDS instead of OPAL-RT.

[stv0g]

Its probably also easier to test RTDS first, because we already have a functioning interface between RTDS and VILLASnode. So there would be no need to implement the Aurora Interface right now.

[stv0g]

In GitLab by @n-eiling on Oct 19, 2018, 14:01

ethercat slaves -v also shows the delay between the first and second arrivals of the ethercat frame at the individual slaves. For the media converter at ACS (Slave 0) the delay is 23440 ns. I guess we can use this as a first estimate for the round trip time.

[stv0g]

In GitLab by @n-eiling on Oct 23, 2018, 11:11

Just a quick update on my progress: I am able to read from the analog in module using periodic PDOs. When sending values to the analog out module the values get set to the correct memory address (0x70x0:01) but it seems as if they are not transferred to the DAC (The DAC raw value 0x800E:01 does not change.). Also etherlab sometimes crashes the linux machine (only when sending data). I'm not sure about the reason for this yet.

[stv0g]

Hi Niklas,

I am able to read from the analog in module using periodic PDOs. When sending values to the analog out module the values get set to the correct memory address (0x70x0:01) but it seems as if they are not transferred to the DAC (The DAC raw value 0x800E:01 does not change.)

Thats the same behaviour which I experienced when interacting with the couplers via SDOs. Did you put the device into the OP - operational state? In PREOP - pre-operational state, the outputs are unaffected.

Also etherlab sometimes crashes the linux machine (only when sending data). I'm not sure about the reason for this yet.

I had to port the etherlab driver to 4.18. Maybe we should test it with a 3.x kernel if this problem persists.

[stv0g]

In GitLab by @n-eiling on Oct 23, 2018, 11:30

The command you used (ethercat download -p3 -t int16 0x8000 0x13 0x0) sets 0x8000, which is the default value for the outputs. This can only be set in the PREOP state. The analog out values (0x70x0) can never be set using SDOs (They are read-only according to the documentation). However, the output should change regardless of how we set it. Anyway, I think this problem is mainly with the beckhoff device rather than the actual communication, which seems to work fine. Regarding the crashes, I can also try installing an older kernel to check if that helps. Should we maybe create a git repo for the test application?

[stv0g]

I would propose to use this repo and start a new branch node-ethercat. We still can go with a standalone tool first. But I plan to integrate it with VILLASnode as soon as possible.

[stv0g]

In GitLab by @n-eiling on Oct 24, 2018, 10:34

I fixed the crashes (NetworkManager was interfering with the ethercat driver).

I still don't see the outputs set to the analog out module at the analog in module, but the device seems to correctly receive them. Maybe the device is not correctly wired up? I am also still getting an error from the etherlab driver that the GE PCI Slave cannot be initialized.

I think for now we have to wait until GE properly set up the PCI slave to do further testing. The test tool and a first stub for the ethercat interface is in the node-ethercat branch.

[stv0g]

In GitLab by @n-eiling on Oct 24, 2018, 10:37

marked the checklist item Test ethercat connection as completed

[stv0g]

In GitLab by @n-eiling on Nov 28, 2018, 08:41

marked the checklist item Have GE configure PCI slave as completed

[stv0g]

In GitLab by @n-eiling on Nov 28, 2018, 08:41

marked the checklist item Test communication with PCI slave as completed

[stv0g]

In GitLab by @n-eiling on Nov 28, 2018, 08:42

Just a quick update: We can now communicate with the GE ethercat slave. The next step are to properly define the interface with them and then implement this into VILLAs

[stv0g]

Our hiwi, implemented a basic ethercat node-type for VILLASnode based on EtherLab.

As we currently dont focus on this direction anymore, I will close the issue

[stv0g]

closed