Hi I have used Rhino for a few years now starting with Rhino 5 and now have Rhino 7 which is up to date
I have also been using Rhino Cam for almost as long. Rhino I use daily Rhino cam Its been about 2 years and not since I updated to Rhino 7. I have a new project going and trying to generate the tool paths and get this message from Rhino Cam “All curves must be closed or end-point matched” Which I cant find in Rhino or Rhino Cam help or I may get no message but a tool path that is not even close.
I made a quick, clean, simple test piece to see if anything changed and got the same result
I reached out to Rhino Cam and they recommended that I update to Rhino Cam 2023 from Rhino Cam 2022 and did so. This morning after the install I got the same result along with a new error message
I have reached out to Rhino Cam about this new but I was hoping that someone here has some helpful ideas. And can explain were to look for the errors that are being displayed
As far as tool path operation its any. I have copied and pasted both into older projects have multiple machining operations that worked in the past incase I had tool settings or some other parameter off and got the same error messages.
If I were to run toolpaths on this, I’d create at least two or more containment geometries – just from looking at that geometry at first glance.
You also might need some contour geometry in specific cases depending on toolpath strategy etc.
I’ve found that the more you break up the data to get CAM systems to focus and concern with specific areas at a time, the better control you’ll have over tool-marks and surface finish.
Otherwise the more you expect a CAM system to do things automatically, the more errors will probably pop up – not only in the software but even in tool-marks or gouges.
Here’s how I’d setup pretty much any file for 2.5D/3D CAM:
By the time I would be done running toolpaths on that part I’d probably have ran about a dozen separate operations – aside from initial stock prep.
If I was doing this in 5-axis using dovetail fixture etc., I’d probably have more containment geometry and like 6 or more different tool-axis-control lines, etc.
Everything’s relative though. Some users might just use sand paper and buffing wheels to fix things.
But software bugs aren’t fun. To avoid those as much as possible you have to spoon-feed CAM systems the most perfect geometry and thorough and concise information as possible.
Nothing is automatic. AI doesn’t really exist – yet.
You have over 700 “drive regions” selected as your control geometry. Like the entire model… Also I really don’t know how to use 2 1/2 axis roughing as an operation in this case, I used 3 axis horizontal roughing instead.
I duplicated the top edge of the pocket to use as control (limit) geometry, and halved the depth increment just to show a multi-depth pass approach. Note of course that the 1/2" ball mill you used as a tool does not go into the tighter spots, the file is just to show you that it does work in RC 2023.
Guess I completely overlooked this part until just now, but still all I see in that file is one polysurface and a few other surfaces.
It seemed as though the error you’re having was associated with a curve being used for toolpath generation that wasn’t a closed curve?
In which case, most toolpaths do benefit and/or require a ‘containment’ geometry. Hence, the questions or ‘what toolpath strategy?’ and 'where’s the …
…?’
This can be interpreted many different ways. Are you saying you copied the erroneous data into other files that worked fine, but the erroneous data cause errors in those files too?
Maybe I’m not seeing the mecsoft plugin data or something…
Weird, I thought the layers or Rhino curves would at least show up. Oh well, I don’t have that plug in on this computer. So, hope you figure it out If you guys need me to test it with mastercam lemme know
Yeah, use the wrong toolpath and you won’t get the results you hoped for. That’s typical for all CAM products. It’s not “lots of bugs and deficiencies”. It’s about knowing how to use the product, any product. I can make WorkNC or PowerMill fall on it’s face if I try to use the wrong toolpath. Is that “lots of bugs and deficiencies” in those programs too?
I count over 60 toolpaths. I get that you don’t like MecSoft products, but why misrepresent the facts? By comparison, WorkNC has around 70. Not that much of a difference.
The error I get is consistent if I select 3D roughing or 2-1/2D or 3D finishing . Also on the test piece the error is consistent if I select only one feature such as one of the dimples to rough machine or finish. Older projects created in Rhino6 with existing roughing and finishing tool paths still work when opened. But I can remove the old tool paths, redo the tool paths and get these errors.
I’d still like to know what. “ All curves must be closed or end-point matched“. Is and what it takes to find and fix. The test piece is really simple I don’t see how there can be anything wrong with it. My past use of RhinoCam with projects created in Rhino 6 has pretty easy to create all kinds of fixtures and molds using step models that were supplied by Automotive manufactures for foam parts used for N.V.H control. The only tool path that I can create with no errors is an outside profile now
Mecsoft technology, especially the RhinoCAM plugin in fact has lots of bugs and deficiencies, but more so on the deficiency side than bugs side even though it’s a fact there’s plenty of bugs. I’ve been familiar with Mecsoft for 19 years. I know a thing or two about it.
I wont get into the philosophy of “wrong toolpath” here just yet, because even most CAM systems use the wrong nomenclature on many things, and it’s not about right or wrong. It’s more about what can you get each “toolpath” to do, and what does it take to do it, and is it close enough to what you need it to do on a particular case at a particular time, in the overall sequence necessary to make the job work.
Most other CAM’s have bugs and deficiencies too, it’s not just Mecsoft. Especially, because ModuleWorks and MachineWorks dominates the industries. Mecsoft is just a very watered-down version of that technology, hence the deficiencies of Mecsoft.
Yes, it’s about what you can get any of these CAM’s using ModuleWorks and MachineWorks technolgoy, to do. Or what you can get these “toolpaths” to do and what each requires to accomplish productive strategy in any case.
I consider those two permutations of ModuleWorks and MachineWorks to be much higher end in comparison to the Mecsoft permutation. But yes you can get any to fall on their face regardless of “toolpath” as well. Especially if you’re not familiar with the bugs/deficiencies and the hurdles of how to get over them, etc.
Yes.
lol, k show me a picture of all 60 you speak of.
I don’t think you do. Facts are facts.
Regardless of what WorkNC’s “toolpath” count is, you’re comparing a much much higher end CAM system to a one that is basically lowest on the totem pole.
Before Vero ever acquired WorkNC, WorkNC was basically one of the top 3 best choices that existed at the time, while Mecsoft is at the bottom. This was way before Hexagon acquired Vero, of course.
So, I imagine WorkNC is probably way way way more advanced than Mecsoft at this point.
Even though they’re all just different permutations of ModuleWorks and MachineWorks, of course.
Hence, bugs n’ deficiencies.
The last time I evaluated Mecsoft was several months ago, and at the time it was probably the 27th time I’ve evaluated what they had to offer in the last 19 years. I noticed they just barely started rolling out the 5-axis they’ve been promising about 10 years behind schedule.
And their permutation of 'TrueMill/Volumill" “dynamic” strategies has bugs with their entries and exits algorithm. Aside from others, this was a no go for my standpoint.
At the time I did capture images of every “toolpath”, I could try dredging them up for you if you’d like. Somehow I have the confidence to guarantee you there is not 60. There’s probably something closer to 12 or 24 – but I’ve been wrong before.
Bottomline, is Mecsoft’s price point is way steeper than it used to be. They want what like 15% annually now? Ridiculous.
Here’s a quick example of RhinoCAM’s “3 axis superduper advanced” toolpath strategies they had to offer within the last several months:
Ummmm. Guys…. RhinoCam works in the Rhino environment. Was problem free for me at one time and is relatively cheap compared to every other 3D software that has any use, and it suits my needs and is fine for what I do. If I needed more horsepower I’d go with mastercam which is also used where I work, but then I’d need to learn something new. It will be way easier just to figure out what those error codes are and make do with what I got
Maybe true but they want more than 10% for maintenance fees now, so might as well go with mastercam. but point is is mastercam has bugs and deficiencies too, cause mastercam is just another permutation of moduleworks/machineworks.
I use mastercam2022 daily. I see no reason to upgrade it for the next 10 years. mastercam2022 is 10years behind where they should have been in 2009.
I figure they need another 10 years to make an actual nother step forward again.
Maybe Sandvik will make it better though.
But mastercam2022 is finally getting somewhere. Despite the bugs n’ deficiencies.
Maybe someday mastercam will have actual ‘perspective’ projection. Who knows.
I don’t know how you used RhinoCAM before, but as I said, “bottom machining” file had literally all of the edges of all the parts selected as regions (over 700 curves) and the other file “Test” had 23 edges selected:
Control geometry for limiting toolpaths has to be closed paths. I simply duplicated the top face border in Rhino (DupFaceBorder) and then deleted the outer rectangle which left me with the freeform pocket edge plus the four other circular pocket edges as a single closed curves to use as control geometry - to limit the roughing path to just in the pockets instead of going around the entire outside of the object.
Thanks, I’m not sure what the last save was that was uploaded here. It could have been that I grabbed everything and tried to create the path, after error after error. I’ll try what you suggested thanks
Note that it’s not actually necessary to extract discrete curves for machining containment - you can pick and chain surface edges together to form closed loops as well. You can use Rhino’s SelChain for this while picking, it works pretty well. But I’m old-school, I prefer to have actual curve geometry for my regions, I most often put it on separate layers to turn on and off when needed.
Well if you are getting the error message “All curves must be closed…”, then RhinoCAM isn’t finding a closed loop to limit the toolpath. If you feel you are getting this message in error, then post a file with a simple example.
If you guys need me to test it with mastercam lemme know 
