What is your product master?
Is it a paper drawing? A digital drawing? a 3D model?
No matter what it is today, it’s likely that, in the future, it’s going to be a 3D model.
According to NIST, there are some big advantages of using a 3D model as master:
- Faster design revisions
- Build and test components and assemblies in a virtual
- environment (do-overs are no problem)
- Infinite viewpoints and exploded views of assemblies
- Direct to rapid prototyping
- Direct to engineering analysis (stress, thermal,
- interference fit, tolerance stack-up, etc.)
- Reduced manufacturing lead time and cost
- Automated generation and update of drawings (when
- drawings are needed)
- Generation of technical manuals directly from model data
- Costing, materials acquisition, marketing, training…
One gotcha in going this route is that your 3D master may be used with different applications, which could make mistakes in interpreting it.
Let’s say you’re importing your 3D model from Pro/E into SolidWorks. Think there is any chance that the importer could introduce errors?
Or, maybe your CAD software goes through a generational change. Is it possible that your carefully constructed 3D models might be misinterpreted by the new generation software? It’s happened before. Like, with the change from CATIA V4 to V5.
Could such a thing happen again? How about when Dassault Systemes SolidWorks Corp introduces its new SolidWorks V6 generation products?
To be fair, I want to give the SolidWorks programmers all the credit possible for making sure that they’ve dealt with compatibility problems between the V1 generation of SolidWorks, and the V6 generation. But, even with all that credit, I have to fall back to this simple concept: Trust but Verify.
Next Thursday, Nov. 8, at 2:00 pm ET / 11:00 am PT , I’m hosting a free webinar with Capvidia, to talk about data verification in SolidWorks.
Capvidia is going to be talking about how their CompareWorks program can diagnose the geometry you import into SolidWorks and show where there are differences and/or give you the assurance it is correct. And how you can use it to establish a documented, traceable procedure in your company workflow.
If you’re a SolidWorks user, and you work with imported geometry, or you’re concerned about how to handle compatibility between your existing version of SolidWorks and the upcoming SolidWorks V6 generation, I think you’ll find this webinar to be really interesting.
Click here to register for the webinar.
Rachel Berry says
Don’t Kubotek do something similar? http://www.kubotekusa.com/
And if it is broken: Elysium http://www.elysiuminc.com/Products/caddoctor.asp or Solid Doctor frm Delcam: http://source.theengineer.co.uk/software-and-communications/manufacturing-software/cam/solid-doctor-enables-cad-model-repair/362043.article
Skimping on translators is a false economy in my opinion – yep you might get a translator that handles 20 fomats for £400but it probably won’t do any well and will leave you with junk!
John says
I’m a SolidWorks user since 2000. During that time I’ve seen many models change geometry during the upgrade process occasionally simple models but mostly complex ones. I don’t trust the upgrade process at all.
John says
I should add, not all these geometry changes produced errors in the model tree, however the geometry was different before and after the upgrade — This is train smash from a data management perspective.
Evan Yares says
When I was at the Spatial user conference a month or two ago, I remember hearing a statement that bad translators are a major cause of not just immediate problems, but also downstream problems. You might find yourself working on what seems to be a perfectly fine translated model, and discover that a blend fails unexpectedly, because the translator didn’t clean up the underlying geometry.
Rachel Berry says
It worse than that – the output of the translator can be perfectly valid and that’s where validation has weaknesses a) geometric point checking is often a big part and whilst the model might match the physical points the geometry can be different (a b-surf in the same place as a cylinder vs a true cyclinder) and b) it can be different plu c) validation isn’t free checking is intense expensive and generally fairly global.
Even if the translator is doing well the setting and understanding of the tolerances is often lacking or hard to determine automatically and it can just be different, so yes a blend down the line can change or fail just because everythings a tiny bit different.
Translation, repair and checking is costly and a lot of the cheaper translators can’t afford to be direct and reverse engineer so go through some intermediate so they can support more so rather than format A->B, A->C->B with more change of error.
It gets worse for the consumer if you buy all the bits from different people or they are rebadged proprietary formats. The translator supplier will argue it’s valid output and not their problem, the modelling will view the input as different and not a regression. At least buying the whole stack from one supplier will give you a single point of help and someone with a vested interest in resolving the issue as early in the process and where it should be.
A non-ideal translation has huge impacts on application performance and reliability. If you can’t trust the translator or resolving issues difficult with that supplier you have to check and then repair even if unnnecessary – slower. If your analytics (planes, cylinders) become tolerantised b-surfs your rendering, modelling becomes slower and under the surface you get a vast increase in numerical intersections being calculated, bigger parts etc. More work to do operations on slightly sub-optimal geometry. You can get artifacts (valid but PITA) slivers, smal edges, tolerant vertices all of which mess up facetting and meshing so CAE calculation more work and if hugely iteractive the overhead scales accordingly.
My pet hate is cheap translators and the lack of understanding of import. And with tolerant models multiple suppliers trying to shift the work can be a nightmare for a customer.