Thanks Peter. Now that I have an answer to the list question, I'll move this convo over to github. I know you're busy so no need to dig into right away. Thank you.
> 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.
Thank you! I did come across that the other day, Thank you for the explanation. I might try this out.
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.
15m with the right cables will not be a problem. wifi WILL be a problem, the slightest glitch will cause sync errors and the gantry will twist
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.
Does do that: Setup: docs:blackbox-x32:wifi_setup [OpenBuilds Documentation] Connect: Scan and select IP from dropdown. Uses Telnet backend correct
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?
your maxrate and acceleration are probably too high causing the motors to stall after accelerating for a bit. Grbl v1.1 Configuration
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.
calibrate using the longest distance you can measure, that is more accurate. OpenBuildsCONTROL has a calibration wizard which makes it easy but it defaults to 100mm which is too short for accuracy.
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.
no, GRBL is not the problem (the other million users do not have this problem ) , nor is the Gcode, the symptom you describe is mechanical and can be 1 or both of 2 things 1 - backlash. check : leadscrew, nut, motor mounting, flexcouplings, bearing mounts, etc for any play. You can feel movement that you cannot see, so grab the 'bit' and give it a wiggle (use a rod, bit will cut you) 2 - the thread on the leadscrew is not regular, known as cyclic error, so that 'calibration' actually varies along its length, and may recur at exact intervals, so 1" 2" 3" etc are all exact, but 1.5" 2.5" 3.5" etc are not exact. To eliminate backlash from the calibration lets run through doing X: jog X to the left of center, say 2" from the end of travel set Zero for X jog further left by at least an inch goto0 - this will drive X in the + direction to 0, thus taking up any backlash set your measuring stick in place without bumping X the tool at all. give a command like 'G0 X10' to drive it 10" in the + direction (this can be done with the calibration wizard) take the measurement. This process of always moving right (or left, or away/toward) is a standard way of eliminating backlash during measurements. We can now test for backlash: set 0 on the left side go left of 0, come back to 0 G0 X11 ; move to the right G0 X10 ; move left back to 10" mark now compare where the pointer ends up to the the previous 0 -> 10" move Conclusive? maybe, depends how good you are at reading scales and compensating for parallax error. You can check for cyclic errors by commanding moves that are multiples of the leadscrew pitch, so, go 1" then 1"+1xPitch, 1"+2xPitch, etc but this is hard to measure without a 2" dial test indicator (and don't forget to back off between moves so it always approaches from the same direction). Maybe 1/2 pitch will indicate the very short term cyclic errors. Very high end CNC machines have an internal 'leadscrew error map' that is used to compensate every move, but that has been largely replaced by engraved glass scales that measure the movement independently of the leadscrew motion Remember to use a pointy bit for the tests, like a 20 degree Vbit, like in the video at HOWTO Calibrate your CNC Machine for MACH3 or GRBL PS all the math is there too if you want to cross check in a spreadsheet.
Great writeup @David the swarfer thanks for sharing! Hoping this testing helps you discover the issue @bernard erhart
Hi guys, if this is the generic 'ask for help' thread then I have a question about OBC and grblHAL. I'm not able to connect to my new grblHAL controller (BTT SKR 1.4 (LPC1768)), the connection times out. I fails after all 3 attempts at detecting the controller. The controller connects fine with UGS but OBC is just way better so I'd like to keep using that if I can. Is there some way I can debug the issue? gSender also doesn't work so these apps dislike something about this controller, but I can talk to it fine with Putty (and UGS as I mentioned) - including ctrl+x resulting in the machine reporting "GrblHAL 1.1f ['$' or '$HELP' for help]". Cheers.
Swarley, I had a very similar problem. After trying to find the problem for hours and hours, it turned out to be that my E-Switch was pushed in and OBC, for some reasons, don't connect to GRBLHal if that's the case.
