Advanced Search

The Probe Basic Lathe screen in full-screen mode is cut off and doesn’t display completely, which is a bit annoying.

Another issue I’m seeing is that the on-screen keys stop working after referencing the machine, and I have to home it again to get them working.
Also, the arrow keys only respond when clicking with the mouse in certain specific areas.To have the spindle rotate at a default speed of X RPM, I set, but without success. When I press the Forward button, it spins by default at a very low RPM.
Finally, for some reason, the subroutines don’t work at all.I’m running the latest update and have replaced the Probe Basic Lathe folders.
 

Hi,

we worked with the hal scope today.
 

Used the mpg today, sadly it crashed again. Loops = 10.

I actually opened an issue on github now over two years ago github.com/LinuxCNC/linuxcnc/issues/2237
No resolution. I never made a serious attempt to understand the code structure of the component.
Just looked at what was going on around the triggered assert() and made some more or less random changes.

Where is the blocking call? I'll see if I can do some ... tests.

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!!!