[etherlab-users] ELM3004 (ADC) and SDOs requests

[Romain Virot]

Thanks a lot for the reply.

I've installed the patches you linked, but doing so my master does not see any slave, at all. When reinstalling regular etherlab master, it can see the slaves again. Any idea what the issue could be?

PS : I'm running the modules directly from a Beckhoff CX5140 IPC.

Romain



----- Mail original -----
De: "Gavin Lambert" <gavin.lambert at tomra.com>
À: "Romain Virot" <virot at lpsc.in2p3.fr>, etherlab-users at etherlab.org
Envoyé: Mercredi 30 Octobre 2019 23:38:50
Objet: RE: ELM3004 (ADC) and SDOs requests

It is normal for a slave to drop to SAFEOP+ERROR when it loses communication with the master app.

If a slave is remaining in OP+ERROR with the master app not running, that is almost certainly a fault in the slave itself.  (However: it's also worthwhile making sure that the slave is not the first one in the network -- try putting in an EK1100 as the first slave if you have nothing else.  In particular, the stock stable branch code will try to keep the first slave in OP all the time, which is usually not a good thing (but is relatively harmless when it's an infrastructure component such as the EK1100).

For your other questions (and also for the above), you may find it helpful to try the unofficial patchset at https://sourceforge.net/u/uecasm/etherlab-patches/ci/default/tree/.  This includes some feature and reliability improvements for CoE as well as a command allowing you to soft-reboot compatible slaves.  It also disables the first-slave-in-OP behaviour.


Gavin Lambert
Senior Software Developer

 


COMPAC SORTING EQUIPMENT LTD | 4 Henderson Pl | Onehunga | Auckland 1061 | New Zealand
Switchboard: +49 2630 96520 | https://www.tomra.com

The information contained in this communication and any attachment is confidential and may be legally privileged. It should only be read by the person(s) to whom it is addressed. If you have received this communication in error, please notify the sender and delete the communication.
-----Original Message-----
From: Romain Virot
Sent: Thursday, 31 October 2019 01:38
To: etherlab-users at etherlab.org
Subject: [etherlab-users] ELM3004 (ADC) and SDOs requests

Hi,

I'm quite new to EtherCAT and while I managed to run a simple system (2 EL2004 modules), I'm facing two issues (maybe related) with a Beckhoff ELM3004 module (and SDOs in general). I already searched heavily for solutions and tried many things but I'm now kind of lost...

First issue is :

I can activate the master and enter the cylic task without issue, and the ELM3004 goes into OP state. If I now stop my master (getting out of the cyclic task loop and releasing the master), the ELM3004 is stuck in OP (with the Error tag) state, while the 2 EL2004 modules do properly return to the PREOP state. I do no understand this behavior nor have any idea of how to diagnosis the problem.

Second one :

I cannot make RT SDOs (using requests) work. The request creation, before master activation, does work. However calling a request, either read or write, always ends up with "busy' states only for the request until the timeout is reached, and then the request state naturally goes into 'error'. This is for various frequency checks (from 1kHz to 1 Hz). I tried to replicate the mini exemple, and behavior is similar. Note that everything related to the EtherCAT system is on the same thread, if it matters (I have a QT Gui on another thread). FYI, I want to use RT SDO to be able to test modules easily and also run diagnosis.


On a side note, is there any possibility to reset//reboot an EtherCAT module (or whole domain//master) from a software perspective only? When the ELM3004 is stuck the only way for me to clean thing is to reboot the system...

Thanks a lot,

Romain
_______________________________________________
etherlab-users mailing list
etherlab-users at etherlab.org
https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.etherlab.org%2Fmailman%2Flistinfo%2Fetherlab-users&data=02%7C01%7Cgavin.lambert%40tomra.com%7C13c13d49111d45372eb608d75d35fb99%7C4308d118edd143008a37cfeba8ad5898%7C0%7C1%7C637080358744179207&sdata=urMi8xlYYC%2BIGYoMcMIN%2BO%2Fm5vyFy1%2Bie7XSnHfTo3w%3D&reserved=0