You are doing awesome things, I plan to start testing Riosub in the near future, hopefully I can contribute something useful !

I don’t have anything in those files. I’m very new to Linuxcnc so maybe I missed a step somewhere to set those files up? 

Moin,
ich würde gerne die ena+ und ena- Eingänge meiner Leadshine DM856 bei einer Mesa 7i76e beschalten. Wenn ihr euch die Anhänge anseht... nach welcher Schaltung muss das geschehen? Spontan würde ich nach PNP sagen... nur ist das richtig?
 

Wow, wow and wow! Great job. Thank you so much image missing /media/kunena/emoticons/smile.png

I get the same error there too (see image).

Would it be possible to activate debug mode in the configuration? This will generate a more detailed error message, which may be more helpful.

PS: If you would prefer me to write in English, please let me know. I'm happy to do so, as I'm the one with the problem, not you. 

 

Vorher wurde durch die Steuerung ja über die Glasmasstäbe positioniert, da war das Umkehrspiel weniger ein Problem weil die Steuerung das für die Positionierung ausgeglichen hat, wenn man bei den wirkenden Kräften (Gleichlauf-, Gegenlauffräsen) und der Anfahrrichtung aufpasst lässt sich trotz Umkehrspiel relativ genau arbeiten.
Meine Aussage hat sich vorallem auf den Motor Encoder bezogen, der würde die Ungenauikeit ja nicht mitbekommen. Wenn die Anzeige der Heidenhain Steuerung noch geht, kannst du ja damit auch erstmal abschätzen "wie schlimm" es ist und dann immer noch Umbauen auf einlesen der Masstäbe.
Welchen Servoantreib und Umrichter hat du den verbaut? Wenn du da einfach an die Encoder Informationen kommst sollte der Aufwand das zu testen ja nicht allzu groß sein.

Marcos DC wrote:

To prepare proper adapter templates for your two drives (the Lichuan OL57E-4A and the Stepperonline A6-750EC), I just need a few details from your setup so I can map the HAL pins correctly.

If possible, could you share:
1. Your LCEC configuration
• lcec.conf (or equivalent configuration file)
• The EtherCAT XML/ENI if you have it
• Or a snippet of the HAL where the lcec.* pins for the drives appear
2. PDO mapping
I mainly need to confirm the HAL pins for the standard CiA402 objects:
• 6040 Controlword
• 6041 Statusword
• 6060 Modes of Operation (command)
• 6061 Modes of Operation Display
If available in PDO as well:
• 6064 Position Actual Value
• 607A Target Position
3. Homing
• Which homing method (object 6098) you plan to use
• Whether the homing/limit switches are connected to the drive inputs
• The HAL pin names for those inputs (for example lcec.*.din-*)
4. Quick Stop
• Is Quick Stop (Controlword 0x0002) configured and usable on these drives?
• Or do they require a different shutdown sequence?
5. Anything unusual
• Any known quirks with enable, fault reset, or homing behavior.

 

Later tomorrow I should be able to gather some of the info you requested. I know I will have hal pins, lcec.conf, PDO/SDO, and a terminal log from test driving these servos.

I have not looked at CiA402 homing at all yet, I will take a quick look at the manual to check whether I have a preference which homing method I'd use.

One potential quirk I noticed with the Lichuan OL57E-4A was if I test drive it in velocity mode (I was typing hal commands at the terminal) I then can momentarily disconnect the servo amplifier power, shutting down the servo amplifier and resulting in a flood of ethercat error logs in dmesg, in a second or two the drive recovers and ethercat reconnects, and the motors resume rotating at the velocity I had previously set in lcec.

This is hardly a problem, as we will be running in position control mode. I expect a servo drop-out like that would at least trigger a following error in a standard linuxcnc config. It did not do that here as I was just running simple hal commands in the terminal directly to lcec without using CiA402.

Sam was working on this a few years ago.
Look at this.


It might help.

OK I'll do this tomorrow

99%. Allready flashed it with original 7i92 bit file downloaded from mesa store support zip files. File attached was modified from that zip also.

Thanks, with this component I was able to extract the bits I needed.

Small clarification regarding the README

After reading the feedback I realized that one part of the README may have been ambiguous, especially the section mentioning “Gantry Support” and gantry_manager.comp.

To clarify the intent of the project:

The goal of this repository is not to introduce a new motion or gantry control layer in HAL. Final gantry squaring, coordinated homing and axis relationships are expected to remain in the motion / kinematics layer (e.g. trivkins) as usual.

The purpose of the HAL components in this project is limited to:

separating CiA402 semantics from the transport layer (LCEC / EtherCAT)

providing a deterministic controlword composition path

adding safety gating

optionally handling decouple/recouple situations when a drive performs internal motion (for example CiA402 homing), to avoid command/feedback discontinuities

So any future “coupler” component would only handle safe transition and coupling of drive states, not replace motion-level gantry logic.

I will update the README to make this clearer.

Thanks for the feedback. Just to clarify an important point that I may not have emphasized clearly:

All components in the current tests run in the same servo-thread at 1 kHz, with a fixed execution order using addf. For example:

safety → pds_manager → procedure (UT) → controlword composer → driver interface

Because of this, execution is deterministic. In HAL this effectively becomes a sequential call chain within the same realtime cycle.

Also, there is only one writer for the final 6040 controlword, produced by the controlword composer, which avoids the typical “multiple writers” problem that often causes ambiguous state transitions.

In HAL, race conditions are caused by multiple threads or multiple writers, not by the number of components.

Regarding gantry and coupling: I agree that final squaring and coordinated homing logic belongs in the motion/kinematics layer. If a coupler is introduced on the HAL side it would only serve a limited purpose — handling safe decouple/recouple situations when the drive performs internal motion (for example CiA402 homing) to avoid command/feedback jumps. It would not replace motion’s gantry or homing logic.

Interestingly, the recent HOME_ABSOLUTE_ENCODER fix in motion (PR #3774) also highlights a similar concern about maintaining internal consistency when offsets are applied during homing. In that patch the motion code re-normalizes pos_cmd, pos_fb, free_tp.curr_pos, and motor_offset to avoid accumulated offsets during re-homing. Conceptually this looks similar to a recoupling step inside the motion layer to keep controller and physical states aligned.

The goal here is not to duplicate motion functionality, but simply to keep CiA402 semantics independent from the transport layer (LCEC/EtherCAT) while maintaining a deterministic controlword path.

I can make a (7I92) bitfile but are you sure 7I92 bitfiles will work on that card?