Ask Grbl CNC questions here.

> Is there a list of grbl / grblhal settings that require a restart when changed?

The $help settings output from grblHAL adds "Reboot required" to the settings that needs it, e.g:

$16: Invert spindle signals as bitfield:
0 - Spindle enable (1)
1 - Spindle direction (2)
2 - PWM (4)

Reboot required.

> I'd like to change soft limits and acceleration.

The OpenPNP plugin has a M-command for setting the acceleration without updating the setting (not yet available for the ESP32 though). Changing soft limits via M- or $-command(s) is also possible if someone writes a plugin for it.

A new feature (and undocumented for now) is that the PWM spindle can be "cloned". This adds a second spindle that shares the PWM output and repurposes the direction signal as its enable signal. The base spindle loses direction control but retains laser capability, the clone loses laser mode capability and has no direction control. I addition the clone gets a new set of settings to control the RPM range etc. (but not the PWM frequency). This allows setting laser mode permanently, and turn it on/off by switching spindles with the M104 command. Spindle switching can also be done via tool number if each spindle is assigned a tool number range.

 

I would like to add wireless to grbl, as the cables seem to be a source of error (and size - I need a 15m bed!). I have a few nrf24l01 wifi chips. so the idea is to put all the post processing on the sender arduino, and the machine control on the receiver arduino, with power on 2 x 24V copper rails and takeoff with brushes.
has anyone else done this? I would appreciate your thoughts,
Robert

 

What controller are you using? Modifying Grbl to do what you are asking about is not an easy task and 8-bit Grbl is getting a bit long in the tooth. But, if you are determined to use an 8-bit arduino, then I suggest you figure out a way to output async (UART) from your NRF wifi set up and connect to the on board UART on the Grbl Arduino. Lots of GCode senders know how to use Telnet to send GCode over a network.

But, a simpler way would be to use a Grbl controller that already knows how to talk wifi (you would still need a GCode sender that talks telnet). There are a number of 32 bit grblHAL based controllers that do. The BBx32 might do that - worth checking if you want an integrated controller. If not, there are other solutions out there.

And FWIW, there are lots of ways to harden a system from EMI, even if you are using USB for the GCode sender connection.

 

Using WiFi for the GCode Sender connection can work. Comm glitches are handled with TCP/IP resend (inherent in a telnet or webpacket interface, Grbl never sees them) and a Grbl controller will not allow dual motor, moving gantry problems from that. Packet loss from WiFi can cause performance issues because of the resend (sequencing error, NAK and packet resend takes time). Increasing the planner buffer to something well larger than the default helps. Ethernet (hardwired) is a better way to go than WiFi, though, much more EMI and radio interference resilient. And auto-squaring (like grblHAL supports) will bring a moving gantry back into alignment with each Home operation.

 

USB is not something that works over distance. ethernet, yes, but a 20m USB costs a fortune (100$ or so) and the plotter bends the cable thosands of times a day, they degrade. I am happy to debug the wifi (as I did with all the cables), If the XYZ commands to the steppers are in sync, on the receiving side, there is not much risk for the gantry (hey I have watched it leave the track and throw itself into the wall, it is not fragile). I just want a machine that I can put on a track, it will plot from my office, then I can remove the machine, to free up floor space. 15m x 3m is about half the usable floor, and we also have to weld and finish in the same space.

 

If you have a good mesh Wifi system, I don’t see any reason not to use Wifi, if Ethernet is not an option.

I’ve found that with a decent off the shelf antenna, grblHAL on my DLC32 is rock solid over wifi.

With all the cheap cables on the market these days, it’s nearly impossible to find a well shielded USB A to USB B cable. Every 6ft cable I’ve tried has picked up EMF from my CNC machine like crazy!

 

Controller? mainly bCNC, but I don't think that matters, as the grbl docs tell you how to talk to a controller. I know grbl is old and tired and cheap, but why pay 50 quid for a 32bit machine, when you can use two 5 quid machine plus 2 quid for a pair of wifi chips.
So it looks like I am on my own here. The thing is, before, I would not use an arduino, because it did not release it's instruction set. now it has, I can always skip the C programming and jump into machine language.
By the way...
I cannot publish on github anymore, as I can't do two factor authentication. Alternative sites??

 

You can buy a DLC32 board for $24 AUD or 13£ that runs grblHAL, and supports an external wifi antenna and works with external Stepper motor drivers.

https://a.aliexpress.com/_mMlFCtC

and here is my pre-compiled grblHAL firmware

GitHub - dJOS1475/grblHAL_Backup: My grblHAL Config Backup

ps, the wifi connector is mini PCI U.FL

 

Sounds like a race to the bottom. bCNC is a GCode Sender, not a controller. Grbl running on an Arduino is a controller (motion controller to be more precise). Why use a 32 bit controller? Well, first off it is a lot faster (8-bit Grbl on an arduino is limited to about 30K steps/second, 32 bit grblHAL on even a $4 USD Rasp Pi Pico RP2040 is way faster). Not only does it allow faster motion but allows you use higher microstepping and thus a higher resolution (aka accuracy). Secondly, an Arduino is not an industrial device (probably why you are having EMI problems). Most 32-bit boards that run grblHAL are EMI hardened to some degree. Also, 32-bit controllers have a lot more memory and allow lots more features that make for a much better CNC experience.

If you don't want to spend money on an EMI hardened controller, I suspect you will be cutting more corners and having lots of problems. Sometimes you have to spend a little more to get good results. Good luck to you.

 

I built a pen plotter years ago using grbl that was modified to control 28BYJ-48 steppers (GitHub - imaicom/GRBL-28byj-48: Grbl ver 1.1f.20170131 with XYZ Unipolar Stepper Support (28byj-48)). I was able to get it to work. I just built an upgraded plotter using the same motors and the same code.

The problem I'm running into is that in UGS, everything works correctly as expected when using the jog controls. I made a simple circle gcode to test, but when I run that gcode in UGS, only the Z axis works as expected, the X and Y axes move, but they just print weird lines, they don't follow the gcode at all.

The worst part is that when I built the first plotter, I ran into this exact same problem, which I successfully corrected, but I'll be damned if I can remember what I did to fix it. I've tried switching the X and Y axes, I've tried various different motor wiring configurations, but I'm hitting a wall. I can't seem to change the behavior. I've tried with different gcodes, too, but they all do the same thing. I've tried with different versions of the 28BYJ-48 modifications.

Anyone have any suggestions?

 

This was the problem. Once I lowered the max rate, the motors moved as expected. Thanks.

 

Ok you asked me to start a new thread and this is the only obvious way to do it. so here goes... I have set up a mill with ugs and grbl. I have fine tuned the steps per mm to go 'exactly' one inch when I program a 1 inch move. It works perfectly. But when I program a .01 inch move it falls short by .008" and when I program a 2 inch move it overshoots by .008". This to me sounds like a divisor, somewhere, is off just a hair. I don't know much about computers so If you could tell me where to view and edit the firmware (?) I could probably figure this out.

 

HOW do you post a Question?

 

okay give me a day and I will give that a try. thanks.

 

to David the Swarfer. hey thanks for the suggestion but it didn't work. Yeah, I calibrated steps/mm using one inch of travel. but when I jog a move short of one inch the actual move falls short and when I jog a move over one inch it overshoots. So even if I calibrate with an 8 inch move (which I tried) it still has this undershoot/overshoot variance. Its like the calibration length I use (whether its 1" 8" or a hundred) is the center of a teeter totter, one side goes up and the other side goes down. which would mean the steps/mm would have to decrease on one side and increase on the other. I wonder has anyone else ever noticed this or do I just need to reload another version of grbl. I sure would like to take a look at the firmware if anybody could tell me how to view that. I may be computer stupid, but math is math after all. and python or c+ or whatever it is just isn't that hard to figure out when all you're messing with is gcode. but hey now that I've rambled on this long maybe I will just reload everything or just move on to something else. could be grbl is free for a reason. Thanks for the help.

 

It sounds like you have serious backlash problem you need to solve.

The other possibility that springs to mind, is you have binding on your lead screws and that’s causing your stepper motors to miss steps.

 

Nah backlash could never cause an over travel, but I will check the ballscrew for binding. with the mod it was a very tight fit I think I had .005" clearance between it and the saddle though I can crank it by hand and don't notice any undue noises while running. I did have to repack the balls though, maybe I got one between circuits. Also, I did figure out how to view the grbl programs and I must say I am a bit humbled. this is a little more than macro b and g code. But if I figure anything out I will post it. Is it possible when I loaded grbl that it got corrupted yet still runs. Maybe I should just reload it. Man, I HATE computers. If it wasn't for solitaire and wordle I'da chucked it years ago. Thanks again for the help.