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: 17 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?
Best Answer
-
jeremiah_peschka840
Member Posts: 17 PRO
I have found the problem, but not solved it.
I created a pair of simple repro programs (attached as "repro 1.txt" and "repro 2.txt") and attempted to verify that there's no issue. I have verified that it's not actually the rapids causing the issue, but the tool setter on my machine.
- Set up a 1-2-3 block on end so that the "work surface" is 3 inches above the machine bed.
- Loaded T2 "manually" (t2 m06).
- Zeroed Z to the top of the 1-2-3 block using T2 and the XYZ probe block.
- Removed the XYZ probe block and the 1-2-3 block from the machine.
- Ran the program.
- Noticed that the second tool received an incorrect length.
- Loaded T2 manually again.
- Opened F1 setup screen. Noticed that the tool setter was showing the incorrect high/low setting.
- Gave the tool setter a gentle tap to jog its memory (uh oh).
- Ran the program.
- Things are successful.
Time to clean a tool setter!
0
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.
I don't have an answer for why this keeps happening, but it does. The issue occurs on the third line down from
( Setup )(line ending in F254:Is there a way to force CAM studio to move toward the work piece in just XY then followed by Z? That seems significantly safer for rapiding into my workpiece.
Edit: the work piece in question is 3/4" thick (19.05mm for the 99% of the world who aren't Americans). Since I have closed loop steppers, I'm guessing that I'm not losing steps.
Would I be correct in assuming that the machine has lost the zero for Z in this scenario?
I have found the problem, but not solved it.
I created a pair of simple repro programs (attached as "repro 1.txt" and "repro 2.txt") and attempted to verify that there's no issue. I have verified that it's not actually the rapids causing the issue, but the tool setter on my machine.
Time to clean a tool setter!
@jeremiah_peschka840 Happy that you were able to resolve this issue. Feel free to post some pictures of the parts you cut!
Y'all have been awesome, both in the forums and privately as support people. Thank you.
I'll be sure to upload some in progress photos as well as the finished product in a new thread. This has been a great learning experience that's been made better through the help I've gotten here and elsewhere.