hmmm, I recall merging stuff, maybe I did not push it to github, I will check when I get near the laptop tonight.
@sharmstr scratch the issues with the z bottoming out at the end stops, i changed my Homez in the post processor back to -10(thought i was smart and changed it to 0) and away it went. Still curious how those settings effect the post process of the data. Thanks
Fusion does safe begin and end moves using machine co-ordinates (accessed by G53). So a 'G53 G0 Z0' should move Z as high as possible so that a following X and Y move is safe = tool is going to be above material and clamps on the table. This works perfectly on my machine which does not have limit switches so machine 0 is a safe place it go to. (I always turn it on and turn it off in a home position so that this always works) On a machine like yours that has limit switches machine 0 is actually touching the switch so going to Z0 is a problem. To avoid this the post allows you to enter an offset from machine 0 so that it can safely go to 'close to home' without tripping a limit switch. So when you enter a -10 for 'HomeZ' it gives a command like G53 G0 Z-10 to safely raise Z without hitting the limit. You may be able to use a value as low as -1 that will raise Z a little bit further yet still safely not hit the limit. Note that G53 is not modal like G54-59 are, to use machine coordinates you have to put the G53 on every line that needs it. On the other hand one G54 will be remembered (the mode is set) until it is changed to g55 or whatever is needed. We small machine users tend not to use anything but G54 for our workpiece so it will seldom be changed.
Give me a couple of days. I want to update the instructions. Also, do we still need the easel post in there? EDIT: Just noticed they finally fixed the property groups, so I'll also working on that to make it easy to understand.
Those aren't mine. Those are from a long time ago. So no. FYI - any setting in green means its set to the default. It changes to blue if you modify it. I'll be updating those with the new documentation.
Thanks @David the swarfer and @sharmstr, David thanks for the explanation that is kind of what i thount once i realized setting it back to -10 worked fine and looking at the gcode commands, it was just weird to wrap my head around having work coordinates set and it still wanted to relate to machine coordinates that was a new one for me nut coming from 3d printing im not used to working with 2 sets of set of coordinate systems so i am still learning how they can intermingle, thank you for that. @sharmstr thanks, i just matched whatever settings i could to my machine settings and left the rest alone, seems to be working fine. Just finished a 2hr first pass and currently running 2nd pass with a tool change everything is working great. thanks a lot for the help!
um, there are actually 7 coordinates systems (-: G53 is the machine coordinate system (MCS), everything is relative to this, homing sets this to 0,0,0 G54 to G59 - six Work coordinate systems (WCS). you can use these in various ways or just stay simple and use G54 for everything. For example when I get my laser mounted I will use G55 for the WCS for all the laser code and G54 for the router. This way I can combine the laser and router code into one file and walk away while it gets on with it.
aaaand all the more advanced controllers have many more coordinate systems. So for example on a horizontal 4 axis mill with a 4 sided tombstone on the table, and each side of the tombstone has 8 vices with a part, you would need 4x8=32 work coordinate systems so you can index each vice in turn. In this way you can write code that runs through each WCS in turn, but runs the exact same code for each part because the code is always relative to the current WCS.
Holy crap i was just looking at the possibility of adding a laser mounted along side my dewalt to do just that i hadnt thought about be able to run the together in one project that is awesome i, i know im a few steps a away from advancing to that but that is definitely on my future docket, i would love to see any write or build post you do on that if you do any, thats awesome! I was just going to ask, i read somewhere that grbl couldnt handle another axis for doing things like adding a rotary, is that true or was that old information i came across a while ago that is also something i want to look into....eventually haha. Thanks for all the info it all makes sense what you are saying i guess i have a lot to research on utilizing work coordinates and different ucs to get max benefit...or just keep it simple stupid and be happy its working like i want it .... ill post some pics here shortly of what i cut out today thanks again!
This is still true for GRBL 1.1g on Arduino Uno. there are some ports for the Arduino Mega that handle extra axes but I don't know how good they are. We are all eagerly awaiting the next version of GRBL which will run on an ARM chip like the Arduino M0 board. This chip has a lot more memory and clock speed so it will handle all sorts of new things. Hopefully 'real soon now' (-:
