Your code is in inches as indicated by the G20 command at the top. G21 is for mm. Its a modal command which means that you'll stay in inches until its changed by a G21. Not sure how the Duet handles homing, but if it doesnt specify G21, then your homing command is running in inches and that's probably why you are slamming into things. i.e. instead of moving to 10 mm its trying to move to 10 inches.
Yes, I know - it keeps crashing my phone! - I'll look at it on my desktop later - could you please delete that post? Thanks Alex
I should also caution you that merely changing the G20 to a G21 then rerunning the code will NOT give you the results you'd expect. You need to regenerate the entire code, but this time using mm instead of inches. Hope that makes sense.
Ahhh, ok. Thanks for that. I wonder how I've managed that then... I think whats happened is the trial software I was using was in inches initially, and I tried changing it all to metric. I mustn't have followed it all through. Completely understand what you're saying. I'll generate the code again tomorrow as per the intentions of the trial software, and run it again. Really appreciate the help @Alex Chambers and @sharmstr. Cheers, Graeme
BTW Graeme, the information that told @sharmstr and me what was causing the problem was that the Z axis was going up before crashing down and it only happened after running G code - your stepper motor cables are probably OK. Alex.
Noted, thanks Alex. I'm going to generate new g-code tonight, without me interfering in any switching of units, and see how that goes. Cheers, Graeme
Open your G code in notepad or wordpad and check you have G21 at the start and not G 20 before you run it. I'm going to have a look at the homing macros to see if they need to be modified to reset to mm before they do the homing moves. Alex.
Will do Alex, thanks. Ryan from Ooznest has just responded to me. He ran my g-code, and all worked as expected for him. I was hoping he would see the issue I experienced. He has given me a test file to run, so I'll try that tonight as well. Cheers, Graeme
Just to provide an update, I ran the test g-code file that Ryan from Ooznest sent me. The g-code and homing afterwards, both worked perfectly. I'll redo my original g-code tomorrow and run it again. Cheers, Graeme
If you don't manage to create your G code in mm you could always add a G21 to the end to switch back to mm before homing. Alex.
Ahh, that's handy to know. Thanks @Alex Chambers. I need to have a good read-up on understanding g-code now.
I've just sent a message to Ryan at Ooznest to confirm which files are the homing macros. I'll let you (and everybody else who might be having a play with Vectric's trial software) know which they are and how they need to be modified when he replies. Alex.
I was looking at their macros and none of them call out G21. Not all of them need it, but for example, the Return To Work Zero one could cause some issues if not set. I suppose that's fine if you always work in mm which they suggest on their firmware page (For all Vectric Products use GRBL (mm) (*.g-code)). I would also assume that the majority of their customers work in mm too. If you look at their Fusion post, you'll see that it throws an error if you try to post in inches. Not sure how Vectric works, but it would be nice if there was a similar error. Another thing I found is that their probing routines dont reset G90: G Code (G21), XYZ Touch Probe Question @G-Wizard I'm curious as to why you are homing after running a job.
Ooznest are British - we gave up on inches (at least the younger generation(s) did ) some time ago. A few people on here are playing with trial versions of Vectric software so I thought it would be a good idea to try to catch a simple error that could knock a machine out of alignment if not damage it. Personally I think every bit of G-code should try to be fail-safe - if nothing else it's good practice for people like me who are just beginning to scratch the surface of this. Oozenest wrote the Fusion post so they have protected their machines from people who are not paying attention, but they are recommending the generic grbl (mm) post for Vectric. Alex.
It was for no other reason than to move the gantry out of the way to better view the workpiece. Is it not normal practice to home the machine on completion of a job? Cheers, Graeme
Like you I home all axes after a job as the quickest way of getting the tool out of the way so I can get at the workpiece - don't like getting my hands caught on the tool. Alex
In my naivety, I jogged the machine over the job of my hand with a cutter in it... resulted in a nice chunk out my knuckle. Lesson learned!
There's no rule saying to cant rehome after. However, the limit switches that these hobby machine's come with aren't exactly accurate so there is potential that your work coordinates will drift. Not a big deal if you're doing a one off with one tool. But if you're doing multiple pieces and/or multiple tools, it could be a problem. What a lot of people do is have code at the end of the file that will raise the spindle to a safe plane, then move to a designated place. Usually I always have it move to where I like to do tool changes. The OB fusion post allows you to set this so its automatically added to the gcode. It doesnt look like the ooznest post does. (Not sure about the vectric post because I only use fusion) But you could always program a macro to do it. Just need to aware of your clamps, which you also need to do if you're homing. (The shortcut to all of this is to use G30 but that's for another discussion.) Take all this with a grain of salt. Just something to be aware of and not a declaration of the only way to do it.
It's all good information, thanks for the response. I'm sure the more familiar I get with the machine and the software, I'll want to start looking in to this kind of stuff a bit more. Cheers, Graeme
Hi @G-Wizard, did you manage to get your sign cut yet? I'm going to have a look at the resources on cnc cookbook to try to learn some basic gcode. I suspect some of the fancier bits won't be supported on our machines - like canned cycles, I don't even know if we have support for arcs or whether our post processor is converting circles to a series of straight lines. Alex.
Hi @Alex Chambers, Time wasn't on my side yesterday, unfortunately. When I did have a quick look, I couldn't fathom how to change the trial sign to mm from the start. Any changes you make to the trial software doesn't allow you to save the file as far as I can see. I'm quite happy that I managed to run the Ooznest file no problem at all, and have the machine behave like it should. Doubt I'll get a chance today, as I'm off out. Any "cutting" I've done this far has been with fresh air, or a pen. Don't want to go breaking any the cutters just yet... Cheers, Graeme
Is that a vectric trial? It should generate mm g code if you use the grbl (mm) post processor - I think the trial software let's you do that even if the drawing is in inches. Alex .
Hello Alex, A bit off topic but I've also been trying to learn (emphasis on trying) some basic g code. I've been looking at the gnea/grbl and it lists the supported gcodes a bit further down the page. There's a link in there to the linuxcnc site which gives a much more verbose description but it makes my brain hurt! Grbl does support arcs but with limitations apparently. I'm not sure what @David the swarfer has done in his post processor swarfer/GRBL-Post-Processor I tried to read it but got lost when it started mentioning circular planes and faulty arc problems at line 47! My last bit of programming was BASIC on a BBC micro so I'm just a little bit out of my depth! Hopefully not too off topic Cheers Adam
Thanks both, I have the added problem of working out how/if the Duet differs from generic grbl. I was going to start by creating some simple G code and seeing what the Fusion post processor did with it. @sharmstr - I am intrigued by G30 and intend to explore that further - I take your point about the limit switches not being too reliable as a reference point. Alex
Neither the ooznest or the OB fusion post spit out a G30. Not sure why they dont, but I use it on my Tormach mill. If you have tested out the new OB post I sent you a link to, you'll see that there are properties you can set to specify where you want your spindle to go after the job is complete. Its handy. I suppose you could move your spindle to where you like it to be after a program ends, set the location with a G30.1 command, then add a macro that calls G30 or add it to your gcode. What I dont know since I havent used G30 with grbl yet, is how the movement is handled. I know on my Tormach it will move the spindle up first, then make its X,Y move. Its something to look into before you use it. If it moves all 3 axis at the same time, then you need to be aware of it and how it may ram into clamps and such. Here's some info fromt the grbl wiki TIP: After running a homing cycle, rather jogging manually all the time to a position in the middle of your workspace volume. You can set a G28 or G30 pre-defined position to be your post-homing position, closer to where you'll be machining. To set these, you'll first need to jog your machine to where you would want it to move to after homing. Type G28.1 (or G30.1) to have Grbl store that position. So then after '$H' homing, you could just enter 'G28' (or 'G30') and it'll move there auto-magically. In general, I would just move the XY axis to the center and leave the Z-axis up. This ensures that there isn't a chance the tool in the spindle will interfere and that it doesn't catch on anything.
