So I am running CNCjs, but have run UGS as well. Once on UGS, and now a few times on CNCjs, when my origin is not at at start point, it has to rapid transit to the first cut. It will drop 16mm (or similar depth) rapid, then begin operations at normal top height.
Not an issue with zero’ing at top height, and my retracts in Fusion360 are all around 2mm for clearance.
If I reload the Gcode, it’s fine. Kinda random. With plastics I can stop machine before endmill destruction. The CNCjs display actually shows -16mm on Z as it does this (I saw it once, other times I was not able to look at monitor). Then it goes to Z=0 and begins proper plunge.
Ideas as to what is happening?
Update: I now manually set “Z8” in the place where you must delete the tool selection, and it goes to 8mm. Basically Fusion360 is not defining the first Z, so I feel that led to random instability. Why does fusion360 not make the first order some retract height, etc?!?
Photo:
Origin is corner point of item, it transits fast thru PVC and then tries to start ‘proper’ pocket drilling at first hole. Today had a similar fail on the other axis too.
If you check “minimize tool changes” it won’t insert the tool change.
Regarding the move…
It moves from where the carriage is to the start point. It actually goes to the clearance height, then to the first cut point. If you haven’t set the safety/clearance height well above the material, it can run into things. Set the clearance height near the top of Z travel when you have a part that sticks up like this in the middle of the work area. It can be a lot lower when the part is flat. Another alternative is to jog to roughly home position (just homing may run the tool into material) , and start the program from there.
Sure, my clearance heights are always +2 to +10mm in what I draw up, and paths are cleared from hold-downs etc. The issue is a deliberate, and variable lowering of Z axis way below the top surface (and Z Zero) prior to rapid transit. One time it just sat there skipping the belt, and also completely irregular, might do it twice in a row then not again for 3 cuts with the same file and same zeroing spot. Or reload the same Gcode and problem goes away.
I guess the issue I am pointing to, is that the g-code appears to not define Z prior to G0 moves. By sticking Z8 in there, I (for now) get reliable results. So problem sorta fixed, but I’d love to learn more about the malfunction and the omission of a Z order early on?
Thx for ‘minimize tool chages’ I will look for it soon.
How are you setting your zero?
Can you share your Fusion file?
What post are you using?
EDIT: Just looked at your code. Get rid of the G28 unless you know what it does and intended it to be there. Where’s your Z coordinate for G28? That’s where it’s going. Not sure why a Z8 seems to fix it. It would still go to G28’s Z location before moving on
The elimination of G28 has been implemented, correct, it can be a problem in my workflow. So I do not zero to machine, on the basis that ‘driving’ the turret all the way right top is a distance, a risk of hitting fixtures, and serves no benefit to me (unless you can convince me otherwise). I set zero to the stock at a point that is corner to rectangular piece usually. Then zero to contact surface of stock. With the 3 zeroed axis I run it, paying no attention to the ‘global zeros’ just interested in the zeros relevant to my workpiece. I have also been keeping the Z8 up there as I feel that an undefined first coordinate is less secure than a defined one, there is no pain in ordering it to go 8mm over workpiece pre-start eh? Also read on G90 and G91 codes. Not sure why Fusion is putting a G91 Z0 up there. That says “Incrementally change Z zero units” Which is basically ‘do nothing’. Idea on that one?
Post is “Carbide 3D (Grbl) / carbide 3d” within Fusion360’s selections.
G28 G91 Z0 means go to G28’s location with an intermediate stop that is zero mm relative (G91) to my current spot. The reason you need the Z0 is to command the machine to only move the Z.
G28 without an axis word will move X,Y,&Z simultaneously. The reason it uses relative mode (G91) is so that you don’t move the Z to a work coordinate Z before moving to G28’s Z location.
If you don’t have G28 set with a safe Z, or don’t know where it is, don’t use it in your gcode. I’d recommend being familiar with it, though.
I guess the G28 demon smited me again… Below is the end script from a run where the end called for a movement to the left 7 inches at Z-2.4. So minor endmill snap, no biggie… Was cutting the tuning fork and it ran left, struck then ran right on it’s own to where its seen in photo.
Thanks Neil,
In this google folder below you will find the post from Fusion360, which I use. Feel free to drop any post(s) there that you feel may be more useful for our machines.
Thx.
No write permission to your folder. Here’s the one I use, and it works great. I’ve not been happy with the “official” carbide3d post. Has both the one I modified, and the one I downloaded (known as the “Strooom” post: https://github.com/Strooom/GRBL-Post-Processor)
In the .cps (it’s not cpp, by the way) . there is a function at the end called “onClose” - this is the code that runs at the end of the post, before it closes the file.
Look for the comment inside “onSection”
// Rapid move to initial position, first XY, then Z
The two “writeBlock” calls right below are the first moves.
I’m not near a computer that has capability to do anything, but I have one post on my A360 drive.
It’s based on the default grbl post, and has user-defined options for G28 and Tool Changes. https://autode.sk/2DjBl5M
