Because of the way grbl's streaming buffer works, you're probably gonna need to involve the GUI as well, I think, because it's the one doing the decision-making on whether to push the next line out or not depending on its estimate of the state of the buffer. You can listen for when the G38.2 is sent, but knowing when it's going to be executed requires listening for a specific return "ok", but those returns aren't labelled in any way, so you have to know whether it's a couple of long lines in the buffer ahead of it or a bunch of short lines! Since this is a step that doesn't require a lot of high-speed operation, it may be possible to command some kind of buffer flush without losing track of the program, such that the only command in the buffer becomes the G38.8, or you could send an initial empty or do-nothing (G91 G0 X0 Y0) line that generates an "ok" response for you to trigger your other system ahead of the G38.2 being executed. If that's possible, that's the way I would do it, but I haven't seen anything that accomplishes it thus far. The other thing here is that grbl has two buffers, the serial receive buffer and the planner buffer where it's actually executing from. I'm assuming that the GUI effectively only sees one buffer, and when grbl moves a line from the receive buffer to the planner buffer is irrelevant, only the "ok" received upon execution. Though since the receive buffer has a 128 char limit and the planner buffer has a 16-line limit, that seems like they could conflict at some point, and I'm not 100% sure how it's managed so that they don't. It's very hard to see exactly what's going to get executed when, because even if you know you've filled the buffer, you still don't know when those lines are precisely going to get executed down the ladder. Maybe the optimum- read, least-complex- method is simply to send a dedicated flag line to grbl, that does nothing but is simultaneously large, useless and unique to look for in the serial stream. A 126-char line, say, that does absolutely nothing (somehow, or maybe just something pointless and non-destructive like arcs) that always gets prepended to your G38.2 lines by a post-processor or find-and-replace. That way, you know for a fact that the only thing following it is the G38.2. Again, though, you don't know when the planning buffer is actually going to shift it into executable position. Hmmm. This is a tricky one... Important to figure out though, in terms of usefully extending grbl's capabilities within a larger system. I wish line numbers were used for send and receive. Lotta lost characters, though, in that small buffer, for 5- or 6-digit programs. For now, you may just have to have the spring hard-mounted to a side-wall somewhere so you can G53 over to it and operate that way. I'd rather figure out a sister-system solution though! EDIT: Two possible interesting things from config that could be worth looking into:
hi Hi i have a mini cnc milling router, with grbl 0.9, just bought a new keystone board, it says machine connected but wont move when i send commands, just says connected but not idle, i'm new as you may tell, can you help please.
Grbl 0.9 is quite old! Last version was in 2015, so most hosts applications these days will not work with it. Grbl 1.1 has been out for over 3 years now (Dec 2016) (and even that has been surpassed by newer versions too with 1.1h out since Aug last year) see gnea/grbl and gnea/grbl
@dazeddnc In general, probing is a very constrained operation, I don't see it happening in anything beyond a very specialized program. Are you trying to do some sort of tool change? In which case, you might want to look at the several projects using GRBL for ATC. Google finds a bunch.
Thanks for reply, opened up page, could not see any download options though, is there a way of downloading 1.1, Thanks
Refer to the wiki it has detailed instructions (do read it all of it, its worth the read and worth the time - its all there!
Are you still on Grbl 0.9? If yes, update first. Read the wiki, it really has all the instructions Or consider an off the shelf solution like docs.openbuilds.com/blackbox if you need an "easier" and more modern solution
Rob: Thanks for a detailed explanation about the situation. Yeah, some kind of line-tracking-echo would be great for extensibility. But....I get it. There's only so many bits and CPU cycles available. Every added feature comes at a cost...and people seem to get by fine without it most times. Phil: I have not ventured down this path. I'll have to poke around and see if that fits the bill. I want to set up my CNC so that a non-technical person can clamp the work piece, click a couple of buttons, and more or less walk away. I don't want to leave open the potential to forget running a probe cycle to find Z=0 after a power cycle, etc. In a nutshell, rather than drawing things in CAD, I have software that will use some awareness of machine capability and direct input of label dimensions/text to engrave a sheet of custom labels. Before starting a cut, it is set up to run a homing cycle and then Z-probe. It may be necessary to change tools, but it shouldn't happen a lot and it certainly can't be fully automated. This is mostly about making things simple for a newbie to setup a job and go. Leave as little to chance as possible. Edit: So, I don't think an ATC is really what I'm after. And the idea of responding to G38.2 is pretty much shot. We'll never be cutting anything that needs coolant though. I'm assuming M7 and M9 would stay in synchronization with other motion commands. I should be able to tie the coolant pin to my pro mini. Then I just have to issue M7 before G38.2 and M9 after.
Yes, that's a good pragmatic solution. Newer GRBL variants have the ability to flip all sorts of external pins, you wouldn't need to steal coolant pins.
Hahaha, it's funny because adapting a coolant/ancillary pin is usually my go-to solution for things like this and for whatever reason this time I didn't even think about it. Good call!
Hello all, I just built my first CNC machine. It's a 2-axes foam cutter inspired by Stefan on CNC kitchen (youtube channel) own's CNC foam cutting machine. It only has X and Y axes (it runs along the X axis, and moves up and down the nicrom wire along the Y axis. To get an idea of this, the machine looks similar to the Foamlinx SC5542: But I have a problem with the homing sequence. I need the Y axis to clear the workspace before attempting to home the X limit switch and then home the Y axis. How can I accomplish this? This is only mentioned on the GRBL help pages when the machine is a 3-axes one, and even in that case, I couldn't find any custom settings for that (like by how much to raise the Z axis). edit: I might have found a workaround this, by increasing the homing pull-off distance, altough it would be nice to be able to set it for individual axes. Thanks in advance
Kind of a hack but you could use Z instead of Y because GRBL homes Z first. Not sure what the GCode gen implications are. Probably a way in the code to make Y behave like Z in the homing sequence.
Operational axes and homing order are configurable via config.h. Might have to poke into it though because I can't find the page where it's mentioned now.
But I can't home "Z" first. The X axis switch needs to be reached first in order to be able to physically reach the other axis switch.
OK, looking at the machine I see that so you really can't use a standard homing sequence at all. I thought your problem was that you had loaded foam in the machine and didn't want to drag the wire through it. So really, you need X to behave like Z in the homing sequence. One thought, why bother with homing? A lot of people run ok with never doing it. In fact, a lot of people run without limit switches at all.
It can be done - you need to think in three dimensions. When you generate your g-code in cam one of the codes defines which of the three planes you are working in (X/Y, X/Z or Y/Z). Tell us where your homing switches are (pic of machine would help as well) and we can give more advice. Alex.
Here's the machine. There are some design glitches and parts missing due to not being able/being lazy to move/resize/mirror certain components on Fusion360 haha. As I said earlier, the machine is inspired on this one (check at minute 19:28):
I'm not entirely sure A) why this needs a homing system at all and not just regular limits, and B) why the y-axis has to go up first since it shouldn't be getting homed with workpieces in it anyway?
Limit switch pull-off distance was set by default at 1mm. If I homed, then moved the X a few centimeters and then homed the machine again, the part that contacts with the Y-axis limit switch would crash into the Y-axis switch when the machine starts to home the X axis. By increasing the pull-off to 3mm, I managed to circumvent this, although I'm losing 2mm on each axis, but I don't really mind.
That could work, but I would have another hanging cable that would need to be pretty long as the switch would travel all the way to the X-axis length. And I would need to redesign more things. I'll stick with the workaround I found for now. Thanks a lot, everyone!
I am not sure if this s the correct place to ask this question, but here goes. I have a question on using the latest GRBL 1.1h. I want to make a pause in the gcode so that I can adjust the amperage of my plasma cutter for the next operation. I have tried putting M01 in the code, but nothing happens, it just continues on the the next operation is if it were not there. As a work around I added M01 M60 to cause an error and stop the program run, then I made my adjustment and pressed the continue button and all went as planned. What I would really like to do is find out what is the correct way to do it. I am using UGCS platform to send the gcode to my machine. Hope someone can help with this, thanks.
M0 for non-optional "optional stop", not M1. If you send M1 it's checking for an optional stop switch to also be set, and I'm not sure off-hand if grbl actually has that capacity or not.
M01 is optional stop. Not sure how grbl or OB control responds to it but you probably need M0. Alex. Edit; I'll have to type faster! LOL.
