Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.
First time visiting? Here are some places to start:- Looking for a certain topic? Check out the categories filter or use Search (upper right).
- Need support? Ask a question to our Community Support category.
- Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
- Be respectful, on topic and if you see a problem, Flag it.
If you would like to contact our Community Manager personally, feel free to send a private message or an email.
CAM "losing" zero
jeremiah_peschka840
Member Posts: 14 PRO
I've been working on a commission and I'm ready to get the CAM working. I've split out the relevant parts into derived part studios and then created a CAM studio for each of those derived parts. So far, so good. You can find the parts in this document, hopefully this is linking to "Side One - CAM" (please ignore my poor naming conventions).
With the release of Masso support, I decided to pick up some MDF to make sample pieces. The tool path for T2 works fine, although it's exceptionally slow (my fault for the adaptive feed rate settings). After the T2 tool path is complete, the machine moves to the back of the bed, comes forward to change to T3 manually, and then moves to the back of bed again.
When the tool path for T3 begins, the machine rapids forward on X, Y, and Z. This smashes the tool into the work piece at a good clip and breaks the tool. It seems like I've set something up incorrectly, possibly in the Linking settings. You can kind of see where the tool smacked into the MDF twice, as well as the busted parts of the tool.
I've attached the g-code as a TXT file.
The question:
What can I change here to ensure that this doesn't happen?
Answers
I know enough about g-code to know I don't know enough….. I'm about 95% sure this is your problem.
When I was using mach 3 and fusion 360 it would crash just like you between tool changes. The Z would rapid down into my workpiece and/or table. If you have a G28 in your code, there should be a setting in your machine controller (not CAM) to set that position to a safe place. Or, don't include it in your code. You'll have to figure out what setting in OS CAM is including it. Either way to fix it should work. You'll need to understand what g28 does and how Onshape CAM and Masso controller handle it.
Search the g-code the G28 will come up 6 times, twice at the end of every tool. All of them can result in the same crash.
Hope I'm not offbase here, but G28 is the home positionm often called before a tool change, do that makes sense since you are changing to T3 a few lines later. I don't see the point in moving to Z0 and then Y0 immediately after the G28 and right before the before the tool change. Maybe the post processor or your CAM tool pathe needs adjusting. What is part zero, particularly Z, set to?
What do the next few lines after the tool change look like?
Aye, the G28 makes sense, in a way, but certainly not for efficiency purposes. I'd think that moving to the work origin Y0 after moving to machine Z0 makes more sense - now you're in a known good place relative to the part.
The part's Z zero is set to the bottom of the part. I've read that this is a better workflow than having Z zero on the top of the part, for consistency's sake.
Here's the code before and after the tool change. Is the
( Setup )line starting the rapid movement toward work coordinate system 0 that results in tool breakage? I'm not sure, g-code is still new to me.Reviewing this gcode step by step, I'm becoming convinced that the error lies in the machine itself, not in the g-code. I have opened a ticket with support to discuss this issue - it makes more sense to me to reference X0 and Y0 from the current work item, but Z0 from the machine (at least, with the generic Masso controller set up).
There's a possibility that static build up cause the machine to become confused about its current location. I haven't seen this happen since I replaced the original Carbide3D controller with the Masso unit, but it's entirely possible. I'll report back after an attempt tomorrow, but with more grounding than I would have thought is needed.
My money is still on g28. It happens to about every hobbiest (me included). The cam puts it in there because the pro machine controls and operators understand it and are expecting it. Us hobbyists are not.
Re-ran things again today with new bits and the g-code ran perfectly. I am not sure why it worked, but it did. I'll take it.
If anyone does have an idea, I'd still appreciate it.