This is the one I use when I want to use @sharmstr's post processor Alex. I just used it to post process your Fusion file - it still put that G0 Z-10 in. The post processor I normally use (no use to you - it's specific to the Duet controller) doesn't do that. PS the file name is OpenbuildsGRBL.cps
All jobs start by raising the spindle to -10mm below machine Z0. That's good and normal (as long as you have clearance for it). The Fusion file looks fine to me. My guess is that its mechanical. When the Z goes down to the bottom, what does the DRO say? As for the properties, the machine variables (control, model, vendor) aren't used by the post processor. You can type in R2D2 in there and it will have no effect on the output code.
DRO is jargon to me too @Matt Thorniley, but EMI means electro magnetic induction (or interference). You need to make sure that any mains leads (especially router lead and even more especially if you are using a spindle with VFD) are as far away from any low voltage cables as possible. In particular try to avoid having mains cables close to and parallel to low voltage. Alex. PS you don't check for it without specialist gear - just try to avoid creating a situation where it is more likely.
Sorry. DRO = Digital Readout. The boxes that tell you where you are. See image below. According to your gcode, it should start cutting -1mm below the stock top. If your DRO for Z says -1mm but your bit is cutting well below that (as shown in your photos) then 1 of 2 things are causing this. 1 - You set your Z0 to below your stock or 2 - Your machine has lost its mind because of EMI - Electromagnetic Interference. Routers can cause this (we can go more indepth later). EDIT: 3rd reason: Mechanical. Your Z axis is is slipping/losing steps
Yahoo! So I went and made sure my power cord was out of the way. Not sure if that had anything to do with it, but I was taking screenshots of my grbl settings and noted that there was a drop down for the cbeam settings. I thought- hey why not load that instead of the custom settings sent previously and voila! It works! Once it was reloaded I did have to change the axis invert on all 3, but once I did it works. Not sure what I did wrong to begin with, but now I think it was the controller settings got screwed up.
I still can't figure out why the 2nd-last pass do not follow exactly the tool path. If you look at the one photo quite a few replies ago it clearly shows that they do not. I can sand that out, but it is still functioning like that on every blank.
Arrgh! @Alex Chambers , @sharmstr, and @Peter Van Der Walt ..... It has happened again! I shut down the computer over night and opened up the program this morning and went back to work. I made sure everything was at 000 and hit run. The spindle bottoms out as before. So I thought- Hm, last time I reloaded the parameters in the controller program, why not do that again? no such luck. I reloaded the gcode- nada. reset 000- again no good. What the heck is going on? I know it's not the Gcode because it has worked several times. I have checked for EMI. something is weird with the controller program. Has anyone else had any issues like this?
@Alex Chambers did you say that you use Mach 3 as your controller? Will that work with my grbl board? I at my wits end. This works great when its running right, but if I can't figure out why the machine keeps doing this error I don't know what other avenue to do
I can't help much if its Openbuilds Control problems, but if your digital readout says Z0 at the start - what is it saying as the file starts and the bit plunges? Alex.
Hi Matt, @sharmstr and I have both asked this but you haven't answered - what does your readout say the Z position is when the bit plunges unexpectedly? Alex.
Thanks Matt - we were obviously both posting at the same time. @sharmstr knows a lot more about this than I do, but I'll have another look at your nc file. Could you please post the latest version. Alex.
You dont need to reload the Grbl settings all the time. In fact doing so will wear out your controller! The EEPROM only has a limited number of read/write cycles, besides thats never the solution 1. Setup your machine correctly (Cartesian standard, distances correct, switches and homing correct etc. No skipping steps, etc. All as it should be 2. Settings is now of of the way... next step, CAM settings 3. Use a simple, easy Grbl compatible Post processor, read the gcode and understand it: Lookup Gxx terms you don't understand LinuxCNC "G-Code" Quick Reference 4. Understand the difference between MACHINE COORDINATES and WORK COORDINATES 4.1 If your GCODE contains Machine coordinate based moves (G53, G28 etc) better be darn sure your machine positions is set correctly by homing and that all settings related to homing is perfect. As a beginner of your skill level I strongly advise against using Machine coordinates - its complicated! 4.2 If your GCODE only uses proper WORK coordinates, all in one coordinate system (G54) its going to be best. Then the abstract concept of a "second layer of positions in a different coordinate system" doesnt come into play. Enough to worry about when you begin, so stay in one coordinate system! 5. With your gcode loaded, jog to where 0,0,0 should be and hit setzero. EVERYTIME before running a job so for that job it knows where 0 is and it will then only do what the gcode does. It doesnt have a mind of its own. it just does what the gcode tells it to do... So if you gcode has Machine coordinates in there it will do confusing moves if you dont yet know how to handle coordinate systems. Keep it simple!
Oh one other suggestion. Fusion360 is hard! Take a break from this project for a bit and do one of the simple Hello Worlds in OpenBuilds CAM Gcode Creator - Public Beta -> You'll see now that the simplified interface and GCODE outputs that fitting of beginners, make for a much better initial experience. Then as skill builds, Fusion may be your go to, but we really did make it as easy as it can be with OpenBuildsCAM: Would just boost your confidence to see that with proper gcode you get repeatable results https://www.youtube.com/watch?v=kI-0n1tFO5U
Peter did you look at my setting for the controller? are they correct? I use open builds post processor and it spits out Gcode that has worked in the past. I do 0 every time.( tired to do it once running from where the machine stopped on its last run, but obviously the trace was not correct). It is very strange that it was working last night until 6:00. I shut down the computer and reopened it this morning. Once I did it started acting like it was going to trace from the bottom of the spoiler board up. why would it work fine the night before and go bad over night? I didn't change anything prior to starting this morning. I have tried 2 different Gcodes and they both do the same.
Hi @Matt Thorniley, do you have limit switches on your machine? Do you home all axes when you switch the machine on? Alex.
Off the top of my head, hard to say. Did you load the preconfigured profile (Thats the profile we know is correct. I saw you mentioned inverting axis, thats fine, just adapting to Wiring differences) Fair enough, but... Machine coordinates cannot be "setzero"ed so the gcode will work repeatable as long as Machine coordinates dont change (the DRO shows WORK COORDINATES, not MACHINE COORDINATES) ... Reset the controller, power cycle, power failure overnight that goes unnoticed, and bam, machine position is different. Run it now and it will do weird stuff... Note the G53 present in the gcode you just uploaded: See G Codes Change the post processor to not use any G53/Machine Coordinate moves Homing/Coordinate Systems/etc I would recommend someone work with a machine for at least a couple months, it is complicated We do not have an official post processor. There are community contributed ones...
No limit switches. Could this be one of the issues? I forgot to turn the machine off last night. It was on all night. I do set 0 axis every time. For some reason even when I go to my set zero point it is off on the Y axis.
1. If you dont have limits, you cannot home. If you cannot home, you cannot SET the G53 Coordinates. G53's X0Y0Z0 is only set by powercycling Grbl, or by Homing 2. "I do set 0 axis" That sets zero in G54. Not in G53. Think of G53 and G54 as layers on top of each other. Setpoints will almost never overlap. 3. As you don't home, your "where is 0,0,0, in g53" question can never be reliable... avoid using G53 moves (and G28, etc) There are ways to manage G53 without homing but you got to have a good understanding first.
You can not... There is no command to set G53 zero as Machine coordinates should be a fixed forever value (homing sets it) Please, just heed the advice. Ignore Machine Coordinates, Pretend it doesnt exist. As if you never heard of it. Eliminate G53 from your workflow and only work in G54. In G54 you have all the freedoms like setting zero etc.
