OpenEtherCATsociety / SOEM

Simple Open Source EtherCAT Master
Other
1.32k stars 670 forks source link

SDO write failed #781

Open Yoouple opened 8 months ago

Yoouple commented 8 months ago

Hi everyone! I encountered the problem of SDO communication failure when using the Panasonic MINAS A6 servo. The following is a detailed description: In the Pre-OP state, the servo drive needs to be mapped to the object dictionary(Assigning PDO), and the SDO write operation needs to be used in this step. This step uses the "ecx_SDOwrite" function, but the function sometimes returns failure. Analysis of the "ecx_SDOwrite" function shows that after the command is written, there will be a readback operation to determine whether the command was written successfully.

  wkc = ecx_mbxsend(context, Slave, (ec_mbxbuft *)&MbxOut, EC_TIMEOUTTXM);
  if (wkc > 0)
  {
     ec_clearmbx(&MbxIn);
     /* read slave response */
     wkc = ecx_mbxreceive(context, Slave, (ec_mbxbuft *)&MbxIn, Timeout);

By grabbing the erroneous packets, it can be seen that after SDO communication is initiated, every time the slave station feedbacks a CoE packet of type "EMERGENCY", causing the readback determination of the "ecx_SDOwrite" function to fail. 296681588-b9e69f64-345b-4424-855e-0ef30205a32e

I cannot confirm whether it is a problem with the Panasonic servo product itself or a problem with the SOEM library. The problem is sporadic and works fine most of the time.

Probably similar to what was mentioned in issue #764

Also if drive works in OP state and SOEM app exits, drive fall in appropriate error, but after it I can't start it again - SDO write in PRE_OP fails. Only power reset helps.

This is the pcapng data captured when the problem occurred: Panasonic.zip

I hope someone can bring me some inspiration. Thanks.

ArthurKetels commented 8 months ago

This is slave specific behaviour. The slaves has a problem and issues an Emergency. This is stored in the ec_errorlist. But your application does not handle the issue and the slave refuses to honour the SDOwrite.

My suggestion is to parse the Emergency data, act on it and see if the slave then responds normally.

One emergency code I found in the capture was : 0x50 0xff 0x10 0x04 Perhaps you can look this up in the slave manual and see what it means.

Yoouple commented 8 months ago

Thank you very much for your reply @ArthurKetels

As you said, I also found this error code (0x50 0xff 0x10 0x04) in one of the EMERGENCY messages and found its meaning: 80 4 Looking at the servo's technical manual, it seems reasonable that this error code occurred, because before this the servo was working in the OP state and I terminated the SOEM application.

But what I don’t understand is that before this error code appears, there are a large number of EMERGENCY messages with empty content. I don't know what went wrong with the drive at this point. empty However, the remapping of the object dictionary was successful, which shows that ecx_SDOwrite is effective, because I observed that the contents in 0x1C32\0x1C13\0x1A00\0x1600 are correct.

Once this error occurs, the real affected place is the "ecx_SDOread" function, because this function cannot read any meaningful data. This will affect the normal function of the "ecx_readPDOmap" function, causing the length calculation of SM2\SM3 to be incorrect, followed by an abnormal FMMU configuration. FMMU

It's not clear to me what triggered this error in this servo, but it does have a serious impact on the normal operation of the protocol stack.

By the way, when an error occurs, restart the servo drive or use the "ecx_config_init" function to rescan and the system will return to normal.