Advanced Search

Now that sounds pretty neat! I take it your Arduino Q contains literally both the mini-pc running Debian 13 AND the motion controller grblHAL STM32. The entire system on one compact little Arduino board the size of Arduino UNO!
I bought one of those Arduino Q when they introduced them. I'd love to unpack it and try that, but I'm currently working overtime on another big project, that should be done in a few more weeks...

Did you try editing the ini file for the sim?

If the old motors and drives work, i would not change them, just get some Mesa analog boards and move on.
I can not give you useful advice for now as i always try hard to use the existing drive train when retrofitting (done plenty of those), and i did not use EtherCAT yet, but from what i read here they are both hard to set up and have issues i do not like to deal with, especially having position feedback going on vacation at random on a 15 ton machine.
If you need inspiration, have a browse through "show your stuff" section of the forum, plenty of retrofits by me and other forum members there, also many more on other sections but might be harder to find.

I still have some old functional microwaves in the shop...
And some 6S/32AH batteries,at 10C they can deliver 320A of current easily, should be enough to run 6-8 microwaves at once! For around 5 minutes...

I really hope those are not - signs in front of the axis lengths!
First, make sure when X axis is moving to the right numbers go up on screen, move up when Y axis moves away from you, and go up when Z axis goes up although these should be negative values.
You can change direction of any axis/joint in the hal file, just add - sign in front of the SCALE value in the INI file, save and run LinuxCNC (needs restarting LinuxCNC, not the PC)
Only after you got this correct move on to fixing homing if using home switches.

Dont forget to set halui.axis.N.jog-speed as well to the same value as joint.N.

joint.N.jog-speed is used before homing, and axis.N.jog-speed is used after.

It may get a little complicated in HAL, but there should be a component or other logic chain which triggers joint.N.plus when the joystick value is >0, and opposite for <0.

Maybe look at wcomp...  Perhaps two wcomp instances, one for plus and one for minus:

• set the wcomp.0.min to just above 0
• set the wcomp.1.max to just below 0

giving you (I think) an adjustable deadband if the joystick analog value flutters a bit at the center point.

Thanks for the hint.
From what I see i have to set halui.joint.jog-speed to some nominal value
Then net the analog value halui.joint.N.analog as I have done above

It also seems possible that I have to set either halui.joint.N.minus or halui.joint.N.plus to actually initiate the jogging

I will play with these options

A bit of background I had gifted a 1995 Cipher engraving table controlled by a Multicam M23 box all new in the day I wanted to bring it up to date and do a complete rebuild and upgrade and as I knew/know just a little I firstly built a control box using a raspberry PI5 and attached it to a testrig I made and then to a chinese table learning how to use Linuxcnc Freecad and any other useful addons.

Now for the issue I have rebuilt the Cipher table with my Pi5 control box and it all works sensors steppers BUT initially it was engraving text mirrored so I fiddled with the INI file settings  min limit and max limit...and eventually got it to do machining BUT the layout is upside down and the X and Y axis numbers are negative below is an image showing the home and extents I have also attached the INI file
I would like to be able to load the files right side up All works fine on my first table build.

I should add that the table image attached is as the physical table but the image on screen in axis shows the home position top rhs if I "fiddle and get the home to btm left on the screen it messes with the homing 

 

No idea about the motors as they tend to have several types of feedback, but for a general idea of retrofitting such machines have a look here:
forum.linuxcnc.org/30-cnc-machines/33529-hurco-bmc-20p-retrofit
forum.linuxcnc.org/30-cnc-machines/31792...-01-retrofit?start=0
There are many more, lathe and a lot of plasma machines i have retrofitted, but this is more like yours, hopefully.

Hello everyone, I have an old CNC milling machine with an onboard FANUC O-M. The IO board and the MEM board are dead. I wanted to switch to LinuxCNC and MESA but I don't know which board to choose because I would like to keep my Fanuc servomotors: the three A06B-0141-B077 / αC12/2000 / 1.0 kW / 2.5 A, the SVM3 and my FANUC A06B-0855-B102 spindle motor (~7.5 kW).

This is why we have code reviews. I frequently cannot see the forest for the trees.

Thank you!

As indicated in the 'Pins' list:
The correct pin name is

not just

Hello Sandro,

Thank you for sharing lcnc-suite — it's a genuinely impressive piece of work, and the 3D toolpath preview alone saved me weeks of development time.

I'd like to report that I've successfully used lcnc-suite as the frontend for a **non-LinuxCNC** CNC system, in case it's useful to you or others here.

---

**My Setup**

- SBC: Arduino UNO Q (Qualcomm QRB2210, Debian 13, Python 3.13)
- Motion controller: STM32U585 running grblHAL, connected via internal UART (ttyHS1)
- G-code interpreter: rs274ngc (from the linuxcnc-uspace package — the C extension only, no linuxcnc task/HAL)
- Machine: CoreXY pen plotter with CNC Shield V3

The key idea: instead of `import linuxcnc`, I wrote a custom FastAPI/asyncio gateway in Python that speaks the lcnc-suite WebSocket protocol on one side and rs274ngc + grblHAL on the other. This means lcnc-suite can work with backends other than LinuxCNC.

---

**What works**

File upload, 3D toolpath preview, program execution (rs274ngc → grblHAL streaming), step execution, jog (continuous + incremental + diagonal), E-STOP/pause/resume/abort, WCS switching (G54–G59), spindle and coolant control, file browser — everything I've tried works well.

---

**Undocumented requirements I found**

While building the gateway I hit a few things not covered in the README. Posting them here in case they help someone else attempting the same:

1. **`heartbeat` must return `{"type": "pong"}`** — any other response causes the WebSocket to disconnect after ~20 seconds.
2. **`GET /settings` is required on startup** — without it the UI enters a reload loop.
3. **`save_settings` WebSocket command must be handled** — sent frequently for jog speed etc., causes visible errors otherwise.
4. **`GET /gcode?path=...` is needed after upload** — the UI fetches file content via this endpoint to display in the editor.
5. **`GET /files` must return `FilesResponse` format** (`{ok, nc_dir, subdir, entries[]}`) — a plain array causes "No program files found".
6. **`status` broadcast must include `armed` field** — needed for the ON button to activate after ARM.

I've opened a GitHub issue with full details:
github.com/bildobodo/lcnc-suite/issues

The gateway source is here if anyone wants to look:
github.com/hoshigarasu/canon-grbl-bridge

Thanks again for building and sharing lcnc-suite.
 

many many thanks !

found the problem, fixed in main and dev branch.
please update your gateware.

The PID controller had compensated for the fault during operation, so I never noticed it

I misspoke. The documentation indicates that if the gladevcp is launched without specifying -x {pid} the panel would be floating. I interpreted that as EMBED_LOCATION was not required. Subsequent testing determined that even if the panel is floating, EMBED_LOCATION must still be defined for the panel to launch correctl.

Fixing the my misspelling of EMBED_TAB_NAME, fixed the launch issue. However, I am now struggling with connecting up the panel to HAL.

During the first investigation I discovered that GMOCCAPY does not toggle the motion.machine-is-on signal as with AXIS. A bit of probing with halmeter I was able to determine that halui.machine-is-on is toggled by GMOCCAPY when the machine is on. I edited my crosshair_panel.hal file to use the halui.machine-is-on, but the panel did no respond.

I've done a bit more testing and discovered that halmeter sees the glade pins as expected, however, halscope does not. Therefore, attempting to manually connect the pins via halscope results in a Pin 'xxx' does not exist error.

At this point I'm lost as to why halscope does not see the panel pins and therefore cannot connect them properly.

Any help would be appreciated.

Currently running:

LinuxCNC 2.9.4
GMOCCAPY 3.4.9
Glade 3.40.0

I've attached all relevant files.

I've attached all of the relevant