Re: [etherlab-users] Error flag after requesting SAFEOP

[Gavin Lambert]

EC_WD_ENABLE enables the SM watchdog; it’s a separate thing from enabling the 
SM itself.  In general you should only activate it on one SM per slave – 
usually the output SM if the slave has outputs or the input SM otherwise.  If 
you don’t need the slave to drop from OP to SAFEOP when it loses communication 
with the master then you can leave the watchdog entirely disabled – though 
using the watchdog is usually recommended for output slaves for safety reasons.

Using erct_slave_config_sync_manager by itself is fairly pointless.  You need 
to specify the PDOs contained in the SM and then also actually use at least one 
PDO from each SM in your domain mapping.  Typically you use 
ecrt_slave_config_pdos to do the former and ecrt_domain_reg_pdo_entry_list for 
the latter.  See the example code.

From: Mohsen Alizadeh Noghani
Sent: Wednesday, 26 September 2018 22:32
To: etherlab-users@etherlab.org
Subject: [etherlab-users] Error flag after requesting SAFEOP

Hello everyone.

When I request SAFEOP state for my slave (Mecapion L7N) using shell command

$ ethercat state --position 0 SAFEOP

the slave's flag changes from + to E, and the state stays at PREOP.

Additional Info:
In a previous project, I used SOEM library and had to deal with the same issue, 
which was fixed by manually enabling sync managers 2 & 3.

ec_slave[1].SM[2].SMflags |= 0x0001;
ec_slave[2].SM[3].SMflags |= 0x0001;

I tried to do the same by the adding following lines in my a simple code

ret1 = erct_slave_config_sync_manager(sc, 2, EC_DIR_INPUT, EC_WD_ENABLE)
ret2 =  erct_slave_config_sync_manager(sc, 3, EC_DIR_OUTPUT, EC_WD_ENABLE)

Both function calls are successful (ret1=ret2=0) but the slave won't reach 
SAFEOP.


___
etherlab-users mailing list
etherlab-users@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-users

Re: [etherlab-users] Read from/write to the slave's object dictionary using SDOs

[Mohsen Alizadeh Noghani]

Thanks.

I tried the second option (used ecrt_master_sdo_download) and it worked.

Best,
Mohsen




On Wed, Sep 26, 2018 at 2:45 AM, Gavin Lambert 
wrote:

> There’s a number of different ways to do it, depending on why and how you
> want to do it.
>
>
>
> If this is a configuration setting (especially if it needs to be re-sent
> every time the slave reboots) that you can write (without needing to read
> anything), then you should use one of the ecrt_slave_config_sdo*()
> methods.  This will not do it immediately but will do it when you activate
> the master, and also if the slave reboots at any time while the master is
> active.
>
>
>
> If it’s a one-off request/query which you only do before activating the
> master, then you should use one of the ecrt_master_sdo_*() methods.  This
> will execute immediately and wait for the response.
>
>
>
> If you want to do it while the master is active, then you can either call
> ecrt_master_sdo_*() from a separate (non-realtime) thread (at the cost of a
> little extra latency on the realtime cycle), or you can use
> ecrt_slave_config_create_sdo_request() and related methods to perform
> polling on the realtime thread (for some extra code complexity).
>
>
>
> If it’s just something you need to do during commissioning and then never
> again (eg. if you can save the setting to the slave permanently), then you
> can use the “ethercat download” command.
>
>
>
> *From:* Mohsen Alizadeh Noghani
> *Sent:* Wednesday, 26 September 2018 03:41
> *To:* etherlab-users@etherlab.org
> *Subject:* [etherlab-users] Read from/write to the slave's object
> dictionary using SDOs
>
>
>
> Hello everyone.
>
>
>
> How can I read from or write to an entry of a slave's object dictionary
> using SDO? I'm going to do this before my real-time task.
>
> For example, I would like to set the value of 0x6040 to 15 before my
> cyclic task.
>
>
>
> Best,
>
> Mohsen
>
___
etherlab-users mailing list
etherlab-users@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-users

Re: [etherlab-users] e1000e driver freeze on kernel 4.9.80 rtai 5.1

[René Reimann]

We tried to use only the e1000e driver for kernel 4.9.80 and no other 
patches. Additionaly we tried the e1000e driver
for kernel 3.18.22 with rtai 5.0. The problem remains the same in both 
cases.


There is no output to the syslog when the system freezes.

On 26.09.2018 02:46, Gavin Lambert wrote:

Email Signature

One of the first things you should try is to triage the patches by 
rolling them back and then adding them one at a time and testing until 
you find which patch appears to introduce the problem (or whether it 
exists in the baseline without any patches).  In most cases you can 
then try skipping that patch and applying subsequent ones until you 
find more problematic patches or you successfully apply the remainder.


Please share your findings so that we know where to look for the culprit.

(Also, if it manages to write some information to the syslog before 
freezing then that could be helpful.)


FWIW, I’ve been using PREEMPT_RT kernel 4.9.51 with e1000e for a long 
while without issues.


*From:*René Reimann
*Sent:* Tuesday, 25 September 2018 19:28
*To:* Gianluca Medini ; 
etherlab-users@etherlab.org
*Subject:* Re: [etherlab-users] e1000e driver freeze on kernel 4.9.80 
rtai 5.1


Hello,

we are experiencing the same problem with rtai 5.1 kernel 4.9.80 and 
rtai 5.0 kernel.
The system freezes randomly after several minutes with the e1000e and 
the unofficial patches.

Does somebody have an idea how to fix this?

Best Regards
René Reimann

On 23.09.2018 22:29, Gianluca Medini wrote:

Hi all, I've tested the driver e1000e on rtai 5.1 kernel 4.9.80.

I'm using Gavin Lambert unofficial patches set that includes
patched drivers for 4.9.80.

The system  freezes randomly after some  minutes.

The Igb driver on same configuration works perfectly.

Someone have experienced the same issue?

GM




___

etherlab-users mailing list

etherlab-users@etherlab.org 

http://lists.etherlab.org/mailman/listinfo/etherlab-users



Logo 



René Reimann
Research Assistent

IALB - Institut for electrical drives, power electronics and devices
Otto-Hahn-Allee 1
28359 Bremen
Raum: S1390
Tel.: +49 421 218 62699
Fax: +49 421 218 98 62699
E-Mail: rreim...@ialb.uni-bremen.de 

www.ialb.uni-bremen.de 
 







Virenfrei. www.avast.com 
 






--
Email Signature
Logo 
René Reimann
Wissenschaftlicher Mitarbeiter
IALB - Institut für elektrische Antriebe, Leistungselektronik und 
Bauelemente

Otto-Hahn-Allee 1
28359 Bremen
Raum: S1390
Tel.: +49 421 218 62699
Fax: +49 421 218 98 62699
E-Mail: rreim...@ialb.uni-bremen.de 

www.ialb.uni-bremen.de 



---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus
___
etherlab-users mailing list
etherlab-users@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-users