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.