I am running a FluidNC controller, with an MPCNC and using gSender to control everything. Loving gSender, and super easy to use.
I’m busy adding an A axis to my machine - actual A axis, not just rotary axis connected to the Y axis. If I set my firmware option to GBRL, things run smoothly, but I can’t activate the 4th-axis mode, and the rotary axis controls move the Y axis.
What’s also weird, is even with rotary mode switched off, any macro I have with an A move gets translated into a Y move (the console shows a Y move). If I type directly into the console, I can get the A axis to move.
If I set my firmware to grblHAL, I can activate 4th axis mode and get the A axis moving corectly. Unfortunately, I don’t think this is the correct mode since the error codes aren’t processed correctly (e.g. on startup, it shows an unknown error instead of the error showing homing is required) and I’m unsure what else could go wrong.
Any advice on how to get this running more smoothly? Ideally 4th axis support with GBRL would be great, or at least an option to not translate the A moves from the macros. I’m assuming this will happen if I run a Gcode file as well?
I am running 1.4.12, because the new UI doesn’t fit properly on my 1366 x 768 monitor (scaling is at 100%).
It is my understanding that grbl cannot accommodate 4 axes, so Sienci did a work around for its Vortex by both creating a post processor for Vectric that translates Y moves into A moves, and offering a Y/A switch.
This one is quite old, but I believe that the basics are still valid. I know nothing about FluidNC, so this link or others you will find with a search may not address your issue directly.
If they do not, you may want to add some details to your question, such as the CAM application you are using to generate the rotary toolpaths and the post processor you are using to generate the gcode.
It’s a combination of a situation where vanilla GRBL (which we do support) does not support A axis but FluidNC/various GRBL derivatives (which we don’t support) do. We might look at adding config options to not translate A to Y for grbl in the future but it’s not a priority at the moment since it’s not supported by the firmware itself.
Hi @gwilki and @kgn thanks for the prompt response, very helpful. I agree it seems like FluidNC supports things GRBL didn’t.
So far, I am not using a CAM tool to generate any toolpaths yet. My issue is that with the firmware set to grbl, sending the command “G90 A5 F3000” in the console rotates the A axis correctly. If I write a macro to do the same thing, the console prints out “G90 Y5 F3000”, so it’s been translated.
If I understand correctly this will always happen with it set to GRBL, even when running a gcode file with A movements.
The reasoning makes total sense. My use case at the moment is very simple, so I might just stick to controlling the A-axis directly from the web interface of FluidNC. If necessary, I think the best solution would be to switch over to grblHAL, since gSender is so good I never use the web interface of FluidNC (which was the original reason I chose it).
I found an easy workaround, thought I’d mention it here. I renamed my A axis to B axis in FluidNC, and now a macro for “G90 B5 F3000” runs correctly since gSender is remapping B to Y. Super relieved - I was not excited to mess with new firmware or Gcode sender, and I was so close to having it working.
Next step will be to setup macros to jog the rotary axis and map it to buttons on the Xbox controller, which looks like it will work. I’m using an MKS DLC 32 controller (ESP32 based) which is technically only 3 axis, but it had a spare I2S pin I wired to another control board (for the steps) and then use a digital output to control the direction, so I was always going to need to use macros to control the direction.