I am making a CNC mill, and would like to allow for manual milling as well as cnc milling. So I would like to use the motors to hold the positions of the Axis that I am not manually moving. I happen to have an extra CNC shield and wanted to control it using an ESP32. (so locking axis via push button on esp along with optical encoder reading and display + additional control and send that to arduino + cnc shield) of course now that I think about it, I could just use a toggle button directly between each enable... ( but then would have to make certain all are pressed when I do cnc steps)
Are you using ballscrews or single-start trapezoidal screws? If the latter, direct manipulation with controller-as-DRO is doable. If the former (to get higher CNC performance) then fly-by-wire is the order of the day- the lack of friction in ballscrews is a problem for manual milling. I fly-by-wire manual mill all the time, just with keyboard controls- I haven't even wired in my MPG pendant yet. Once I have the handwheel, it'll be even more manual-ish! My mill's a conversion too, so I have the before/after experience of the manual side of it. Not really a huge difference, to be honest. And being able to MDI specific locations in CNC and do line-by-line milling is pretty amazing. And of course, climb milling is fine.
Because they can be backdriven by the cutter. An ACME/Tr thread can't be backdriven, it's too steep an angle with too much friction. If you let go for a second to reposition your hand, or the cutter digs in suddenly, or whatever, the machine could crash itself. Ballscrews must be fully locked at all times. Only the motors can do that.
Ah ok, did not think about that, lucky I have trapezoid threads, so no issue there. Thanks to Peters comment I have figured out how I would need to modify the GRBL code.and board.
I converted my machine over from a parallel breakout board using Mach3 to GRBL and I'm having some trouble with homing it now. The homing procedure seems to work correctly, and the gantry is left at (-2,-2,-2), which is the pulloff measurement. But then if I jog back to (0,0,0) the limit switches are hit before the gantry gets into position. For example, I home the machine and it finishes with the Y at -2mm. I jog +1mm on the Y axis. Everything is ok. I jog +1mm on the Y axis again and it triggers the alarm at -0.028mm. I repeat this process and this time it triggers the alarm at -0.019mm. The difference isn't a concern, but the fact that it hits the alarm *before* getting back to zero is a problem. My homing settings are: Locate Speed: 20mm/s Search Speed: 500mm/s Debounce: 100 Pull Off: 2mm I changed the Locate speed to 25mm/s and it made it significantly worse. The Y would trigger the switch at -0.119 and -0.084mm during two separate tests. Mach3 was able to get a perfect zero at faster rate (~50mm/s iirc) where (0,0,0) was exactly one motor step from triggering the limit. Is there something I might have missed or is GRBL just not able to handle this level of repeatability and accuracy?
this is perfectly normal for GRBL, just don't go to 0,0,0 (-: the exact trigger point is influenced by homing speed deceleration time debounce time (trigger is after this, then decelerate to a stop, then use current position as trigger point). if those values stay the same, and the switches are reasonable quality, then the trigger points will always be the same within some small tolerance that depends on how good the switches are. This tolerance is probably smaller than your 'mm per step' value (-: You can easily test this by setting up a dial indicator somewhere in the workspace. 1 - home 2 - jog up to the indicator and set 0 for that axis (lets use X) and on the indicator. write down the absolute coordinate of that position 3 - jog away. 4 - home 5 - issue G0 X10 then G1 X0 F50 6 - how close is the dial indicator to 0? repeat many times to find an average 'homing error'. read more about it here gnea/grbl and 20mm/second is very fast for a 'slow homing seek rate'. that is 1200mm/min unless you are confusing GRBL's settings which are all in mm/min with Mach settings which might have used mm/s. 100 mm/min would be much better (-:
Exactly what David said. Most switches, even inexpensive ones, have repeatable trigger points to within microns. Mach is running on a 32-bit processor with MHz signals. grbl is running on an 8-bit microcontroller with kHz signals. At a certain point, something has to give. If you want high performance and open architecture, you need LinuxCNC with Mesa IO cards. grbl does the best it can whilst almost completely maxing out the capabilities of the controller, which is plenty good enough for the vast majority of home machines.
I'm going to try running Estlecam's controller firmware and see if that makes a difference since it offloads a lot of processing to the computer rather than the controller itself. If that isn't any better I might just have to swap back to my lpt breakout board. Homing inaccuracies around ~0.1mm just isn't going to cut it. I was also having problem with the z probe measuring ~1mm too low on occasion but I can at least work around that by manually zeroing.
To be clear, Grbl does not have 0.1mm inaccuracies! It has literally (provided the hardware is repeatable) sub micron precision on that.. - provided you have homing switches that are repeatable to the same degree - Have $24 set to a nice slow feedrate (100mm/min or even less) to avoid shaking the switch / overrunning /etc - read the descriptions on $24 and $25 to understand this gnea/grbl - Understand that you CANNOT return to position where the switches triggered (G53X0Y0Z0 if the switches are at MIN, or G53X(maxtravel)Y(maxtravel)Z(maxtravel) if the switches are at MAX) as that is the point WHERE THE SWITCH TRIGGERED, thus returning there, will, no surprise, trigger the switch You can move to just before it. A flawed test procedure is convincing you of an inaccuracy. - Home, then move in machine coordinates to position, make a mark - Rehome, then re-move in machine coordinates to the same position. Mark will line up - If it does not, you need better homing switches, not a different control system
I'm reluctant to blame the hardware since everything worked perfectly with Mach3 and was perfectly repeatable. - provided you have homing switches that are repeatable to the same degree I have no concerns about this since the only change to my machine was the controller board. - Have $24 set to a nice slow feedrate (100mm/min or even less) to avoid shaking the switch / overrunning /etc - read the descriptions on $24 and $25 to understand this gnea/grbl Despite my error earlier as far as the units, these values are set to 100 for fast and 25 for slow. With the slow find rate at 25 the gantry hits the limit switch at -0.1mm. - Understand that you CANNOT return to position where the switches triggered (G53X0Y0Z0 if the switches are at MIN, or G53X(maxtravel)Y(maxtravel)Z(maxtravel) if the switches are at MAX) as that is the point WHERE THE SWITCH TRIGGERED, thus returning there, will, no surprise, trigger the switch You can move to just before it. Perhaps there's a difference in the homing cycle I'm misunderstanding. It seems with Mach3 it would set the machine zero to the step immediately prior to the switch being triggered, which would allow the gantry to return to that position without complaint. Does grbl set the zero to the step that causes the switch to trigger? That might explain part of it but not the fact that it hits the limit switch at -0.1mm...
Can't say for sure, welcome to ask the Grbl devs directly: Build software better, together Yes plenty of differences, which is why I said, i think they way you perceive it is the cause of the deviation. It sets ZERO, to where the switch was hit (plus debounce delay, but that should be consistent between cycles as per grbl parameters value). Also keep in mind whatever host you have my be rounding for display purposes. Its not an accurate way you are trying to test this. Do the test I suggested above instead of a Mark, you could use a dial indicator instead - will be much more valuable time spent What kind of switches do you have? Some pics of the setup?
I just tested a few times with my (grbl, belt drive) laser. My home switches are at -X, -Y, +Z (ie. top front left). G53 X0Y0Z0 is at the pull-off position of all three switches, not the trigger point. Since everyone else seems to say otherwise, I don't know if this is a setting I changed without realizing but I don't recall anything about it. Common sense and safety would suggest to me that it should always be this way, so I don't know why others' machines are different. I have both soft and hard limits on, so the only negative number I could enter and be accepted as valid per the soft limit setting is Z. Grbl treats limit switches as e-stops, so I'd rather not deal with resetting the machine any time I jog a little too far- soft limits work great. I tested repeatability with a test indicator. I homed, set up the indicator in X such that I had to move all three axes to zero it, set it as the G54 origin, jogged away to a random spot in another area, then hit home. Jogged somewhere within 10mm of the indicator, then hit return to origin (to shock the TDI less than with my 15,000mm/min rapids over longer distances). The least-precise repetition was 0.003" (~0.075mm). The others were all 0.0015-0.002" (~0.04-0.05mm). I'm using the "Longrunner" Makerbot limit switch clones.
It should not be. Homing Pull-off exists for systems with shared limit switch inputs for more than one switch (think corexy) where it needs to clear one switch to move the axes to hit the next switch, as explained here gnea/grbl and gnea/grbl Thank you!!! (by the time you approach those numbers machine flex during the cut will long since be the bigger issue) - by the way pretty good for belt drive
Hmm... I'm not sure I read those the same way: This is just to be able to use limit switches as home switches, as a function of the Uno's limited IO capacity. Doesn't require complex axis setups for shared home switches, though it can. If the home is set too close- or on top of- the home switch, as it normally would be with separate home and limit switches, the limit switch function that the switch is pulling double-duty as would be constantly triggered at G53X0Y0Z0. Which is absurd and fundamentally broken. Machine home has to be a short distance from the switch for the machine to function, you can't have a specific but perfectly valid coordinate that you can't accidentally go to or your machine alarms out! My $27 is set to 3mm. Its entire purpose is to ensure that this: ...is repeatable. I assume here, $20=0 and $27 = 0.1mm, or thereabouts. In which case, the machine should allow commanded travel to -0.1mm and the switch should trigger reliably at -0.10mm. Nothing here suggests that machine home should be set right on top of multiple limit switches, though. Quite the opposite- the whole point of pull-off is to avoid it, and the ability to adjust pull-off is simply for reliable use of different throw-length microswitches. Again, the point is purely to manage physical IO by careful manipulation of home and limit switches. If you know which axis you're moving, you can use one pin for all the home and limit switches. Otherwise, move everything and wait for the parallel triggers to come in to denote home. Then move away a little bit so you don't home at a limit. Just as it says previously at at line 90: There's no reason whatsoever to then set current G53 location to be [X0,Y0,Z0] + $27. Additional complexity for extremely marginal gain (~1mm of travel) and reduced reliability (easier to hit the limit switch for non-emergency reasons). Based on my FEA modelling in my M4 build thread, I agree! Flex of these long beams will be by far the more dominant variable in a machine with cutting forces involved, especially a standard single-beam design.
My steppers move my gantry 0.003mm per step. I home, back off a bit, then move one step at a time until the switch is triggered. The alarm goes off at -0.025mm. So the zero is not being set at the step that triggers the switch, but somewhere in the neighborhood. @Peter Van Der Walt - Home, then move in machine coordinates to position, make a mark How do you suggest making a mark that isn't less accurate than my limit readings? I suppose I could mill an edge on something stable like a block of aluminum, but that will only tell me if the home position changes a measurable amount in negative space, and I'm not sure I'm skilled enough to get a surface finish smooth enough to allow me to accurately measure these tolerances. I flashed and set up Estlecam's controller just to see. It finds the homing switches at 1mm/s (yes, per second, I made sure I wrote it down correctly this time ), which is ~twice as fast as I had grbl set to (25mm/min ~= 0.5mm/s). I can then jog it right to 0.00 and the very next step of the motor the limit alarm is triggered. I don't love Estlecam's interface, but I might learn to live with it.
Would you believe Sonny himself? Why grbl after completion HOME, machine position is not cleared to 0 · Issue #862 · grbl/grbl
I just checked my Arduino library folder on the laser machine and lo and behold, HOMING_FORCE_ORIGIN is totally uncommented. (I regret nothing and everyone else should do it too. In fact, it should default to uncommented! It's the best!) (I stand by my interpretation of the above quotes, too- it's lines 126-129 of config.h that are actually really pertinent for this discussion)
Grbl doesnt support per-step move so I'll assume you were sending 0.003mm moves using the MDI Did you have soft-limits enabled? Then it will alarm, before hitting the switch, on the maths (move of 0.003mm is greater than the remaining 0.025 available to move in), thus it alarmed (as it sees this as an error in gcode, move will exceed travel) by throwing alarm "2: G-code motion target exceeds machine travel. Machine position safely retained. Alarm may be unlocked." If it hit the switch it would have been "1: Hard limit triggered. Machine position is likely lost due to sudden and immediate halt. Re-homing is highly recommended." - so the context of Which alarm code comes into play. Looking back at it, I think you were getting Alarm 2, this it was not hitting the switch, it was Grbl warning you it could not execute that move. The Grbl wiki really is a must read
Like @Gary Johnson I'm having many errors related to "is not a valid Win32" when trying to start the electron app from the command line. Any help would be appreciated.
Gary was working with GrblPanel Grbl Panel is a now retired application last updated in 2018 Releases · gerritv/Grbl-Panel but was not based on Electron You don't have to: Go to https://software.openbuilds.com and grab the installer for OpenBuilds CONTROL
Sorry about that. didn't see what program he was trying to work with. I'm trying to work with the source code for OpenBuilds to add some custom functionality (and just learn coding better). I started adding custom functionality back in April but haven't had time to work on it till now. I just have forgotten how I launched/started the program in the vscode command line. I'm able to successfully run "npm run dist" to create an install exe, however for debugging code and starting the app on the fly isn't working. Sorry for my inexperience here...
Ahh! cd into OpenBuilds-CONTROL "DEBUGCONTROL=TRUE ./node-modules/.bin/electron . " (space dot to denote current directory) Note: mingw terminal uses linux-style forward slashes, may need to use backslash on Windows CMD
Thanks for your help on this, i really appprciate you taking the time. I am still not having any luck. Here is my the output: Code: bseal@WE-BSEAL MINGW64 ~/Desktop/OpenBuilds-CONTROL-1.0.234 $ DEBUGCONTROL=TRUE node_modules/\.bin/\electron . Console Debugging Enabled Starting OpenBuilds CONTROL v1.0.234 App threw an error during load Error: \\?\C:\Users\bseal\Desktop\OpenBuilds-CONTROL-1.0.234\node_modules\@serialport\bindings\build\Release\bindings.node is not a valid Win32 application. \\?\C:\Users\bseal\Desktop\OpenBuilds-CONTROL-1.0.234\node_modules\@serialport\bindings\build\Release\bindings.node at process.func (electron/js2c/asar.js:140:31) at process.func [as dlopen] (electron/js2c/asar.js:140:31) at Object.Module._extensions..node (internal/modules/cjs/loader.js:1016:18) at Object.func (electron/js2c/asar.js:140:31) at Object.func [as .node] (electron/js2c/asar.js:140:31) at Module.load (internal/modules/cjs/loader.js:816:32) at Module._load (internal/modules/cjs/loader.js:728:14) at Module._load (electron/js2c/asar.js:717:26) at Function.Module._load (electron/js2c/asar.js:717:26) at Module.require (internal/modules/cjs/loader.js:853:19) Error: \\?\C:\Users\bseal\Desktop\OpenBuilds-CONTROL-1.0.234\node_modules\@serialport\bindings\build\Release\bindings.node is not a valid Win32 application. \\?\C:\Users\bseal\Desktop\OpenBuilds-CONTROL-1.0.234\node_modules\@serialport\bindings\build\Release\bindings.node at process.func (electron/js2c/asar.js:140:31) at process.func [as dlopen] (electron/js2c/asar.js:140:31) at Object.Module._extensions..node (internal/modules/cjs/loader.js:1016:18) at Object.func (electron/js2c/asar.js:140:31) at Object.func [as .node] (electron/js2c/asar.js:140:31) at Module.load (internal/modules/cjs/loader.js:816:32) at Module._load (internal/modules/cjs/loader.js:728:14) at Module._load (electron/js2c/asar.js:717:26) at Function.Module._load (electron/js2c/asar.js:717:26) at Module.require (internal/modules/cjs/loader.js:853:19) Error: listen EADDRINUSE: address already in use :::3001 at Server.setupListenHandle [as _listen2] (net.js:1300:14) at listenInCluster (net.js:1348:12) at Server.listen (net.js:1436:7) at Object.<anonymous> (C:\Users\bseal\Desktop\OpenBuilds-CONTROL-1.0.234\index.js:61:59) at Module._compile (internal/modules/cjs/loader.js:968:30) at Object.Module._extensions..js (internal/modules/cjs/loader.js:986:10) at Module.load (internal/modules/cjs/loader.js:816:32) at Module._load (internal/modules/cjs/loader.js:728:14) at Module._load (electron/js2c/asar.js:717:26) at Function.Module._load (electron/js2c/asar.js:717:26) { code: 'EADDRINUSE', errno: 'EADDRINUSE', syscall: 'listen', address: '::', port: 3001 } Error: listen EADDRINUSE: address already in use 0.0.0.0:3000 at Server.setupListenHandle [as _listen2] (net.js:1300:14) at listenInCluster (net.js:1348:12) at doListen (net.js:1487:7) at processTicksAndRejections (internal/process/task_queues.js:81:21) at runNextTicks (internal/process/task_queues.js:62:3) at processImmediate (internal/timers.js:412:9) { code: 'EADDRINUSE', errno: 'EADDRINUSE', syscall: 'listen', address: '0.0.0.0', port: 3000 }
node-serialport needs Python to recompile the bindings: and also see Installing SerialPort · Node SerialPort Also, you already have a running instance (might be a crashed one from before) - check Task manager and close other processes of CONTROL/Electron
For dev side stuff, always welcome to work via OpenBuilds/OpenBuilds-CONTROL with questions And if its something cool you are doing, also let us know what you are working on. Happy to help and can integrate back upstream if it fits our agendas
Interesting thing with the new Fusion360 for personal use. It puts this line in the gcode ... That's fine and all except if I leave it in either control or grbl on the black box pauses until the end of time itself although I didn't wait that long. If I remove that line it seems to work.
Indeed. The discussion- and fix for the OB grbl post, from @David the swarfer - can be found in in this thread in the remainder of page one and some of page two from this post onward: Life After Fusion 360
