Advanced Search

If you're going to use a CM5 & carrier board you'd be crazy not to use an NVMe drive. It's fast, like really fast. I use one with mine Rpi5.

Hallo,

Kurz zu mir, habe mich heute hier bei euch regestriert weil ich nicht weiter komme und glaube noch öfter hilfe brauch.
Bin der Tom 35Jahre ich habe minimal Linux vorerfahrung, hab ein Prusa MK4 und eine Bernado 550 Dreh Fräs kombi mit nachgerüsteten DRO
Habe die Zahnräder zur Zug-leitspindel hin ausgebaut und will die jetzt mit nen nema24 - cl57t - mesa 7i96s - ace minicomputer - joystick oder controller/win11rdp steuern.

Hab alles fertig angeschlossen! Netzwerk zu Mesa eingerichtet jetzt kann ich die karte pingen mit ca. 170-200ms
Gehe jetzt in den pncconf wizard und mach nur das nötigste xz lathe der Motor test der X-achse funktioniert Motor dreht sich!
Speicher alles + desktop verknüpfung!

Wenn ich jetzt die Verknüpfung startet kann ich die Mesa karte nicht mehr pingen...
Karte leuchtet 4xGrün 1xGelb(der obere)
Jetzt kann ich den Motor 5min lang bewegen...
So dann nach ca. 5min leuchtet jetzt der unter dem gelben auf der karte Rot und ich bekomme im program unten rechts die fehlermeldung:
hm2/hm2_7i96s_0: error finishing read! iter=1256216
Jetzt kann ich auch den Motor net mehr bewegen.

Hab natürlich schonmal gegoogelt anderer Kernel macht mir schon zu viel probleme bei der Installation.
Gibt ja hier bei euch nen thread mit 34 seiten, wo ich echt nich mehr durch blicke...
Muss doch nen Fix geben weil es ja anscheinend erstmal geht^^

Möchte der effiezens wegen noch ne 2 Frage mit zu geben
Ich lass den originalen Schlosskasten mit zug/Leitspindel drin bedeutet das ich den schrittmotor einmal im dauerbetrieb
eine richtung fahren lasse(wenn ich nur den automatischen vorschub brauche) und einmal ganz normal mit eingelegter
schlossschraube zum gewinde schneiden...
Ist das möglich? Weil die position nach manueller arbeit ja sozusagen nicht mehr stimmt...
Kann ich LinuxCNC die Position vom DRO geben bzw. das DRO als endschalter benutzen?

Vielen Dank

Gruß Tom

 

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.