Great. Looks like you could break this up with a complex entry for each input
          <pdoEntry idx="6000" subIdx="01" bitLen="16" halPin="DI-bit" halType="bit"/>

eg
 

Well that was far less painful than I thought it would be.
AO0 looped back to AI0 gives comparable readings.
 

All it took was a bit copying and pasting, a few minor value edits, and I have the Analogue and Digital IO working with the following code-
<slave idx="3" type="generic" vid="0x00000b96" pid="0x00001400" name="D4">
      <!--EC1A-CORE1-->
      <syncManager idx="0" dir="in"/>
      <syncManager idx="1" dir="out"/>
      <syncManager idx="2" dir="out">
        <pdo idx="1601">
          <!--Digital Output process data mapping-->
          <pdoEntry idx="7010" subIdx="01" bitLen="16" halPin="DO-bit" halType="bit"/>
        </pdo>
        <pdo idx="1603">
          <!--Analog Output process data mapping-->
          <pdoEntry idx="7030" subIdx="01" bitLen="16" halPin="AO0" halType="u32"/>
          <pdoEntry idx="7030" subIdx="02" bitLen="16" halPin="AO1" halType="u32"/>
        </pdo>
      </syncManager>
      <syncManager idx="3" dir="in">
        <pdo idx="1a00">
          <!--Digital Input process data mapping-->
          <pdoEntry idx="6000" subIdx="01" bitLen="16" halPin="DI-bit" halType="bit"/>
        </pdo>
        <pdo idx="1a02">
          <!--Analog Input process data mapping-->
          <pdoEntry idx="6020" subIdx="01" bitLen="16" halPin="AI0" halType="u32"/>
          <pdoEntry idx="6020" subIdx="02" bitLen="16" halPin="AI1" halType="u32"/>
          <pdoEntry idx="6020" subIdx="03" bitLen="16" halPin="AI2" halType="u32"/>
          <pdoEntry idx="6020" subIdx="04" bitLen="16" halPin="AI3" halType="u32"/>
        </pdo>
        </syncManager>
    </slave>

Obviously doesn't include the ModBus stuff, but I have no use for that.
The lcec_configgen halPin naming did use duplicate names, and the unknown halTypes ( !!type 002e!! ) can be set to either bit or u32 depending on your own preferred usage. I've used bit for now.

To follow up with the lcec_configgen output, this is what it generated -

<slave idx="2" type="generic" vid="0x00000a79" pid="0x00001000" name="D3">
      <!--CL3-E57H-->
      <syncManager idx="0" dir="out">
        <pdo idx="1a01">
          <!--TxPDO 2-->
          <pdoEntry idx="603f" subIdx="00" bitLen="16" halPin="errorcode" halType="u32"/>
          <pdoEntry idx="6041" subIdx="00" bitLen="16" halPin="2-statusword" halType="u32"/>
          <pdoEntry idx="6064" subIdx="00" bitLen="32" halPin="position-actual-value" halType="s32"/>
          <pdoEntry idx="60fd" subIdx="00" bitLen="32" halPin="digital-inputs" halType="u32"/>
          <pdoEntry idx="6061" subIdx="00" bitLen="8" halPin="modes-of-operation-display" halType="s32"/>
        </pdo>
        <pdo idx="1601">
          <!--RxPDO 2-->
          <pdoEntry idx="6040" subIdx="00" bitLen="16" halPin="2-controlword" halType="u32"/>
          <pdoEntry idx="6060" subIdx="00" bitLen="8" halPin="modes-of-operation" halType="s32"/>
          <pdoEntry idx="607a" subIdx="00" bitLen="32" halPin="2-target-position" halType="s32"/>
          <pdoEntry idx="6081" subIdx="00" bitLen="32" halPin="profile-velocity" halType="u32"/>
          <pdoEntry idx="6099" subIdx="01" bitLen="32" halPin="search-switch" halType="u32"/>
          <pdoEntry idx="6099" subIdx="02" bitLen="32" halPin="search-zero" halType="u32"/>
        </pdo>
      </syncManager>
      <syncManager idx="1" dir="out"/>
      <syncManager idx="2" dir="out">
        <pdo idx="1600">
          <pdoEntry idx="6040" subIdx="00" bitLen="16" halPin="out-controlword" halType="u32"/>
          <pdoEntry idx="6060" subIdx="00" bitLen="8" halPin="mode-of-operation" halType="s32"/>
          <pdoEntry idx="607a" subIdx="00" bitLen="32" halPin="out-target-position" halType="s32"/>
          <pdoEntry idx="60ff" subIdx="00" bitLen="32" halPin="target-velocity" halType="s32"/>
        </pdo>
      </syncManager>
      <syncManager idx="3" dir="in">
        <pdo idx="1a00">
          <pdoEntry idx="6041" subIdx="00" bitLen="16" halPin="in-statusword" halType="u32"/>
          <pdoEntry idx="6061" subIdx="00" bitLen="8" halPin="mode-of-operation-display" halType="s32"/>
          <pdoEntry idx="6064" subIdx="00" bitLen="32" halPin="position-actual" halType="s32"/>
          <pdoEntry idx="606c" subIdx="00" bitLen="32" halPin="velocity-actual" halType="s32"/>
          <pdoEntry idx="6077" subIdx="00" bitLen="16" halPin="torque-actual" halType="s32"/>
        </pdo>
      </syncManager>
    </slave>

Which without editting results in this error -

Debug file information:
Note: Using POSIX realtime
Failed to register PDO entry: No such file or directory
LCEC: master 0 syncUnit default PDO entry registration failed
LCEC: failure, clearing config
LCEC: exiting
LCEC: returning -EINVAL
lcec: rtapi_app_main: Invalid argument (-22)
./my_EtherCAT.hal:10: waitpid failed /usr/bin/rtapi_app lcec
./my_EtherCAT.hal:10: /usr/bin/rtapi_app exited without becoming ready
./my_EtherCAT.hal:10: insmod for lcec failed, returned -1
1740
Stopping realtime threads
Unloading hal components
Note: Using POSIX realtime

Is there any kind of documentation about syncmanagers anywhere that explains what is required/how they work?

I'm starting a new thread for this, as I'm sure other people will likely be looking at these modules. The exact module I have is a AMSAMOTION EC1A-IO16R-AM6, which has 16 Digital Inputs, 16 Digital (relay) Outputs, 4 Analogue Inputs, 2 Analogue Outputs, and a ModBus connection.

The main reason I've selected this module is for the Analogue Inputs, as I want to use one for a Plasma THC, and another for FRO.

I've had it connected for a while, but have been concentrating on the Lichuan drivers first, so as it stands, I've only got as far as the lcec_configgen output -

<slave idx="3" type="generic" vid="0x00000b96" pid="0x00001400" name="D4">
      <!--EC1A-CORE1-->
      <syncManager idx="0" dir="in"/>
      <syncManager idx="1" dir="out"/>
      <syncManager idx="2" dir="out">
        <pdo idx="1601">
          <!--Digital Output process data mapping-->
          <pdoEntry idx="7010" subIdx="01" bitLen="16" halPin="mapping-ch" halType="!!type 002e!!"/>
        </pdo>
        <pdo idx="1603">
          <!--Analog Output process data mapping-->
          <pdoEntry idx="7030" subIdx="01" bitLen="16" halPin="mapping-ch0" halType="u32"/>
          <pdoEntry idx="7030" subIdx="02" bitLen="16" halPin="mapping-ch1" halType="u32"/>
        </pdo>
        <pdo idx="1605">
          <!--Modbus Master Control process data mapping-->
          <pdoEntry idx="7050" subIdx="01" bitLen="32" halPin="tigger-bit" halType="!!type 002f!!"/>
          <pdoEntry idx="7050" subIdx="02" bitLen="32" halPin="clear-bit" halType="!!type 002f!!"/>
          <pdoEntry idx="7050" subIdx="03" bitLen="8" halPin="rs485-enable" halType="!!type 001e!!"/>
        </pdo>
      </syncManager>
      <syncManager idx="3" dir="in">
        <pdo idx="1a00">
          <!--Digital Input process data mapping-->
          <pdoEntry idx="6000" subIdx="01" bitLen="16" halPin="mapping-ch" halType="!!type 002e!!"/>
        </pdo>
        <pdo idx="1a02">
          <!--Analog Input process data mapping-->
          <pdoEntry idx="6020" subIdx="01" bitLen="16" halPin="mapping-ch0" halType="u32"/>
          <pdoEntry idx="6020" subIdx="02" bitLen="16" halPin="mapping-ch1" halType="u32"/>
          <pdoEntry idx="6020" subIdx="03" bitLen="16" halPin="ch2" halType="u32"/>
          <pdoEntry idx="6020" subIdx="04" bitLen="16" halPin="ch3" halType="u32"/>
        </pdo>
        <pdo idx="1a04">
          <!--Data process data mapping-->
          <pdoEntry idx="6040" subIdx="01" bitLen="16" halPin="word0" halType="u32"/>
          <pdoEntry idx="6040" subIdx="02" bitLen="16" halPin="word1" halType="u32"/>
          <pdoEntry idx="6040" subIdx="03" bitLen="16" halPin="word2" halType="u32"/>
          <pdoEntry idx="6040" subIdx="04" bitLen="16" halPin="word3" halType="u32"/>
          <pdoEntry idx="6040" subIdx="05" bitLen="16" halPin="word4" halType="u32"/>
          <pdoEntry idx="6040" subIdx="06" bitLen="16" halPin="word5" halType="u32"/>
          <pdoEntry idx="6040" subIdx="07" bitLen="16" halPin="word6" halType="u32"/>
          <pdoEntry idx="6040" subIdx="08" bitLen="16" halPin="word7" halType="u32"/>
        </pdo>
        <pdo idx="1a05">
          <!--Data process data mapping-->
          <pdoEntry idx="6050" subIdx="01" bitLen="8" halPin="err0" halType="s32"/>
          <pdoEntry idx="6050" subIdx="02" bitLen="8" halPin="err1" halType="s32"/>
          <pdoEntry idx="6050" subIdx="03" bitLen="8" halPin="err2" halType="s32"/>
          <pdoEntry idx="6050" subIdx="04" bitLen="8" halPin="err3" halType="s32"/>
          <pdoEntry idx="6050" subIdx="05" bitLen="8" halPin="err4" halType="s32"/>
          <pdoEntry idx="6050" subIdx="06" bitLen="8" halPin="err5" halType="s32"/>
          <pdoEntry idx="6050" subIdx="07" bitLen="8" halPin="err6" halType="s32"/>
          <pdoEntry idx="6050" subIdx="08" bitLen="8" halPin="err7" halType="s32"/>
          <pdoEntry idx="6050" subIdx="09" bitLen="8" halPin="err8" halType="s32"/>
          <pdoEntry idx="6050" subIdx="0a" bitLen="8" halPin="err9" halType="s32"/>
          <pdoEntry idx="6050" subIdx="0b" bitLen="8" halPin="err10" halType="s32"/>
          <pdoEntry idx="6050" subIdx="0c" bitLen="8" halPin="err11" halType="s32"/>
          <pdoEntry idx="6050" subIdx="0d" bitLen="8" halPin="err12" halType="s32"/>
          <pdoEntry idx="6050" subIdx="0e" bitLen="8" halPin="err13" halType="s32"/>
          <pdoEntry idx="6050" subIdx="0f" bitLen="8" halPin="err14" halType="s32"/>
          <pdoEntry idx="6050" subIdx="10" bitLen="8" halPin="err15" halType="s32"/>
          <pdoEntry idx="6050" subIdx="11" bitLen="8" halPin="err16" halType="s32"/>
          <pdoEntry idx="6050" subIdx="12" bitLen="8" halPin="err17" halType="s32"/>
          <pdoEntry idx="6050" subIdx="13" bitLen="8" halPin="err18" halType="s32"/>
          <pdoEntry idx="6050" subIdx="14" bitLen="8" halPin="err19" halType="s32"/>
          <pdoEntry idx="6050" subIdx="15" bitLen="8" halPin="err20" halType="s32"/>
          <pdoEntry idx="6050" subIdx="16" bitLen="8" halPin="err21" halType="s32"/>
          <pdoEntry idx="6050" subIdx="17" bitLen="8" halPin="err22" halType="s32"/>
          <pdoEntry idx="6050" subIdx="18" bitLen="8" halPin="err23" halType="s32"/>
          <pdoEntry idx="6050" subIdx="19" bitLen="8" halPin="err24" halType="s32"/>
          <pdoEntry idx="6050" subIdx="1a" bitLen="8" halPin="err25" halType="s32"/>
          <pdoEntry idx="6050" subIdx="1b" bitLen="8" halPin="err26" halType="s32"/>
          <pdoEntry idx="6050" subIdx="1c" bitLen="8" halPin="err27" halType="s32"/>
          <pdoEntry idx="6050" subIdx="1d" bitLen="8" halPin="err28" halType="s32"/>
          <pdoEntry idx="6050" subIdx="1e" bitLen="8" halPin="err29" halType="s32"/>
          <pdoEntry idx="6050" subIdx="1f" bitLen="8" halPin="err30" halType="s32"/>
          <pdoEntry idx="6050" subIdx="20" bitLen="8" halPin="err31" halType="s32"/>
        </pdo>
      </syncManager>
    </slave>

Now this obviously doesn't work, as there are a few unknown halTypes, so I'm expecting a few issues along the way to getting this working, however it's a job for tomorrow night, as I'm needing to go and get some sleep, but first step will be getting the Digital IO working.

For a bit more thread completion, this is my current XML for a single CL3-E57H drive -

<slave idx="0" type="generic" vid="00000a79" pid="00001000" configPdos="true">
        <!-- Lichuan CL£-E57H -->
      <dcConf assignActivate="300" sync0Cycle="*1" sync0Shift="0"/>
      <sdoConfig idx="2303" subIdx="00"> <!-- Peak Current -->
        <sdoDataRaw data="a0 0f" />
      </sdoConfig>
      <syncManager idx="0" dir="out">
      </syncManager>
      <syncManager idx="1" dir="in">
      </syncManager>
      <syncManager idx="2" dir="out">
        <pdo idx="1600">
          <pdoEntry idx="6040" subIdx="00" bitLen="16" halPin="cia-controlword" halType="u32"/>
          <pdoEntry idx="6060" subIdx="00" bitLen="8" halPin="opmode" halType="s32"/>
          <pdoEntry idx="607A" subIdx="00" bitLen="32" halPin="target-position" halType="s32"/>
          <pdoEntry idx="60FF" subIdx="00" bitLen="32" halPin="target-velocity" halType="s32"/>
        </pdo>
      </syncManager>
      <syncManager idx="3" dir="in">
        <pdo idx="1a00">
          <pdoEntry idx="6041" subIdx="00" bitLen="16" halPin="cia-statusword" halType="u32"/>
          <pdoEntry idx="6061" subIdx="00" bitLen="8" halPin="opmode-display" halType="s32"/>
          <pdoEntry idx="6064" subIdx="00" bitLen="32" halPin="actual-position" halType="s32"/>
          <pdoEntry idx="606C" subIdx="00" bitLen="32" halPin="actual-velocity" halType="s32"/>
          <pdoEntry idx="6077" subIdx="00" bitLen="16" halPin="actual-torque" halType="u32"/>
          <pdoEntry idx="60fd" subIdx="00" bitLen="32" halPin="digital-inputs" halType="u32"/>
        </pdo>
      </syncManager>
    </slave>

This configures the drive to 4000mA current, and reads the digital inputs to a halPin.
I'll likely expand on it once things are installed on the machine, as I'd like it to fully configure the drive when the machine is powered on, but this is enough to get the basics working for now.

Is there a way to use the following error of the servo drives instead of the simple internal calculation in LinuxCNC? 
I get the actual following error from the servo drives (inovance SV660N / stepperonline a6) via ethercat idx="60F4" and have used it to tune the drives. 

There is an inherent lag between the commanded and actual position of servos due to the servo cycle of 1ms plus execution time plus processing in the drives and so on. For high speeds of say 50m/min LinuxCNC reports a couple mm of following error while the servo driver itself does not show any significant error. Is there a way to use the actual following error from the servo driver, and use that as the following error in linuxcnc for the joint, instead of the calculation on the side of linuxcnc?

mwc wrote:

 
Is anybody reading the status from drives during operation?
I know I could connect the drive error variable to a suitable HAL pin. but is anybody also reading the error code?

 

Check your xml file - it may already have a fault status hal pin 'baked in'

And cia402.comp has a drive fault pin:
If you can unplug or power off your drive and LCNC doesn't error out immediately, your setup could use some work.  Do you have anything connected in HAL to joint.N.amp-fault-in?

I don't think any of that is necessary (mapping homing pins to the regular inputs). I'm like 95% there now getting cia402 homing working with the absolute mode disabled. I'm able to home all axis x and y (z spins around looking for the z pulse and doesn't find it), but sometimes a joint will throw an amplifier fault JUST after completing homing (I can see the logging from cia402_homecomp indicating that the process had finished for that axis). I'm not sure why this is and it seems to be random...It'd be nice to figure it out but I guess that all i need is for homing to succeed once and then switch to absolute encoder mode? I'm still not sure how the combined Y+Y2 is supposed to work without homing... Like suppose you move one of the motors when the machine is off, will linuxCNC or something try to correct this deviation when the machine is turned on? If anyone knows what is the aim regarding this topic, please let me know. Below are my steps to getting to this stage:

- This repo is the best one I found for both homecomp implementation and linuxCNC config for these servos github.com/nickstewartroc/linuxcnc-a6-servo , and it is a fork from the one mentioned by @andrax (though the files he posted are not from there or are modified at least). Only one thing from there didn't work for me which is the binding of the di pins to see their state, they didn't reflect the way they are setup there. This is how each servo looks and what worked for seeing the home switches change state ( see<pdoEntry idx="2040" subIdx="05" bitLen="16" halType="complex". Also, I initially had issues halcompiling this homecomp with the additional includes, it was giving me an error on some types, make sure the cloned linuxCNC repo is on the same tag as your installation and not on main.

<slave idx="3" type="generic" vid="0x00400000" pid="0x00000715" configPdos="true">
<dcConf assignActivate="300" sync0Cycle="*1" sync0Shift="300000"/>
<watchdog divider="2498" intervals="1000" />
<sdoConfig idx="2004" subIdx="0a"><sdoDataRaw data="01 00"/></sdoConfig>
<syncManager idx="2" dir="out">
<pdo idx="1600">
<pdoEntry idx="6040" subIdx="00" bitLen="16" halPin="control-word" halType="u32" />
<pdoEntry idx="6060" subIdx="00" bitLen="8" halPin="control-mode" halType="s32" />
<pdoEntry idx="607A" subIdx="00" bitLen="32" halPin="target-position" halType="s32" />
<pdoEntry idx="60FF" subIdx="00" bitLen="32" halPin="target-velocity" halType="s32"/>
<pdoEntry idx="607C" subIdx="00" bitLen="32" halPin="home-offset" halType="s32"/>
<pdoEntry idx="6098" subIdx="00" bitLen="8" halPin="homing-method" halType="s32" />
<pdoEntry idx="6099" subIdx="01" bitLen="32" halPin="homing-high-velocity" halType="u32"/>
<pdoEntry idx="6099" subIdx="02" bitLen="32" halPin="homing-low-velocity" halType="u32"/>
<pdoEntry idx="609A" subIdx="00" bitLen="32" halPin="homing-acceleration" halType="u32"/>
</pdo>
</syncManager>
<syncManager idx="3" dir="in">
<pdo idx="1A00">
<pdoEntry idx="6041" subIdx="00" bitLen="16" halPin="status-word" halType="u32" />
<pdoEntry idx="6061" subIdx="00" bitLen="8" halPin="mode-display" halType="s32" />
<pdoEntry idx="6064" subIdx="00" bitLen="32" halPin="actual-position" halType="s32" />
<pdoEntry idx="606C" subIdx="00" bitLen="32" halPin="actual-velocity" halType="s32"/>
<pdoEntry idx="6077" subIdx="00" bitLen="16" halPin="actual-torque" halType="s32"/>
<pdoEntry idx="60FD" subIdx="00" bitLen="32" halPin="digital-inputs" halType="u32"/>
<pdoEntry idx="2040" subIdx="05" bitLen="16" halType="complex">
<complexEntry bitLen="1" halPin="di-1" halType="bit"/>
<complexEntry bitLen="1" halPin="di-2" halType="bit"/>
<complexEntry bitLen="1" halPin="di-3" halType="bit"/>
<complexEntry bitLen="1" halPin="di-4" halType="bit"/>
<complexEntry bitLen="1" halPin="di-5" halType="bit"/>
<complexEntry bitLen="11"/>
</pdoEntry>
</pdo>
</syncManager>
</slave>

- Wire the home switch per page 26 of the manual. You need to tie either COM- or COM+ to your external PSU's negative output depending on the sensor type (NPN or PNP). I had tied COM- instead of COM+ for PNP and that wasn't working. Make sure DI3 flips when the sensor toggles before proceeding any further.
- Depending on whether your sensor is NC or NO, you need to change your home switch between active low and active high, documentation for this is in page 209. (<sdoConfig idx="2004" subIdx="0a"><sdoDataRaw data="01 00"/></sdoConfig> in my config for NC switch). Also on page 209 is the function selection for DI3. It's set correctly by default, but one of my drives had it wrong and i presume this was the result of debugging changes made via dcConf entries that got removed. Check that all yours drives have it on the correct setting which is 5. You could technically use any of the DI pins that have function selection as the home switch changing stuff around this PDO. By this time the sensor pin should light up in halshow when triggered no matter whether the sensor is NO or NC.
- At this point it should be possible (though i haven't tested, i did have it working with the pins wired to the beckoff inputs though) to configure regular homing using the drive pins as input if you wished to test it out for sanity checking.
- Assuming that works or you skip it, copy the relevant bits of the hal in the referenced repo. I didn't have to change anything there since i dumped my XML (which was already very close but had slightly different property names) so i could just copypaste as it was.
- I used homing mode 4 like @Andrax but that might not be right for you. On Page 74 there's ample documentation for how each home mode works.
- When trying things out you might use low speeds for the 2 speeds involved in homing. Beware homing has a timeout that defaults to 60 seconds on the servo config. Homecomp doesn't catch this timeout and gets stuck forever, leading you to have to close linuxCNC and power cycle the drives (Page 215).
- Presumably once you're happy you'd comment the homing stuff and add HOME_ABSOLUTE_ENCODER to the joints like the initial post suggests.

I hope this helps someone, and please let me know if your know what the amplifier faults i'm getting after homing might be. This is my first time using linuxCNC. My config is attached for whoever finds it useful or can help me with the little bit i think i have left to fix.

ok, seems its like
Keep the rest of the entries there. Things like status words are important
Also make sure the total bits adds up to 32, pad out unused ones
 

type:
ethercat pdos > pdos.txt
ethercat sdos > sdos.txt
and share the output here.

Probably something like

You don't need bitslice, just do it in the xml  NOte there are some unused bits in this example

Got the inputs figured out.

1.  Program drive so all inputs are 'no function assigned'

2. Change xml input address HAL name:
3. Add bitslice to HAL, using the bit chart from the servo manual:
Now I can press buttons connected to the drive and all five inputs react in halshow.  Rather exciting...

Next step is to see if I can fumble through changing the PDOs to 'fixed' and somehow map the outputs.

Anyone have a clue what 'sub-index 1' means?
 

That sounds like the noise produced when synchronization is lost during motion. My solution was to change the parameters to `refClockSyncCycles="-1" sync0Cycle="*2"`. After making this adjustment, I no longer experienced any synchronization loss. I am using an Inovance SV660N drive. You can also add the following line to the XML configuration to monitor the number of synchronization loss events: `<pdoEntry idx="200e" subIdx="19" bitLen="16" halPin="SyncLossCount" halType="s32" />`.


The entry `<pdoEntry idx="200e" subIdx="19" bitLen="16" halPin="SyncLossCount" halType="s32" />` is effective only for Inovance SV series drives; it cannot be used with other drive models.

VEICHI SD700 EtherCAT — Er.960 on startup, clears after few F2 presses — why?Platform: LinuxCNC 2.9.8, Debian, kernel 6.12.57+deb13-rt-amd64 (PREEMPT_RT) Drive: VEICHI SD700 EtherCAT servo drive (firmware V1.2) Interface: linuxcnc-ethercat (lcec) with cia402 component Mode: CSP (Cyclic Synchronous Position), 1ms servo periodWhat's happeningEvery time I start LinuxCNC, the drive shows Er.960 (SYNC0 synchronous frame loss) for the first 15-30 seconds. During this time pressing F2 gives: After pressing F2 several times over 15-30 seconds, the drive eventually shows "88" (operating state), I hear a click from the motor, and everything works fine after that — jogging, position feedback, motion programs all stable.My question is: why does Er.960 appear at startup and what is actually happening when F2 eventually causes it to go away?System latencyThis is likely relevant. My machine is an AMD Ryzen system on a Shenzhen Meigao generic motherboard. Latency-test shows: I have tried:

• CPU governor set to performance
• C-states disabled via cpupower
• nomodeset (amdgpu blacklisted)
• isolcpus, nohz_full, rcu_nocbs kernel parameters
• idle=poll

None brought jitter below ~80µs — likely SMM interrupts from locked-down BIOS on this generic hardware.Current workaroundUsing (500µs) in dcConf which helps the drive lock faster but doesn't eliminate the startup Er.960 completely.Config filessd700.xml sd700.hal sd700.ini Specific questions

1. Is Er.960 at startup expected behavior on a high-jitter system while DC sync is being acquired, or does it indicate a configuration problem?
2. Why does pressing F2 (which sends CIA402 enable controlword) help the drive clear Er.960 and lock onto DC sync? I would not expect an application-layer command to affect DC sync acquisition.
3. Is there a way to make the drive more tolerant of sync frame jitter during the initial lock-in period — either via SDO parameters or lcec config?
4. Would increasing
   Code:

   refClockSyncCycles
   help, and what is the recommended value for a high-jitter system?
5. Is there a known-good
   Code:

   sync0Shift
   formula based on measured max jitter? (e.g. shift = 2x max jitter?)

Any insight appreciated. The system works well once locked — just trying to understand the startup behavior and ideally make it more reliable.

@andrax
I appreciate your help and efforts on the topic. Actually, this was my working configuration, I just added the additional rows in .ini and .hal files as per you absolute encoder guide topic.

The "sdoConfig" line for 0x6098 is there to set the homing method of the drive. I added it before looking at your guide. It simply sets homing mode 34 - index pulse.

What do you mean by the wrong naming convention? You stated the halpin "opmode". Did I write it wrong or is the data type of signed 32 wrong? As per servo manual, it is an 8 bit variable but LinuxCNC expects it as signed 32.

I did not use the "name" attribute for the EtherCAT slave in the .xml, instead I use the slave ID number in the .hal file.

Would elaborate more on what is wrong the .xml file? I can get the .ini and .hal files from you absolute encoder tutorial but there is no .xml file there. That is why I ask about my errors in the .xml file.