from your latest output, both PDO entries are clearly 16-bit and your XML uses bitLen="16", so that part looks correct.

also, halType="u32" does not mean the PDO is 32-bit. It only affects how the value is exposed in HAL.

it doesn't look like a bit length issue anymore.

given that, I would focus on:

- XML syntax issues (even a small typo can break it, and LinuxCNC may stay silent — checking dmesg helps here)
- verifying that the PDO/SM structure matches exactly what `ethercat pdos` reports
- keeping the mapping minimal until it reaches OP

once it reaches OP, then refine the mapping.

I struggled a lot because it was a topic I didn't understand at all. I added the pdos and the lcec_configgen result, but I didn't understand what kind of structure I was supposed to create.
When 32 bit = 16 bit
ceka@debian:~$ ethercat slave
0 0:0 OP + XINJE-DS5C1 EtherCAT(CoE) Drive Rev4.0 v3.7.70
1 0:1 OP + XINJE-DS5C1 EtherCAT(CoE) Drive Rev4.0 v3.7.70
2 0:2 OP + XINJE-DS5C1 EtherCAT(CoE) Drive Rev4.0 v3.7.70
3 0:3 SAFEOP+ERROR E EM32DX-E4   ????????????????????????????????????????????
ceka@debian:~$

SAFEOP+ERROR E EM32DX-E4

old now

ceka@debian:~$ ethercat pdos
=== Master 0, Slave 3 ===
SM0: PhysAddr 0x1000, DefaultSize  128, ControlRegister 0x26, Enable 1
SM1: PhysAddr 0x1400, DefaultSize  128, ControlRegister 0x22, Enable 1
SM2: PhysAddr 0x1800, DefaultSize    5, ControlRegister 0x64, Enable 1
  RxPDO 0x1600 "RxPDO0-Map"
    PDO entry 0x7000:01, 16 bit, "OUT"
SM3: PhysAddr 0x1c00, DefaultSize    7, ControlRegister 0x20, Enable 1
  TxPDO 0x1a00 "TxPDO1-Map"
    PDO entry 0x6000:01, 16 bit, "IN"
ceka@debian:~$

lcec_configgen
<slave idx="3" type="generic" vid="0x00004321" pid="0x01100073" name="D4">
      <!--EM32DX-E4-->
      <syncManager idx="0" dir="in"/>
      <syncManager idx="1" dir="out"/>
      <syncManager idx="2" dir="out">
        <pdo idx="1600">
          <!--RxPDO0-Map-->
          <pdoEntry idx="7000" subIdx="01" bitLen="16" halPin="out" halType="u32"/>
        </pdo>
      </syncManager>
      <syncManager idx="3" dir="in">
        <pdo idx="1a00">
          <!--TxPDO1-Map-->
          <pdoEntry idx="6000" subIdx="01" bitLen="16" halPin="in" halType="u32"/>
        </pdo>
      </syncManager>
    </slave>
  </master>
</masters>
ceka@debian:~$


Would the `lcec_configgen` command help? Could someone write the correct configuration for me?


 

Always something new to learn. Write-once sdos, ok.
If you aren't too bored of the device you might try with initCmds
if you understand the format of the input file. I struggle there but
there are examples I guess.

I always wonder how to program those things.
Programming I see as the big bottle neck for 5-axis.
The type of machine seems to be of very limited practical use . 


 

Same here. with dual boot things get complicated when I want to replace one OS and keep the other. My fix has been: one hdd = one os.

Just to be safe, I pull all bootable drives and leave only the one connected, to which I'm installing the OS. This greatly reduces my chance of making mistakes when selecting what installs where. My dual boot mini-pc contains two SSD's.

That said, I can see the case for dual booting on one drive, especially if the machine only has one drive slot. Did you see  wiki.debian.org/DualBoot/Windows  ?

Wow!
Two things I see especially:
1. Wireless probe, probably bluetooth.
2. Run the program, providing feedrate override by spinning the jog wheel. Then switch over to programmed feedrate.

I want to use my CNC to make PCB prototypes and just wanted to check if auto-leveling for Probe Basic exists. 

By "auto-leveling" I mean the ability to probe at grid points and modify a gcode file to compensate for an uneven bed/PCB surface.

I have seen some auto-leveling projects compatible with LinuxCNC but not one that is compatible with Probe Basic.

Thanks in advance

Success! I used Ethercat download to set the parameters for one VFD register to measure the bus voltage instead of the ethercat-conf.xml file and I got a reading that changed from time to time. At one stage it was at 321.0 which also showed up on the vfd console. This is meant to be intermediate DC power which should be  1.414 x mains power input. Working backwards, that was 227 volts (should   be 240 volts). So learnings are:
1. Once a SDO is set, it can't be changed
2. You need to set the SDO's via Ethercat download, not via XML
3. SDO's are cleared when the slave is powered off. 

Out of time now but It looks like I'll be able to get this going now. It was frustrating not being able to see anything at all.

Thanks for the help....
 

Yes, it certainly pays to get a quote from Beckhoff first. Some of their modules are really cheap and others like encoders 5151 etc al are expensive here in Australia.

I've finally got to a stage I never need to boot windows again. But what i've always done is install a second SSD/HDD and instal Linux to it. Then select what drive to boot from using the BIOS boot menu.

I did once have a dual boot laptop using grub but the system got its knickers in a knot and I lost everything so have never wanted to risk it again.

SO when uploading an SDO in dmesg, I get 
SDO download aborted
Unsupported access to an object 

I mighht try configuring with ethercat download commands before starting. Wierd

I've actually got bigger problems here now.  I am not getting proper communication between linuxcnc's lcec driver and the ethercat slave.

I don't have any errors on startup but if I toggle an output from halshow, the light comes on in halshow but the actual state does not change on the device. This worked previously but on a different config. eg, this no longer toggles the physical outputs.


I can set the same output pins on and off using the ethercat upload and download commands.
I Stripped out all of the SDO commands for modbus but it is still not working. Not sure how to resolve this issue.

Ahh, now I have it working again. dmesg showed an error loading my xml but Linuxcnc was silent on this. I missed something! Now I will add stuff back in slowly.

I don't really have anything here like a USB to 485 adapter to test vfd comms with and there are no status lights.

What I have worked out uploading registers is that I have a timeout error and the error count increments all the time

I think I have worked out all the XML syntax and settings.

@ruediger123

The restriction is the corner itself. A sharp corner is a mathematical direction discontinuity. The velocity vector must change by ~191 mm/s across a 45° turn. With a 1ms cycle time, respecting 50 m/s³ jerk would require spreading that change over ~3800 cycles, during which the machine travels nearly a meter. No feed rate fixes this, the problem is geometric.

The only mathematically correct solution within your parameters is for the planner to detect that no valid cornering speed exists that satisfies the jerk limit given the available segment geometry, and fall back to a full stop at the corner. That is exactly G61.1 behavior.

This is actually a valid point and potentially a missing feature: the junction velocity calculation should be jerk-aware, and when the jerk-constrained cornering speed rounds down to zero, the planner should stop rather than arrive too fast and spike. Currently it may only be acceleration-aware at the junction, which allows a non-zero entry speed that looks acceptable to the acceleration limit but still violates jerk because the ramp does not fit in the available geometry.

The practical workaround in the meantime is either G61.1 explicitly, or a P tolerance of several mm to give the planner room for a proper S-curve through the corner. P0.01 is geometrically equivalent to sharp.

This is not really an XML problem.

The XML is just a configuration layer for PDO mapping.

What you actually need to understand is:

PDO structure (Rx/Tx)
Sync managers
How lcec interprets the XML

A good workflow is:

1 - Use ethercat pdos to discover the device
2 - Reproduce exactly the same structure in XML
3 - Only then refine HAL mapping

Quick question:

Your device reports:
PDO entry 0x6000:01, 16 bit

But in your XML you configured:
bitLen="32"

What do you think happens if the device expects 16 bits,
but the master tries to map 32 bits?

Also, check this:

<pdo idx="0x1a00,">
<pdoEntry idx="0x6000,">

Notice anything unusual there?

I would suggest:
- match the bit length exactly (16)
- remove the trailing commas
- start with a minimal mapping (no complexEntry)

Once it reaches OP, then split into bits.