SOEM with LAN9253

[mictas]

Hello,

we uses a SOEM ROS package to manage our actuators from ROS Melodic in a Linux Ubuntu 18.04 LTS OS. Our EtherCAT board uses a Microchip LAN9253. The LAN9253 includes 8 SyncManagers, 8 Fieldbus Memory Management Units (FMMUs) and a 64-bit Distributed Clock. We tested successfully our ESI file and firmware using "Conformance Test Tool". We tried to move our actuators using a TwinCAT test program and it works. Unfortunately, when we try to move our actuator using SOEM package, it doesn't work and the following error is returned (launching a program based on "slaveinfo.c"):

Other useful information could be the following ones:

In the past we used the same ROS SOEM package to move actuators having an EtherCAT board equipped with LAN9252 (4 SyncManagers and 3 Fieldbus Memory Management Units (FMMUs)) and all worked.

So we suppose, that it could be a problem regarding LAN9253 (8 SyncManagers, 8 FMMUs (7used)) with SOEM.

1) Is SOEM able to manage devices with 8 SyncManagers? 2) We tried to modify EC_MAXFMMU changing its value from 4 to 8, but the error persists:

Is it possible to adapt SOEM for our LAN9253? If yes, what settings need to be changed?

Waiting for your response, thank you. Best regards.

[ArthurKetels]

No particular reason why SOEM should not support 8 FMMU's. But above information is by far not enough to give sensible answer about what goes wrong with your slave. Please provide the ESI and Wireshark trace of the boot-up process.

Is there any reason why you need 7 FMMU's? Most slaves function perfectly well with 3.

What I can deduce from above screenshot is that something goes wrong with the allocation of SM to FMMU. The standard SOEM configuration function tries first to assign all output SM (type =3) to one or more FMMU. Then it does the same for all input SM (type = 4).

There is something not OK with the SM length and start address. F.e. SM4 starts at 0x1800 and has length 44. So its end address should be 0x182c. This is not possible because SM5 starts at 0x1820.

Also your SM flags are quite unusual.

Again more information is most welcome.

[nakarlsson]

In addition make sure to use the latest SOEM, , we did a fix when using multiple SMs. https://github.com/OpenEtherCATsociety/SOEM/pull/375

Note: the above PR doesn't affect the actual configuration, just the expected WCK calculation.

[MattiaDeiRossi]

Hi everyone, I tryed to fix @mictas issue.

I done some tests with the same configuration and debug the code. Debugging the code I found a configuration that works well

file ethercatmain.h

/** max. SM used */
#define EC_MAXSM 9
/** max. FMMU used */
#define EC_MAXFMMU 6

file ethercatconfig.c int the ecx_config_create_input_mappings and in the ecx_config_create_output_mappings functions I change ByteCount = SMlength; // instead of ByteCount += SMlength to make the offset correct. It's looks like a small bug. Isn't it

 /* search for SM that contribute to the input mapping */
   while ((SMc < (EC_MAXSM - 1)) && (FMMUdone < ((context->slavelist[slave].Ibits + 7) / 8)))
   {
      EC_PRINT("    FMMU %d\n", FMMUc);
      while ((SMc < (EC_MAXSM - 1)) && (context->slavelist[slave].SMtype[SMc] != 4))
      {
         SMc++;
      }
      EC_PRINT("      SM%d\n", SMc);
      context->slavelist[slave].FMMU[FMMUc].PhysStart =
         context->slavelist[slave].SM[SMc].StartAddr;
      SMlength = etohs(context->slavelist[slave].SM[SMc].SMlength);
      ByteCount = SMlength; // instead of ByteCount += SMlength;
      BitCount += SMlength * 8;
      EndAddr = etohs(context->slavelist[slave].SM[SMc].StartAddr) + SMlength;
      while ((BitCount < context->slavelist[slave].Ibits) && (SMc < (EC_MAXSM - 1))) /* more SM for input */
      {
         SMc++;
         while ((SMc < (EC_MAXSM - 1)) && (context->slavelist[slave].SMtype[SMc] != 4))
         {
            SMc++;
         }
         /* if addresses from more SM connect use one FMMU otherwise break up in multiple FMMU */
         if (etohs(context->slavelist[slave].SM[SMc].StartAddr) > EndAddr)
         {
            break;
         }
         EC_PRINT("      SM%d\n", SMc);
         SMlength = etohs(context->slavelist[slave].SM[SMc].SMlength);
         ByteCount += SMlength;
         BitCount += SMlength * 8;
         EndAddr = etohs(context->slavelist[slave].SM[SMc].StartAddr) + SMlength;
      }

After that I have modified the wkc actual calculation to align it with wkc expected: wkc += 6 because the expected is calcolated with EC_MAXSM and EC_MAXFMMU variables

Thanks to all these modifications I was able to run my programs with LAN9253 (8 SyncManagers, 8 FMMUs (7used)) Can this be a solution to the problem? Are the indices of the two functions correct?

[nakarlsson]

can you create a PR instead, easier to get an better overview of the changes.

[nakarlsson]

@mictas , can we close this issue?

[mictas]

Hello, you can close this issue in my opinion. Thank you