First off, I’m a bit of a GCODE / CNC newbie - I’ve had my nomad since just before Christmas.
I’ve been making good progress with it and GCODE. However I’ve recently figured out that what I want is multiple workspaces or G54 - G59 or a temporary workspace offset G52.
Reading around, it’s clear that Nomad doesn’t support this. While there are other ways to accomplish the same thing - in my case I’m really looking for multiple offsets.
My question is - Based on my understanding at this point, the Nomad is running an opensource CNC engine (GRBL) and there are any number of tools to drive a GRBL based CNC machine. IE. I’m not “stuck” with Carbide Motion.
Are the gcode limitations due to the physical hardware and/or controller board or are the limits imposed mostly by Carbide Motion?
If I (can I?) try a different control program will more gcode be available?
Amigo , tu puedes trabajar esta maquina con diferentes softwares , por ejemplo estlcam , Universal G code y muchos mas .
También puedes aprender G-Code y hacer las rutinas diseñadas por usted . Lo único que te puedo decir es que estas en el mejor lugar CARBIDE 3D . Gracias .
Thanks.
Yes I’ve read that in other posts. Can you be more explicit about which offsets are used and how / for what (generally)? That would help out a lot rather than hacking around in the dark.
I’d prefer to just keep using carbide motion for now (bird in hand) rather than going down the rabbit hole of switching to another sender. CM has a nice easy to use interface and is handling most of what I need.
On the other hand, if there is some builtin limit to CM do to the way it’s designed thats fundamental and can’t be worked around, I’d rather spend my time finding another sender.
I am not able to commit to whether or no work offsets are used, or will not be used internally in the future — if you test with one version, that testing should stay valid for that version, but we can’t guarantee that a future version won’t need to use it.
If you want something beyond the basics, you should try something else — bCNC is flexible and popular, as are UGS and cncjs — they’re free, so no issues in trying. Most of the G-Code senders are, only a few are commercial/paid apps.
If you are generating Gcode yourself, by hand, that is awesome. I know a lot of experienced, long career people that have never used anything but automatic generation via a CAM package. You will learn a lot about how things work this way. (I use a cheat sheet at this point. I have been spoiled by competent CAM tools)
Before setting ANY of the machine variables (GRBL or Gcode standard ones), write down the original values so you can reset them. The FAQ explicitly states that G54-G59 are intercepted by CM, as the machine settings may be used by CM-- or Carbide Create-- itself. (https://docs.carbide3d.com/software-faq/list-of-supported-gcodes/) If you use another sender, they will be available to you, but restore them to the original values before going back to any C3D software. GRBL does not recognize G52. Again, it does recognize G54-G59, but, I can not emphasize enough, record the existing values before changing them and restore them before using any of the C3D software. (your mileage may vary. I have not had any problems doing this, but make no guarantee)
Some of the limitations are due to CM using particular features for its own purpose. Others are due to stuffing a modern control scheme into what is essentially a pre-1980 technology processor (the Atmel based Arduino hardware) limiting the feature set for GRBL.
For direct control of the machine, another sender can be used, but you will need to deal with tool length probing yourself (it has been discussed previously on this forum), and may want to set travel limits (default is off for soft limits, or at least was when I got my machine).
Most CAM chains don’t have any issue with the unimplemented/blocked features. They generate Gcode using what is available, trading more work up front (location calculation and so on) and longer gcode files for multiple coordinate systems and canned cycles.
You really can use any serial-capable sender. I have used PuTTY for manual control, and even used it as a file sender for a few things (my wasteboard surfacing job, for example).