Advanced Search

Finished the mod for qtdragon, which adds HAL pin encoders for all sliders, jog on all axes, increments, and MPG.

Add HAL pins for XYZABC axis jog:

qtdragon.jog.axis.x.plus
qtdragon.jog.axis.x.minus
qtdragon.jog.axis.y.plus
qtdragon.jog.axis.y.minus
qtdragon.jog.axis.z.plus
qtdragon.jog.axis.z.minus
qtdragon.jog.axis.a.plus
qtdragon.jog.axis.a.minus
qtdragon.jog.axis.b.plus
qtdragon.jog.axis.b.minus
qtdragon.jog.axis.c.plus
qtdragon.jog.axis.c.minus

For example, following pins are available for feedrate slider:

qtdragon.feed.override.count-enable = HAL_BIT, IN must be TRUE to enable feedrate counts
qtdragon.feed.override.counts = HAL_S32, IN encoder input for change feed override
qtdragon.feed.override.btn-100 = HAL_BIT, IN reset to feed override to 100%
qtdragon.feed.override.step = HAL_S32, IN increase/decrease step as a % of the maximum value

For sliders JOG_RATE and ANGULAR_JOG add pins to toggle between fast and slow jogging:

qtdragon.jog.override-linear.turtle = HAL_BIT IN decrease jogging in 10 times
qtdragon.jog.override-linear.turtle-led = HAL_BIT, OUT indicated slow mode is on
qtdragon.jog.override-angular.turtle = HAL_BIT IN decrease angular jogging in 10 times
qtdragon.jog.override-angular.turtle-led = HAL_BIT, OUT indicated angular jogging slow mode is on

Add HAL pins for MPG:

qtdragon.mpg.mpg-enable = HAL_BIT, IN must be TRUE to enable MPG counts

Jog increments pins, used first 3 INCREMENTS from ini file:
qtdragon.mpg.mpg-inc.1 = HAL_BIT, IN
qtdragon.mpg.mpg-inc.2 = HAL_BIT, IN
qtdragon.mpg.mpg-inc.3 = HAL_BIT, IN

For angular axis used next pins, also first 3 value from ini:
qtdragon.mpg.mpg-angular-inc.1 = HAL_BIT, IN
qtdragon.mpg.mpg-angular-inc.2 = HAL_BIT, IN
qtdragon.mpg.mpg-angular-inc.3 = HAL_BIT, IN

Pins for axis selected:
qtdragon.mpg.axis.x = HAL_BIT, IN
qtdragon.mpg.axis.y = HAL_BIT, IN
qtdragon.mpg.axis.z = HAL_BIT, IN
qtdragon.mpg.axis.a = HAL_BIT, IN
qtdragon.mpg.axis.b = HAL_BIT, IN
qtdragon.mpg.axis.c = HAL_BIT, IN

MPG encoder pin:

qtdragon.mpg.encoder-count = HAL_S32, IN MPG encoder input

Add a pins to cycle change increments:
qtdragon.mpg.mpg-inc.cycle = HAL_BIT, IN
qtdragon.mpg.mpg-angular-inc.cycle = HAL_BIT, IN

Put this file into <YOUR CONFIG FOLDER>/qtvcp/screens/qtdragon_hd/. Tested on qtdragon_hd, but should be working on qtdragon too.

I think to that there are some mistakes what I have done.

Hi all,

I'm trying to compile Remora for RP2040 from source and I have some issues. There were some compiling errors that I could solve (in the ioLibrary one #include <string.h> was missing and the ftp_getc function call was throwing an error, so I commented it out), but I'm still having problems to make it run. I can ping the pico and upload a configuration, but when I start lcnc and reset the e-stop, there are a few (5-10) packets exchange and then I have a Ethernet error. If I turn on usb serial port on the pico I can see that it goes in Running state, then resets and go back in Idle state. So first guess is that there is some problem with the ethernet communication.

The thing is that if I load the firmware remora-rp2040-2.0.0 from the repository, I can reset the e-stop in lcnc without problems. So I exclude any hardware/wiring or configuration/component problem.

Can maybe someone point me in the right direction for this problem? Was the rp2040-2.0.0 firmware compiled with the source code on the repo? Could it be an issue with the ioLibrary as it is the one throwing errors on compilation? Or did I miss a configuration in the CMakeLists or in configuration.h? (I'm using a pico board with a W5500 ethernet over SPI chip, connected on pins 16-20)

Thanks in advance,
Luca

is that it explicitly acknowledges this: during CiA-402 internal homing, the drive is not under LinuxCNC’s trajectory control. The component tries to temporarily decouple LinuxCNC from the position loop (by keepingpos_cmd
in sync withpos_fb
) while the drive is homing, and then re-synchronize afterwards. 

Ah, that would explain the strange behavior where the servos jump after homing, leading to error E87.1.

Wie ich schon sagte, du bist nicht der einzige der das Problem hat. Aus irgendeinem einem Grund bekommen die servos nach dem homing einen Fahrbefehl, der zu dem Fehler führt. Bei mir hat geholfen das Handrad abschalten.
Zusätzlich habe ich eine sehr niedrige homing Geschwindigkeit und ich habe die joggeschwindigkeit auf 6mm/min als Grundeinstellung. 

hey, danke für die schnelle antwort, macht bei mir aber leider keinen unterschied. könnstest du vielleich nochmal über meine config drüber schauen ob dir was auffallen tut? Wäre dir echt dankbar

Thank you for reporting back.

thank you!

Willkommen in Club.
Schalte das Handrad erst nach dem homing ein.

Danke, habe mit deiner config hab ich die paar fehler in meiner config gefunden. Habe nur noch ein kleines problem, nach dem homing springen die motoren beim modus umschalten (automatisch von linux cnc von 6 auf 8) schlagartig an eine andere position, dadurch ensteht beim mir im drive öffters der Fehler E87.1, hast du das problem auch? wenn ja wie hast du es gelöst? oder was denkst du was es sein könnte?

LG

Hi all,I spent some time reading through the existing code and examples (,, the Leadshine EL8 example, and rodw’s), plus the available documentation (Yaskawa EtherCAT, some A6/Lichuan docs, and the CiA-402 profile). I don’t have this hardware on my bench, so this is a code/doc-based perspective.One thing that stands out is that the older approaches (,, and the EL8 example) all implicitly assume that LinuxCNC remains the “owner” of the position loop all the time. That works well in modes where LinuxCNC generates the trajectory (CSP/PP/etc.), but it becomes conceptually fragile when the drive performs internal homing and moves on its own. In those cases, the drive is effectively autonomous for a while, and LinuxCNC still tries to reconcilevs, which is where the following-error / desync problems come from. The EL8 example solves this pragmatically for that specific drive, but it’s still a drive-specific adaptation rather than a generic model.What I think is the important architectural step in rodw’sis that it explicitly acknowledges this: during CiA-402 internal homing, the drive is not under LinuxCNC’s trajectory control. The component tries to temporarily decouple LinuxCNC from the position loop (by keepingin sync with) while the drive is homing, and then re-synchronize afterwards. That feels like the right direction conceptually, and it’s a step beyond just adapting one specific drive.Where it still seems incomplete (and this matches Andrax’s point) is robustness: today the logic mainly focuses on “start homing” and “target reached”, but there is no explicit, defensive state machine with timeouts, start/progress checks, and clear fault paths. For a truly generic solution that should also work with obscure or poorly documented CiA-402 drives, it probably needs to be more watchdog- and state-driven, and rely only on the minimal, reasonably guaranteed signals (state transitions, mode display, position change, target reached, fault), rather than assuming specific vendor bit semantics.So, from my point of view, the real problem is not “making it work for A6” or any single brand, but defining a LinuxCNC-centred homing flow where:

• LinuxCNC explicitly steps out of the position-control role during internal homing,
• the process is supervised by a small, defensive state machine with timeouts and error paths,
• and then LinuxCNC is cleanly re-attached to the position loop once the drive reports homing done.

This is all based on reading the code and docs, not on hardware testing, but it seems like rodw’s work is already addressing the right architectural issue, and the next step is mostly about making that flow robust and generic rather than vendor-specific.

Yes that was my problem... thanks a lot!!!

Following this with interest (I had the exact same problem) - my goal was rebuilding the mot2-eth driver. Will review all the advice here when I've had more coffee but PITA if we can't build from a Trixie installation.

Further experimenting seems to have determined the cause of the failure at Grub install

I was performing the install in the workshop where I have wifi access to the internet but no Ethernet connections 
Everytime without fail the install of 2.9.8 failed at the install Grub stage

Now on the same PC with a Ethernet cable plugged in the install ran through without any issues at all

i therefore believe that something critical to installing Grub is missing from the 2.9.8 ISO, as the 2.9.7 iso installed ok WITHOUT the Ethernet cable being plugged in

hopefully this rather time consuming and frustrating experience of installing 2.9.8 will help other following the same path

Thanks to all who replied with ideas, very much appreciated

best regards. Paul

That example shows how to connect the servos to the joints in linuxcnc.
It is done in the same way for all cia402 servo drives.
You do need to modify vid and pid for your specific drives.
You find those numbers in the output of "ethercat slaves -v".

There is of course a lot more like configuring switches, spindle, mpg, hmi, but since you already
have a linuxcnc system running that is no surprise. The same way now.

What can be a differentiator between the servo drives is how to tune the servos.
Is there software for that? How to connect to the drives?
Tuning process? How to store the tuned parameters?