I work very closely with our company engineer, he works with Cimatron to prepare the files for CNC milling.
When I transfer file in IGES format there is no problem the files open with no problem in Cimatron, all the surfaces are good and joined. But when I receive files from him ,even if it is the same file I sent him (he only saves it again in Cimatron), the surfaces are many time broken ( their edges are not well defined and i need to rebuild them) and i am unable to join them ( the edges move and the surfaces are not touching each other).
We tried to use STEP format to transfer the files but that didnt work the files were even worst.
Does anyone have experience with this problem?
Is their a better way to transfer the files?
Hi Roi, for the joining problem this might be a tolerance issue. Check if the absolute tolerance in Cimatron is smaller compared to the one used in Rhino. I get various IGES files, eg. from ProE or Solidworks where joining results in many naked edges until i lower my tolerance in Rhino from 0.001mm to 0.01mm. Bad or missing trim curves are common too.
For the bad objects problem, it might help to tinker with IGES prefs (or flavours) in Cimatron, i´m not shure what kind of settings it has to offer. Alternatively, is there the possibility to try out VDA format ?
Quoting from step 5 in the Guidelines for Repairing IGES Files
â5 Check for bad surfaces.
The Check and SelBadObjects commands will determine if some of the
surfaces in the model have problems in their definitions. They may have stacked
control points, bad edge curves, or a variety of other problems.â
This article was apparently written back in The Rhino2 days. That was when Rhino had good error checking That functionality is no longer present.
I knew something was wrong recently but I couldnât put my finger on it. During the Beta phase of Rhino 5 I could swear that I could use selbadobjects and it would select the one in the example below⌠and now it doesnât. Notice the contours are not continuous across the middle of the object where there are stacked control points.
Why is the object above not classified as bad anymore?
It clearly does not work as you cannot perform standard Rhino Commands on it like sectioning.
plus I was impressed by the improvement of selbadobjects over Version 4⌠but now I am not. I was singing its praises to the other offices in my group as they would send me files to check for issues and v4 didnât identify them but v5 did. These were IGES files from Maxsurf
This is just my guess right now, but I think, in theory, Rhino was supposed to handle stacked control points better so these were not considered bad any more. It clearly does not handle them fully yet. We get surfaces with stacked points from hull building programs, where stacking points internally, so to speak, is commonly used to make chines, so we do want to handle them better⌠OK, I see youâre getting surfaces from MaxSurf.
Can you send me the surface that behaves badly in your example?
@GregArden, am I correct that intersecting surfaces with stacked points was supposed to âjust workâ in V5, or did I make that up?
Whilst Iâm glad you are making inroads to allowing Rhino to handle stacked CPs better, there are programs that donât.
We use openCascade in or in-house software for sectioning the IGES hull forms to calculate displacement. The maths goes awry if there are stacked CPs. Rhino was used to correct these models supplied to us from Third parties and selbadobjects was useful to identify at first glance which surfaces were using them and then applying the smooth command to separate them.
It might not be considered a âBad Objectâ now, but it is certainly bad practice. But as a consequence, if you extrude these three surfaces to solids then you try and Boolean Union them, it will fail. ~Unsurprisingly
Adds the command âSelStackedVertsâ, which should select all curves and Breps that contain stacked vertices. Could have scripted that but wanted to try the plugin approach. Might add a event watcher later, like CheckNewObjects, to execute the checks when objects are added to the documentâŚ
First of all, Stacked control points is not the only type of degenerate geometry that causes Rhino commands to fail. In the âDonât have a solid filletâ thread we had two examples in one small model.
Second, the problem is that often it is not the users fault. Frequently, bad geometry is created by bugs in Rhino. The reason Rhino development proceeds at such a glacial pace is in part because it can take years of users stumbling over bad geometry to find these bugs. That is because nobody can tell at what point the bad geometry was created⌠If Rhino had good error checking the bugs would be found and eliminated quickly.
The solid tools in particular could use a good dose of error checking. They tend to be lousy tools that breed degenerate geometry because they have never been deloused.
Surfaces with collapsed spans should get called out in some kind of check function. But they should also work for simple trim and split operations. For more complicated operations like booleans they may never work, which is why we need the check function.
