g2
g2 copied to clipboard
synthetos
"Pull Up" on pause
When the machine goes into FeedHold, is there any possibility of performing a pull-up (to retract from the material as in a CNC mill application) and if so - how is that functionality accessed (or how is it planned to be implemented?)
I'm working on a tweak to the chilipeppr widget to do exactly this. Essentially, you'll be able to add a custom chunk of G-code that will be sent once the machine goes into pause on an M6. If you're interested, I'll send you a link to the workspace with the tweaked widget once it works.
This sounds cool. Have you considered using the G28 or G30 commands? These will memorize the position then return to it later.
I had not, although that seems like it might be useful. I've never really played with those commands, and now when I tried it it seems to behave funny: https://github.com/synthetos/g2/issues/164
Ryan,
There are a few ways of implementing this. I think the easiest would be just for us to implement the "jog mode" we have discussed many times.
The concept being that when the machine is in feedhold that it is in "jog mode" (there will be other ways to invoke it as well). In jog mode we can issue special jog commands.
So, to "back off" on feed hold the UI could simply send the appropriate jog after the feed hold command.
Of course jogging is non-trivial and needs sorted out.
-Rob
Ryan, Please give my hacked Chilipeppr workspace at http://chilipeppr.com/G2-minimill a test. It has a few changes to the Gcode widget to make tool changes better.
The thing that helps with your problem is that it is now possible to define G-code chunks that are executed when the system pauses on an M6 and when the system unpauses after an M6 pause. Just open the Gcode widget settings and right under "Pause on M6" there are two areas where you can add Gcode.
On my machine, I defined these like so:
g28.1 g0 g53 z0 g30.1 g55 g0 x0 y0
(I do tool changes in G55 to measure tool offsets) and
g0 g53 z0 g30 g28 g54
With these, the machine moves up and over to the G55 origin as it hits an M6, and then back to the original position (at max height) after you unpause.
I haven't tested it much and I've never written a line of Javascript before yesterday, so it's quite possible there are bugs, but it appears to work.
Another thing I added is that the tool change window now displays which tool you're supposed to change to. Before you had to look at the Gcode listing or keep track of it in your head.
How does this handle the situation where I've pulled the tool into feedhold, and want to pull up out of the material then (ie not doing an M6 pause?)
It does not. A feedhold means G2 itself has paused and is no longer processing instructions. I don't think there's any way to inject new motion commands in that situation without flushing the queue and that means your program is shot.
So what we are discussing here is a way to inject some motion commands into a feedhold context.
This is going to be tricky, since the buffer has to be carefully managed to ensure that the serial buffer isn’t full on a single-port setup (such as a UART-connected host).
-Rob
Keep in mind that a way to inject motion commands doesn't have to be serially. This would be the ideal situation (let me do anything from the hold state) but for our application, you get 100% of the way there simply by pulling up out of the material and shutting the spindle off on a feedhold. The action to do on a hold could be "baked in" before the file is run, in such a way that you don't have to try to jam additional motion commands down a packed serial channel in the instance that a hold is encountered.
An update regarding my chilipeppr tool change script from above: DO NOT use G28 or G30 to return to the preexisting position after tool change. These are saved as machine positions, so if you switch to a longer tool, you'll very likely slam it into the workpiece on the return move. Ask me how I know...
Is this because of the reporting issue? These functions are supposed to work in machine coordinates, but I can see that if the position reporting is not consistent this can cause problems.
No, it's precisely because they work in machine coordinates. Since the machine moves back to the same position in machine coordinates, not in work coordinates, the tool end won't be in the same position. If the tool is longer, it will be closer to the workpiece (ie a lower Z WCS position) than the previous tool was when the position was saved.