RhinoCam, Issue with Valley Remachining

I’m hoping a few people around here are using RhinoCam? I am having a problem with my “clean up” passes cutting too deep.

I am parallel finishing with a 1/2" ballnose, which is leaving material that needs to be cleaned up. So I created “between curve” finishing toolpath that follows my fillets, using a 1/8" tapered ballnose. The simulation looked perfect, but in reality it cut too deeply in certain areas, forcing me to start over. I’d say it is close to .020" too deep

I tried again, this time I used “Valley Remachining”. This did the same thing with the same 1/8" tapered ballnose, and it cut too deep. About the same depth as before.

For these attempts I set my parameters to leave 0.0" stock for all tool paths. And tolerance is ± .001". Absolute tolerance is 0.00001". Step over was .005". And I have arc fitting enabled.

I had been using my CNC’s built in tool height sensor, so I took some time to test its repeatability and accuracy. I saw variation of ~0.003" between the 1/2" ballnose and the 1/8" ballnose. This is not nearly enough to explain the issue, but something I will pay more attention to in the future!

Now I’m back at the computer, starting over in a new file. I created the parallel machining and valley remachining tool paths. This time the simulation of the Valley Remachining tool path actually shows the issue I was experiencing. In this new file the stock parameter is 0.01" on both. (I’m machining MDF, and in order to end up with a good surface, I will apply epoxy to stabilize the MDF and re-cut to the actual dimensions.)

Unfortunately everything in this file is curved, so there isn’t any geometry I can measure on the finished part to determine which tool path is cutting the correct depth. And the compare feature isn’t being helpful. I’m currently trying to get a second opinion by running a polygon simulation. But that will take some time.

(The flat surface should transition smoothly to the curved surface, but here there is a dip inbetween.)

That image shows some pretty rough looking graphics. Do you have your simulation set on Voxel model or Polygon model?

I would double check your tool pick-up. We run paths like this all day long with no issues. If the issue persists I would suggest using MecSoft’s support. They are very helpful.


And make sure your tool is well seated/tightened in the holder !!

Yeah, the simulation is about the best I can manage. Most of the time I can’t get a polygon model to simulate at all. When I run it, Rhino becomes non-responsive. I check the activity monitor and it shows all cores are active, but nothing is happening. The problem seems to be a moving target. For example, yesterday the Voxel simulation would run fast (i.e. utilize GPU) when the model was hidden, but it would go very slow (no GPU) when the model was visible. Toggling back and forth was like shifting between high and low gears. But it doesn’t seem to be doing that today. And RhinoCam never utilizes the GPU for the polygon model, which I’ve wondered about.

Getting a working tool path is what I need right now, so I’m not too concerned about the simulation looking good. Of course that plan hasn’t completely worked!

I should probably make a different thread for the computer aspect of my problems…but I have a newly built machine for CAD/ CAM. It’s an i9-11900kf + 64gb ram + 2tb nvme + Quadro P2200. I thought this would plenty. Rhino runs great. RhinoCam is another story. It acts like it’s bottlenecked somewhere, but the CPU is among the fastest single core processors around, the GPU isn’t being utilized very heavily, and RAM definitely isn’t an issue.

Yes, I already learned that lesson. I have a gouge in my table to prove it! But I do not have ATC, so tool pick-up isn’t the issue. And I have been using the tool height sensor, which adjusts the z zero pretty close. I found out it isn’t perfect, but it isn’t the cause of this problem.

Yes, it seems like that should work fine. Is it only that one file, or is it always like that? I run RhinoCAM here on a 2018 laptop with an i7, 32Gb RAM and a 4Gb P2000 and it runs pretty fast, including simulations - of course, very dense/fine toolpaths do take longer to simulate. I always run polygon simulations, accuracy standard or medium, the voxel model is just too coarse.

One other thing to check - you say you programmed a “1/8” tapered ballnose". Have you tried programming a straight ballnose to see if that changes anything?

I would definitely take this up with Mecsoft support if the problem continues.

Thanks. I will try different tools. The slow simulation issues start with the horizontal roughing pass, which is the least complicated.

Does your computer use GPU for the polygon tool path? Or does it run on CPU?

In the process of figuring out what the problem is that I need to get help with, I think I mostly solved the problems I was having.

For the simulation, I changed the absolute tolerance to .0001" from .00001". In a RhinoCam webinar one of the guys said, “Modern computers are so good at floating point calculations…” and he didn’t recommend changing absolute tolerance. But changing the tolerance seems to have helped.

For the tool paths that looked like they were cutting too deep, I’m pretty sure those finishing tool paths did not completely overlap with the previous tool. For the simulation above I used the curve machining path, and I adjusted the “band” to be wider. Now the simulation looks good. I haven’t run it yet, so fingers crossed!

I suppose the question I still need to ask support is about settings for better simulation speed and stability. My computer is struggling, but I can’t tell what the bottleneck is. The majority of my system resources are free, but it is acting like it’s running out of memory or CPU, going non-responsive and crashing.

My project is large, atleast for me. The region that is parallel machined is ~20x22", and I’m using a stepover of .012". So I guess that is a lot of data, and it takes about 6hrs to run on my CNC.

If you want to upload a sample file that is giving you problems somewhere and send me a download link via PM, I’ll be happy to test it here and see if the simulation runs better or not.

For the record, I’ve been working on the issues I was having, and I believe it is solved.

My router was not trammed in quite right, which resulted in the tool tip moving side to side relative to zero, depending on the tool length.

I knew it was a little off, but I only thought it would only matter with an endmill. It’s kind of a sore subject, because the mfg claimed theirs is the most accurate. But mine was not very good. I had worked on it a little before, but I hadn’t gone over everything.

But anyway, I was dragging my feet on buying a decent indicator and fixing everything. I spent a fair chunk of my time last week adjusting everything on my machine, making sure everything is as flat and square as possible.

Then I ran a test, using a small section of the part I was cutting before, and the tool paths all lined up. I used the automatic tool height sensor, and there wasn’t any issue with that. So I guess it was all down to a wonky cnc router.

I haven’t spent any time on the simulation part of it. It seems to run best if I just walk away while it’s running.

1 Like