I made this simple small part (rectangle with 4 through holes in 2 dimensions) using OnShape CAM. First "real" part I tried to make. This part is going on our robot.



I was able to do this with OnShape CAM but it took me about 4 days of fighting issues with CAM to get it done.  It would have taken me about 2 hours in Fusion.  Some of this is just my learn curve time for new software, and most is just UI issues making things slower and more painful to work through but there were also bugs I had to work around, and a lack of features that forced me to HAND-CODE some g-code to get this done.

It used three different tools (3/8 end mill, 1/4" chamfer mill, and a twist drill), and three set-ups to define this.  There were 4 setups on the machine, but the last two were the same, so only 3 setups needed to be defined in CAM. I used 12 tool paths and 9 tool changes. This is all consistent with how I would have done it in Fusion as well.

BUGS That got in my way

Drill Depth Bug

This is documented in a separate forum post.  The drill operation doesn't drill to the correct drill depth at times. It's random, and strange as to when it works and when it doesn't, but even worse, the amount that it chooses to be off by, I could never predict.  But it was always between 0 and 1 mm, so never a larger error, but large enough to cause some real problems.

For this part, the problem was in trying to use a 45-deg chamfer mill to create those hole chamfers doing a drill operation to plunge to exactly the right depth to create exactly the right chamfer I needed.

Those are all .5mm chamfers on the part so an error in depth by +-1mm made the chamfers totally wrong.

John was sharing some ideas for working around this, but in the end, none of his ideas fixed it. What I had to do was read the G-code produced to figure out the error and then adjust the tool path to compensate.  In this case, I needed a depth of 1.63mm.  I put in a depth of 2mm, produced the G code, so that it was only drilling to 1.042m, did the math, changed my depth in the drill op to 2.588 and that got the gcode to the depth I wanted of 1.65mm.  Obviously, it's not working right.

This was only for the first setup for the top holes.  All the other holes didn't trigger the bug, so I had to use the correct depths.  But I had to very carefully look at the drawn tool paths, and simulations, and for double safety, read the g-code to verify it was doing what I wanted.

So, this took me over a day to figure out and work around.  Probably a day and a half.

Component Version Updating is Buggy

In my struggles to make all this work, I had to make about 16 version updates of the CAD studio to add or change features, like creating new curves to control a new tool path, or make minor changes to the part, like removing or changing chamfers.

Every time I need to important a new component, I have to fight the "update" option of the CAM Studio.  It seldom just works.  It's better if you only have one complete, but I had 4 defined (the model body, and 3 curves).  It will almost always correctly how the studio needs updating, and mark the components that are out of date with the blue circle, but it almost never works to update corretky.  OPick on, tell it to "update all" (the only option available) it runs for a while, then shows the one comment updated, but the others are left in odd states.  Sometimes they still have the Blue Circle, sometimes they don't.  And when you select them, even though the hover tag shows them out of date, it won't let you press the Update button on the dialog.

SOmetimes refreshing the page to make it update the status helps, sometimes it doesn't.  Often I have to delete components and re ad them to get it all back in sync.  It's a fight every time. And I had to do it 17 times before I finished this very simple CAM project.

This bug never stopped me, but it was a very frustrating fight every time that was very time-consuming. 

Missing UI Features that were a real problem

No Ability to produce separate G-Code programs for each setup.

This was a show-stopper.  I couldn't use OnShape CAM as it is to run this part because of this.  I had to hand-edit the g-code to produce what I needed since OnShape CAM didn't do it for me.

I was using the Haas Generic machine definition and haven't tested the other options.  Do other Machine defines get this right, and it's just a weakness of the Haas-generic?  If so, this is just a Machine Post processor bug request....

The problem is that each of the three setups needs to be separate programs with separate numbers (1001, 1002, 1003) and separate startup and init and end sequences.

In case anyone doesn't understand this here, the workflow for making a part like this on a typical 3 axis mill is along these lines:

First:
0) Put all the tooling in your tool holders, install it in the machine, and set all the tool offsets.  If your tool holder is large enough, you can do all the tools for all the setups.  Our tool holder holds 20 tools and I only used 3 total for this simple part (4 if you count the edge finder), so there was no problem loading all the tools up frong.

For each of the 4 setups, I had to run:
1) part in vise in the right orientation.
2) Probe the part to set up all the G54 offsets for the part origin, which match the offset definition used in the CAM setup.
3) Load the program for that setup (1001 for my first setup, 1002 for the second), and run it.
4) Inspect the part to see if all is good and if not, see if you can fix it by writing new CAM or changing the CAM you have, reload the fixes, and re-run as needed.
5) When all is good, remove the part from the vise, flip as needed, for the next setup.

This only works if you have a different program FOR EACH SETUP.

With the generic Haas profile I was using, OnShape couldn't do this.  There are only two options, either you produce one program for all three setups, all run together in a way that has no way of working since you have to pause the machine, flip the part, and change the G54 setting in the middle, which is not possible, or you produce g code for each of my 12 tool paths, load 12 g code files, and load each one manually, in order, and hope you get it all right.  Not a viable option for real work.

So what I did was let it generate one big file, then hand-modified the Gcode to split it up into the three different programs I needed.  And while I was there, fixed some of the absurd stuff it was doing, like homing all three axis and stopping the tool and coolant between every tool path, even though the tool paths were using the same tool and nothing needed to be homed or stopped. (it's painful to watch the machine home and then return to where it was ). But I assume this is just a lack of fancy code in the generic Haas post-processor that will be improved down the line.

So not only is this a lack of "export" button options, but you don't even have a way to define different program names for each setup yet which is a fundamental requirement of CAM.

A workaround (other than hand editing broken gcode as I selected) is to use a different CAM Studio for each setup.  But then the machined stock doesn't carry forward from each setup to the next, which is an important debugging tool to make sure you are defining each operation correctly and end up with exactly the part you need, after all three setups.

In addition, I didn't realize such an important feature was missing until after I had created the first versions of all these setups and tool paths in one CAM Studio.  I first, decided to copy, and then delete the extra setups. But as I started that, I realized it was too painful to both with, since there is no UI feature so delete an entire setup.  You must select bench entry in the list, delete, then say yes, then the screen redraws and jumps so you can't tell where you were in the list, study the list carefully to figure out what needs to be deleted next, repeat, for 40 steps until done. Repeat 3 times for the three files. So I gave up on the pain of that and went with the better solution for me, which was hand editing the gcode.

No Step-Down on Facing Op

This was a pain I had to work around.  On the second setup for the bottom, I had to take off about 1/4" of material which was overhanging all 4 sides -- left over from the first op.

I would normally do this with a facing 0p using multiple step-downs.  But that wasn't an option. So I tried using an adaptive clear to get rid of the stock. Nothing I tried worked (maybe some combination of options would work?).  The adaptive clear kept giving me "empty toolpath" errors (I couldn't find anything to machine even though I was using an extra curve to define the op, and tried with and without using re-maching of starting stock option, etc.  So I had to give up on that path, and decided to first rough using a face path with small step-overs.

The facing with small step-overs wasn't too hard to code (but required new control curves and more fighting the update bugs). But I forgot to consider would would happen when it was miching the last edge that was overhanging.

What happened as I machined it, was the last edge bent, and caught on the tool, which caused the part to pull out of the vise a little. It was trying to do this:



When it messed up and ended up looking like this:





The 1mm overhand I left for a second facing path to finish it, but the back edge there is where the roughing pass dug down into the part because it was pulled up on the left side.

This error, of course, was mine, but it was caused because I couldn't do the things I normally would do here -- which was to slowly take down the thick top a few mm at a pass so that it wouldn't run into this problem of trying to machine a thick piece not supported by the overhang.

In the end, the error was so minor I didn't need to remake the part. Most of the error in the picture was removed with the last finishing facing path.

Another way I like to deal with overhangs like this is to profile around the part to cut off most the overhang. Then the facing op isn't trying to cut material hanging in the air. But it's such a pain to define even a simple profile like this on the current CAM Studio, I didn't even bother to try that path.  Again, this is all after spending days on what should be a 2 hour CAM job.

So, please add step-down options to the facing op.

Annoying UI issues

As I work through the learning curve, I learn what to avoid and what works.  But some issues are still getting in my way.

The feature list is visually very confusing.

The setups, tool definitions, and tool ops all blend together so it's hard to find the feature you are looking for. There is no indentation for each setup (only the leading carrot has little visual impact), and the tool definitions of tool paths are too similar to be easy to separate without a moment of studying.  

Even for this very "simple" CAM job, my feature list expanded to two full screens (on my Laptop).  That's absurdly long and confusing for something so simple. So for example, I try to hunt down and change the second drilling op of the first setup, and I can't just visually go right to the correct location (end of the first setup) I have to read carefully multiple lines to figure out what position the screen is scrolled to,m and then carefully hunt down the future I'm looking for.  It's just painful.

They are spaced out too far, and they should use smaller fonts to allow more to be on one screen with less space between them (Part Stuiod is great this way).  The setup header should visually be very different, either in style, (bold font style etc) indentation or something, so I can finally see the setup vs. tool path structure in an instant.

The Tool definitions as separate features are a waste of screen space. Logically they make sense, but functionally, they just get in the way and waste vertical space. I'd rather the tools be defined elsewhere, like the top of the feature list where you define tools in order, like T1, T2, T3 etc, then in each tool path, you just link to which tool you are using in the tool path.  Vidually, the tool path could show the tool, and the name, like "T1 - Facing". That would reduce the meat of the job to just being setups and tool paths. And when you want to change operation orders to reduce tool changes (critical when hand changing tools) the data you need is right on the front of each tool path. So we end up with something along the lines of this:

T1 - 3/8 End Mill
T2 - 1/4" 45 deg Chamfer
T3 - #43 Twist Drill
TOP Setup
     T1 - Face
     T3 - Drill
     T1 - Roughing
     T1 - Profile
     T2 - Chamfer
     T2 - Spot Drill
     T3 - Drill Holes
BOTTOM Setup
     T1 - Rough Face
     T1 - Finish Face
     T2 - Chamfer
     T2 - Spot Drill
 SIDE Setup
     T2 - Spot Drill
     T3 - Drill Holes

Instead of something clean similar to the above, I have to search through this endless mess to find stuff constantly and it's irritating (and this is only what fits on one screen):



I know you guys have plans to do an overhaul on the UI, but I just wanted to share what is quite frustrating to me about the current one in case you had ideas for simple changes to help this before the total rewrite happens.

All geometry references are lost on a version update

I know this is just a missing feature that's not even easy to add, but it's so very annoying.  I make one simple change to a part like changing the size of a hole, then fight the update bugs to get it into the CAM Studio, then all the job, and tool path references are erased and I have to redefine them, even though the version change didn't make any changes to the parts they are referencing.

So this means every time I decide to make some change in CAD to support what I'm trying to do on the next tool path, it breaks all that came before it.  I have to click though each one, remember what edges I was using to drive each tool path, and re-enter them all, double check I got ir right.  Flip right vs left when that isn't right, then manually regenerate all the tool paths, manually regenerate all the stock.  Just to get back to the one new tool path I was trying to add.

17 versions I created, which means at least 17 times I was re-entering all the stuff on tool paths I had already finished.

I know that down the road, you can do this much better, but if you are trying to get a version released fast, then this will be a real turn-off to anyone actually using it for real work.It's why I had using Fusion for CAM after doing the CAD on OnShape. If I need to change the model on OnShape, I have to import a new body definition into Fusion, and replace the first one, and Fusion doesn't know it's the same body with a small change, so it breaks all the links and I must go though and update them all.

But if I CAD in fusion and CAM in fusion, it doesn't get lost like that. I can make a small change to the CAD, and it doesn't break all the CAM (sometimes nothing breaks).

The reason to use an integrated package is exactly to make this updating CAD not break the CAM.  But if you don't have even that working in CAM, then the motivation to switch to a very raw Alpah version of a new CAM system is near zero. If you release without this working, and the idea spreads through the community that this is just "not ready for use yet", then you have lost the momentum and once it is ready, it will be harder to get people to look at it again.  Sure, you want to release this to the customer base as fast as possible, and a raw product that needs improvements can work just fine, but not one that is both missing major features, has a poor and confusing UI (doesn't follow any of the OnbShape standards your uses expect), and fails to actually take advantage of why we all want an integrated CAD CAM system (quick seamless updating from CAD to CAM).

Conclusions

So again, despite issues with a few bugs, annoying UI, and some critical missing features, I still was able to make a real part using OnShape for CAD and CAM; It worked in the first try, and even a mistake on my part that caused a part pull out wasn't bad enough to force me to start over.  I got a good part first try.

You guys have a ton of critical stuff working and working well, which is great, but it only takes one iceberg, one hole, to sink the entire boat.

So it took me like 4 days of fighting with CAM studio to get the CAM ready.  And maybe 4 hours of setting up the machine, running it, and cleaning up.

Using Fusion for the CAD it would have taken me maybe 4 hours. So 4x8 hour days, for 32 hours, vs 4 hours.

In it's current form, as much as I want ot use OnShape for everything, it's just too painfully slow to use until some of these UI issues are improved.

Next

I hope to continue to explore and learn the rest of the tool paths and all their options to get over that learning curve hump.

I need to test taping.

There was an error of some arcs generated by the Haas Generic post-processor that my machine didn't like, which I got around just by turning off arcs.  But I want to look at that and find out why my machine didn't like it, so you guys can consider updating your post processor for this machine. Converting arcs to lines causes the size of the program to explode and fill up almost all my limited 1MB of memory on the machine. So it's best to not have to do that. It was in a helix move that triggered this and I know this Haas can do a heix with arcs, I just don't know what was wrong with the way the post-processor coded it.

Test the other 4 or 5 machines I have access to.  Once I master a better understanding of all the features and bugs of CAM Studio on this first machine, I'll try running the same test parts on the other machines to see if there are 1) post-processors that work for them and 2) if so, what bugs or other issues there are with them.

If I get more real parts for work, I'll try to do them on CAM Stuidio first, but if time constraints or frustration runs too high, I'll punt and go to Fusion.