I finally got my modified Workbee 1515 up & running & I'm learning the differences from my Shapeoko XXL & its Carbide Motion control software. I'm still in "I'm terrified I'm going to break this" mode & I apologize if any of this is simple or obvious: 1 - I usually zero at / near the front left corner. When a cut finished on the Shapeoko the spindle moved to the back left corner of the machine. I've only run a few test programs in air but on the Workbee, when the program finishes the spindle returns to the start point & stays there. This leaves the gantry at the front of the machine & in the way. Is there a way to change this? 2 - I cut a lot of acrylic & usually zero to the wasteboard, not the top of the material (because acrylic can vary in thickness). Carbide motion had a "Rapid to XY" button" and "Rapid to Z +5mm" button & I used both frequently. Control has a "Goto XYZ" button & I can't use that because Z is at the wasteboard. So, can I recreate these functions using macros, and if so, how? Thank you!
end of job.... it is just doing what the Gcode said to do, neither OBControl nor GRBL do anything extra, just what they are told to do.. a macro to move it safely out of the way would be G90 G21 G17 ; set modes so we know what they are, previous gcode may leave 'anything' set in unexpected ways G53 G0 Z-5 ; raise Z to 5mm below the machine home position, if -5 still triggers the limit, use -10 or whatever suites G53 G0 x-5 y-5 ; move to home position, just short of the limit switch, if 5 to little, read the line above.... Rapid to XY G90 G21 G17 G53 G0 Z-5 ; raise Z before moving G0 X0 Yy0 ; move to work 0,0 Raise Z by 5mm G91 G21 G17 ; note, setting relative motion mode G91 G0 z5 ; raise Z 5mm above where it is now G90 ; back to normal absolute mode
Thank you! The first macro (Rapid to XY) doesn't work; it moves Z, then gives me the message "error: 2 - Numeric value format is not valid or missing an expected value. [G0 X0 Yy0]". And I'm not sure I was clear enough in my post. What I want it to do is to go to specific machine coordinates, not work coordinates. This will be the corner of my wasteboard & will end up being work zero for most of my programs. In machine coordinates, right now I need them at about X-1200, Y-1175. The second works but not as intended (again, my fault for not being clear). No matter where the spindle is, i want it to move to 5mm above work Z0. So, if for example I'd just homed, it would move down, and if I just zeroed to my wasteboard, it would move up. Lastly - after what you said about the end of the job (just doing what it's told to do), I remembered that I had used the GRBL (Inch) post processor in VCarve. Thinking that could be the difference, I switched it back to the Shapeoko (Inch) post processor & tried again & got the same result - the Workbee returns to zero and stops, leaving the gantry at the front of the machine. So there has to be something extra happening in Carbide Motion, right?
Probably because of the clear typo... There's no logical reason why "G0 X0" should be followed by "Yy0" instead of "Y0". If you're not also researching the codes that are being provided to you here, how they work and under what parameters, they're gonna be of limited utility. He also showed you what "move in machine coordinates" was: It's up to you to make the codes work in your specific instance. Sounds like you need this rather useful resource: LinuxCNC "G-Code" Quick Reference - Google is also your friend for checking specific codes, whole articles are written about just a few letters! Work Z0 is in G54 (etc) work coordinates, and can't be G53'd. You have to perform a probing cycle to find where the top of your spoilboard is after homing. There isn't a consistent shortcut there because that's going to vary over time as you resurface it and use different end mill stickouts. Homing is simply to set the approximate starting parameters of the machine (within the limitations of the switches, thermal variations, etc), it's not a panacaea to fix all things in 3D space (unfortunately for everyone). If you are zeroed there (which you can't be until you're already homed because it's an offset, so that aspect of the question is moot), then your G54 coordinates are set there, in which case a simple G0 Z5 would work just fine. If the CAM and processor are setting up a "return to work zero" at the end of a run, you'll have to manually add a "go to machine position" block yourself (unless there's a setting in post to change it or add additional custom blocks). It's possible the Shapeoko may home at the front, but then set itself up to operate in negative space, which means it's using its preset dimensions to move X0Y0 to the back of the machine (whether that's machine zero or work zero, I dunno). Post the end of your code and maybe we can point out what's happening. Some of the confusion may come from OBCONTROL's intention of not confusing new users by hiding some of the machine/work coordinate offset stuff, so you're not seeing everything that's going on. Bear that in mind while you work, or consider a more advanced G-code sender. In general, it sounds like you may have some reading to do on G-code, modalities, machine setup (and traditions), and why things work the way they do. The LinuxCNC link should be helpful, as grbl tries to follow the LinuxCNC standard to the best of its hardware abilities.
I did Google parts of what I was given & in hindsight, yeah, Yy should've been obvious. But I didn't focus on the error because I believed that the macro wasn't doing what I intended. It was. I have both of these macros working now, and a third I made on my own. The end of my code looks like this: G0Z0.3250 G0Z0.8000 G0X0.0000Y0.0000 M02 Note that this code is identical to the code I used on my Shapeoko. Here's a discussion about this over in the Carbide Community. So with identical code, on the Shapeoko the spindle moves straight back the Y axis to the back of the machine, and on the Workbee it stays at work zero. It makes me think that Carbide Motion's doing something extra at the end of the program (not GRBL). When I first posted I thought I wanted the gantry to move back out of the way, but now I think it might be better to use the code or a macro to make it do what I want. Instead of going all the way back I can move it only as far as I need it... no wasted motion.
Hmm, that's odd. Certainly sounds like CM is adding its own extra flavor there, because I don't think that's standard behaviour. Shouldn't execute anything at all after the G0X0Y0, just reset to MDI and standard G54/G90/G17/etc settings. The macro definitely gives you more control, and I'm sure you can modify your post to insert it right before the M02.
