Advanced Search

I don't know where this idea comes from that you need any coding skills to setup Linuxcnc. This is one of the biggest lies attributed to Linuxcnc (Linux in general), it's bullshyte. You don't need to be a coder, even to type instructions at a terminal, no one ever said you need to be a coder to use MSDOS. That was the point of a OS to enable the system to be used by "non computer people" as well as a lot of abstraction & a million other things.

Setting up Linuxcnc for a basic 3 axis mill take no time at all using the Linuxcnc supplied config tools. Whether it's a parallel port or 7i92 based system. The biggest issue I see users have is not paying attention to the errors reported in the error report, things like pin xx doesn't exist, usually it's a typo. Or a user expecting a pin to exist that doesn't. Realtime errors are a PC issue, not really a Linuxcnc config issue.

Whether you axis, gmoccapy or your "grbl module" (whic I think will be a performnce hit in a bad way) you will still need to setup a linuxcnc config, the very thing you've been mentioning.

If you want to use grbl use it, but Linuxcnc is a completely different beast, but don't expect any grbl functionality from Linuxcnc.

Mesa, LlinuxcncRIO & Remora all work along a similar concept, step & direction signal generation is off loaded to the external motion control card.

I don't know why you would want to send a gcode file line by line to linuxcnc when it can open and read the file directly.

One thing that is very intriguing, you admit to poor coding skills, yet propose some major replacement of the Linuxcnc internal workings.

In reality all grbl is is a way to send data via a serial port.

Thank you! Your's was exactly the voice of experience I was hoping to hear from.

I love/hate LinuxCNC. On the one hand, I spent hours last night trying to figure out how to get my USB gamepad "wand", which worked fine under 2.7.4, to work reliably under 2.9. On the other hand, it's likely that Grbl/FluidNC wouldn't support the gamepad at all.

I've wondered, too, about whether the Grbl comm protocol could be implemented on the front of LinuxCNC. I know the folks driving industrial mills would be horrified, but it might be a good solution in some cases.

Again, thanks for the feedback.

I have a LinuxCNC image running on a CM4/eMMC, so it should also work on the Pi5.

Hello
I put my pi 5 into operation yesterday.
Unfortunately I get the locale error with Pconf

I tried to use the same settings as you.
My keyboard is german

Do you have an idea?

I have added the missing part to the INI file and change basic_probe.py, probe_routines.py and probe_subprog.py to the original files from v2.9 from github.

After performing additional measurements, it appears that the issue of bad synchronization between the measurement process and data updating in the widget mainly occurs when the feedrate value changes during probing. If the value remains stable throughout the measurement, the probe measurement cycle completes correctly.

The video shows four consecutive measurements:

• The first measurement was completed without issues.
• In the second measurement –> at 37 seconds in the video, the feedrate oscillate from 52% to 51% and back during the probe measurement, after which the value in the table for the Z axis changed. However, the measurement had not yet been completed.
• The third measurement –> similarly to the second, at 1:06 the feedrate oscillate from 40% to 41% (a very quick oscillation), after which the value on the axis Z changed.
• The fourth measurement was completed without issues (no feedrate oscillation).

Do you have any idea how a change in feedrate could affect the value update in the widget?

The Radxa Zero 3E is a nice small SBC very similar to the Pi Zero but available with more RAM and an ethernet connector. You don't want to use it for step generation, but with the latest Armbian running a 6.12 RT kernel, the latency is ok, especially for a headless motion controller running a servo-thread. Could be interesting for example in a OpenPNP setup. One problem is that USB is not working with current kernel, but this will probably be fixed soon.

Yesterday I ran a G1F1X100 command with 6 TMC5160 connected over SPI @ 6MHz and spidev driver; the servo-thread (reading all 6 position, writing all 6 speed, only one PID) stayed under 0.75 ms for the entire 100 minutes.

I retrofitted my first engraver with GRBL; took an Arduino nano, read the manual for 3 hours, connected everything in 2 more hours and had a working system that I used till my spindle controller card burned while milling a pcb... I then retrofitted a small desktop mill and went this time for GrblESP32, which became FluidNC later. Again, the set up was quick, efficient and functional.

I started to read about LinuxCNC when I was trying to use TMC5160 stepper with their internal motion controller rather than with step/dir signal. For me this could be the first big difference; if you look for a G-Code interpreter to generate up to 6 axis step/dir signal at a fairly high frequency and need the standard Start/Stop/Pause inputs, then go for Grbl-like system. If you need more complex interaction with hardware, then LinuxCNC is the answer.

The second big difference is probably the difficulty; maybe not the best example, but after several months I still don't have a working system. But to be fair, it has a lot to do with my poor coding skills, and the fact that my mill is currently working well under FluidNC. Anyway, even for a standard project, you will have to find a reliable step generator (PC-based or external), find the correct configuration, adapt the INI and hal files, choose a GUI. There are many options and that's fantastic, but it takes time to figure everything out. FluidNC works on ESP32 and uses one config file. That's it.

Speaking of figuring things out, this forum is certainly the third big difference; yes, FluidNC has a nice wiki, yes 3D printing Grbl-like systems like Klipper, Marlin, etc have also a lot of users and forums. But this forum is a real gold mine and there are so many different information about so many different subject that you can spend hours here without thinking about your mill. Congratulations guys!

The fourth and for now last difference I'll mention is the GUI; as said before, Grbl-like systems are G-Code interpreters and they do not offer any user interface. So one option is to use none and just put your G-Code on a SD card and start it with a button or a small touch screen, or to connect an external PC that will host the GUI. There are different existing software and I don't know them all; I use bCNC and tried UGS. They are very fine for simple setups, to home machine, use camera for alignment, Z and tool probe, etc.

In my current project, I try to use LinuxCNC on a Radxa Zero 3E as a headless 6-axis motion controller. For this, it would be fantastic to have a module similar to linuxcncrsh but "speaking" Grbl standard; I could use any of those existing G-Code sender with my LinuxCNC board. On the other hand, the Remora component use external micro controller to generate steps/dir signals, but in theory, a Grbl component could completely replace the EMCMot+Stepgen components in LinuxCNC for stepper motors signal generation.

One more question about HAL pin for fast/slow button. In the example there was this function to call, but it doesn't work as toggle, but as momentary.

Is it possible to make it toggle or is it only done in hal? And how can I know the status of this button? I want to change the step depending on the speed, because now at low speed the step is too big.

My brain is confused.
The sequence in the OP doesn't work.

The only reliable way I can set the machine up is to MDI a G0 with axes values per the Parameters (with the steppers off).

Still trying,
John.

rigid tapping needs reversal of spindle so backlash matters.
If i have encoder on spindle shaft backlash
will be problem?
How many lines encoder needed for rigid tapping?

Oh thanks a lot, your code example was very helpful. I just started learning python and my level so far is “monkey see, monkey do” Without a concrete example it's hard for me to understand exactly how to do it. Now I can find my mistake, I tried it for one slider, the values are changed and saved.

tristate_bit and tristate_float are the names of the hal components,
but tristate-bit.n.xxxx and tristate-float.N.xxxx are the names of the function
and hal pins that the component exports.

tristate_bit works on bits where tristate_float works on floating point numbers.

I looked at the sim config an edited a mesa config to add the new TP, but it does
show major acceleration spikes (~500K)  lasting 1 servo period. I needed to set
large  following error limits  to avoid the spike triggering a following error.

Note that this is not hardware related but may have a relation to scaling so I can try again
by modifying the sim config to make sure everything else remains the same.
 

Now taking an interest in the G10 L2/L20 pair of Gcodes.
Cannot make sense of the Documentation against the machine display.
My current job is positioned with its G54 origin having x, y, z values -ve relative to Home.

Parameters #5221, #5222, #5223 are documented as the coordinate system Offsets for G54.
The parameters in the linuxcnc.var file correctly show the G54 origin with -ve values.

But, to set up the machine correctly, I have to swap the signs used with a G10 L2.

When Gmoccapy launches, before homing, the DRO shows the tool position with +ve values.
Then G10 L2 P1 with +ve values loads the DRO with -ve values (CORRECT for this job).

Then conventional Touch-Off and run the job.

Please, is my brained screwed, or is the Documentation misleading ?

John.

Read the online documentation for V 2.9  for "homing configuration" (Several times)
the HOME_SEQUENCE parameter for each side of the gantry must be the same and it must be negative to tell Linuxcnc to treat it as a joint axis.