Advanced Search

Hi, just a note if you tryto use the on-screen keyboard, this will not work.  It results in:

This is due to an unmet dependency.  is included, but not .  Install that package also and onboard will then work.

grandixximo wrote:

@atsu

Your servo drivers support a period of 1250000

????

Yes, they should. The manual states the following:

In the work mode, the synchronization cycle must be an integer multiple of 125 μs. Otherwise, the servo
drive will report Er74.0 (EtherCAT synchronization cycle setting is incorrect.)

Initially, I ran the drives with a period of 1000000 ns, but increased it to the current value couple months ago. Did it because in some rare instances I got "Unexpected realtime delay on task 0 with period 1000000" error in UI. I can try lowering it back to 1000000 ns to see if it makes any difference.

@TAKUYA

I see that you did not set pdo 1600 for your X drive was this on purpose?

I don't think the EK1100 needs the dconf line at all, but that should not effect, your DC seems ok, can you open the halscope, plot pll_err and app_phase? also servo-thread

also Sync0Shift should be half or 30% your cycle time, not 0
 

forgot to mention granite devices have a good article about feedback systems and even mentions Linuxcnc
granitedevices.com/wiki/Dual-loop_feedback_position_control 

@atsu

Your servo drivers support a period of 1250000

????

Hi ihavenofish,

I am also in process of retrofitting a TC225, however I am in a different situation where the machine was completely gutted and I am starting from (almost) scratch. When you get a chance could you send us that pinout? I have the Oriental Motor brake pack and gear motor and am confident in that part, but I haven't been able to find any information on the encoder. All I have right now is a harness that has 8 wires with the following labels: 49, 50, 51, 52, 53, 54, 55, and E. My next step was to start probing each wire to determine which ones are 0V, +24V, and the 4 BCD signals. E is obviously earth ground.

I appreciate it!
Jeff

Do not fight the paradigm to avoid a world of pain.
To say you have open loop is not correct. your encoder output should be fully wired in so you do have a feedback loop. Some machines have a dual feedback loop with the motor encoder configured in velocity mode inner loop and optional linear scales configured in position mode as the outer loop.

There are many closed loop stepper motors with encoders and a few also have an index signal. Usually the dual feedback system connects the motor encoder velocity feedback to the drive and the position feedback to linuxcnc.

I have never had drives with index marks but my uderstanding  is that linuxcnc can search for a home switch, then move to the nearest index pulse before completing homing. Ethercat drives that home internally are different animal altogether

The new PR with comp kinematics support for TP2 will have artifact debs at the end of this link

github.com/LinuxCNC/linuxcnc/actions/runs/23100211514?pr=3807

Yes, this is one of the reasons why I ditched Rufus and now exclusively use and recommend  balena etcher on all platforms

If your 7i92 doesn't have a free input for the Z signal, that's too bad. I'd recommend upgrading so you have more inputs. Alternatively, you can set HOME_USE_INDEX = No, and then LinuxCNC will use the home switch for reference. However, this is less accurate.

automata wrote:

Hi grandixximo,
Congratulations on a viable solution to this long standing gap in Linuxcnc implementation.
I was going through how you have taken into account the kinematics in userspace for planning which is needed for kinematics bounds checking.
I also see that you have made the relevant changes in the kinematics defined in src/emc/kinematics/* files.
There is another set of switchable kinematics defined in the src/hal/components/*.comp files (method made viable by David Muller / aciera on this forum). For example xyzab_tdr_kins.comp, xyzacb_trsrn.comp etc.,
I somehow find the idea of implementing the kinematics as a loadable .comp module compiled by halcompile very fascinating and useful
Is there a guideline on how to transition those kinematics also to this new setup?
-automata

Hi automata,

Good question — the .comp-based kinematics (like xyzab_tdr_kins.comp, xyzacb_trsrn.comp, etc.) were missing planner type 2 support because halcompile doesn't generate the nonrt_attach() entry point or the shared-memory parameter bridge that the userspace planner needs.
I've added a glue header (comp_kins_uspace.h) that makes the conversion straightforward without having to rewrite the .comp as a hand-written .c file. The idea: HAL pin values are mirrored into shared memory by the RT module each servo cycle, and the userspace planner reads a consistent snapshot from there instead of touching HAL pins.
The conversion is 5 mechanical steps:

#include "comp_kins_uspace.h"

Call comp_kins_uspace_setup(comp_id, "mykins", num_joints, "XYZAB") in your setup function after hal_ready()

Replace each *(haldata->pin) with KINS_READ(haldata->pin, N) where N is a unique index per parameter

Bracket kinematicsForward/kinematicsInverse with COMP_KINS_BEGIN(haldata) / COMP_KINS_END()

Add COMP_KINS_NONRT_ATTACH("mykins") at the end of the file

For switchable kins, also sync the switch type with COMP_KINS_SET_SWITCH_TYPE() in kinematicsSwitch().
xyzab_tdr_kins.comp has been converted as a reference example — look for the lines marked with +++ comments. The kinematics docs (docs/src/motion/kinematics.adoc) now have a full section on this with annotated code examples.

Hello
Please see the attached Files.

Thanks for looking through them.

~Takuya

Thank you for taking the time to go through the messages from the last few days. I suspected as much, the AI's "fix" wasn't really anything useful.

Regarding the first slave lacking DC, you are correct. I actually changed the order of slaves in the chain yesterday so that the A6 servos are now defined first. They do have assignActivate defined. However, that change didn't make any difference to the dc-phased pin or the pll-*** pins.

I have attached my ethercat-conf.xml along with HAL and INI files if they are of any help.

ethercat master command after LinuxCNC has started:

Master0
  Phase: Operation
  Active: yes
  Slaves: 6
  Ethernet devices:
    Main: 10:60:4b:5b:58:34 (attached)
      Link: UP
      Tx frames:   146273
      Tx bytes:    9824436
      Rx frames:   146272
      Rx bytes:    9824318
      Tx errors:   0
      Tx frame rate [1/s]:    800    709    308
      Tx rate [KByte/s]:     93.7   84.1   32.2
      Rx frame rate [1/s]:    800    709    308
      Rx rate [KByte/s]:     93.7   84.1   32.2
    Common:
      Tx frames:   146273
      Tx bytes:    9824436
      Rx frames:   146272
      Rx bytes:    9824318
      Lost frames: 0
      Tx frame rate [1/s]:    800    709    308
      Tx rate [KByte/s]:     93.7   84.1   32.2
      Rx frame rate [1/s]:    800    709    308
      Rx rate [KByte/s]:     93.7   84.1   32.2
      Loss rate [1/s]:          0     -0      0
      Frame loss [%]:         0.0   -0.0    0.0
  Distributed clocks:
    Reference clock:   Slave 0
    DC reference time: 826802114159640000
    Application time:  826802133398422723
                       2026-03-14 11:15:33.398422723

@TAKUYA
@Atsu

Please share your full XML
and the output of ethercat master command after you have started linuxcnc

Atsu wrote:

Experienced some jitter as well today while running grandixximo's fork. I doubt there is any synchronization being done while the dc-phased pin is false and all pll-*** pins are 0. Ran sudo dmesg to see what is happening in the background. Maybe someone can notice something clear in the log:

During startup:
[  801.691210] EtherCAT: Requesting master 0...
[  801.691215] EtherCAT: Successfully requested master 0.
[  801.691915] EtherCAT 0: Domain0: Logical address 0x00000000, 74 byte, expected working counter 12.
[  801.691918] EtherCAT 0:   Datagram domain0-0-main: Logical offset 0x00000000, 74 byte, type LRW.
[  801.691932] EtherCAT 0: Master thread exited.
[  801.691933] EtherCAT 0: Starting EtherCAT-OP thread.
[  801.691970] EtherCAT WARNING 0: 1 datagram UNMATCHED!

During operation:
[  807.424674] EtherCAT WARNING 0-1: Slave did not sync after 5000 ms.
[  808.944250] EtherCAT 0: Slave states on main device: OP.

During shutdown:
[  841.183382] EtherCAT 0: Master thread exited.
[  841.183401] EtherCAT 0: Starting EtherCAT-IDLE thread.
[  841.183449] EtherCAT ERROR 0-0: Failed to receive AL state datagram: Datagram initialized.
[  841.183462] EtherCAT 0: Releasing master...
[  841.183464] EtherCAT 0: Released.
[  841.188247] EtherCAT 0: Slave states on main device: SAFEOP, OP + ERROR.
[  841.196539] EtherCAT ERROR 0-0: AL status message 0x001A: "Synchronization error".
[  841.197317] EtherCAT 0-0: Acknowledged state SAFEOP.
[  841.208612] EtherCAT ERROR 0-1: AL status message 0x001A: "Synchronization error".
[  841.209116] EtherCAT 0-1: Acknowledged state SAFEOP.
[  841.220587] EtherCAT ERROR 0-2: AL status message 0x001A: "Synchronization error".
[  841.221590] EtherCAT 0-2: Acknowledged state SAFEOP.
[  841.256274] EtherCAT 0: Slave states on main device: PREOP.
[  841.828318] EtherCAT WARNING: Datagram 0000000031def7fe (master-fsm) was SKIPPED 1 time.
 

This seems a similar issue, please share your XML file
also send this command 

ethercat master

and share the output
the output should look something like

Master0
  Phase: Operation
  Active: yes
  Slaves: 12
  Ethernet devices:
    Main: 88:03:8f:28:ca:33 (attached)
      Link: UP
      Tx frames:   78788870
      Tx bytes:    65756113151
      Rx frames:   78788869
      Rx bytes:    65756112300
      Tx errors:   0
      Tx frame rate [1/s]:   1000   1000   1000
      Tx rate [KByte/s]:    822.0  822.0  821.9
      Rx frame rate [1/s]:   1000   1000   1000
      Rx rate [KByte/s]:    822.0  822.0  821.9
    Common:
      Tx frames:   78788870
      Tx bytes:    65756113151
      Rx frames:   78788869
      Rx bytes:    65756112300
      Lost frames: 0
      Tx frame rate [1/s]:   1000   1000   1000
      Tx rate [KByte/s]:    822.0  822.0  821.9
      Rx frame rate [1/s]:   1000   1000   1000
      Rx rate [KByte/s]:    822.0  822.0  821.9
      Loss rate [1/s]:          0     -0      0
      Frame loss [%]:         0.0   -0.0    0.0
  Distributed clocks:
    Reference clock:   Slave 0
    DC reference time: 826799805203739108
    Application time:  826800839056809695
                       2026-03-14 10:53:59.056809695