No, I've got a buddy with Solidworks. Solidworks opened the file just fine, and exported it as a Parasolid.
at 1st it didn't work importing the Parasolid, since it contained more than one shape. Seems that VX still has a bug in their parasolid import if a parasolid file has more than one solid object in it, it says it has none...

Firstly, very pleased that you have been able to work around the problem and can continue the work.

Concerning files from Catia, VX is usually very very good with them, especially the IGES exports, which tend to be untidy because the average Catia User does not know how to use the Catia IGES Export module properly (if you ever see it, you will understand why!). Now, VX should NEVER crash to the desktop, so we would like to have the original IGES file that brings about this failure so that we can improve VX.

The multi-body STEP/Parasolids problems have yet to be fixed in VX, but VX will import most files nevertheless, leaving you with some "house keeping" to do. Although it has been around a very long time now, the STEP standard for model geometry is still causing difficulties throughout the CAD-CAM industry - the documentation is simply huge!

We also offer two dedicated Catia translator modules, so if you are going to import a lot of Catia data you might like to check them out.

Could we just define what precisely are the issues with importing STEP and Parasolid files? Are you saying (and it would appear to match my experience) that any STEP or Parasolid file with more than one solid entity will not import properly? Like it or not STEP and Parasolid are very popular formats. Getting reliable import AND export from VX is critical.

I'm getting slightly concerned about VX's abilities to handle solids reliably. Too many simple stl exports are flagged up in Magics with bad triangles. This was a common issue with ThinkDesign as well. Personally I would prefer to see rock solid import export as being the focus for v11 - or even v10.xxx

Whilst end to end CADCAM is great not all of your customers have this capability. We need to work in an environment where we send files to toolmakers, prototype companies and customers that are in neutral formats or (preferably) native formats. I don't want to get into a slanging match about software A vs software B but ultimately, modelling tools mean nothing if you cannot get the data out reliably. Thats the reason (well one of the reasons) I stopped using ThinkDesign. STL output was rubbish, Parasolid was poor and STEP inconsistent.

Here's what I've found so far.
Parasolid imports. VX wont import a parasolid file if it contains more than one object/solid.
Step Imports. VX will import multiple object files fin. But wont place and orient them properly according to the step assembly.
Iges Imports. VX will import multiple object files, and place/orient them properly. But it wont make a "multi-object" file out of it.

I'd say VX does need some work on importing things. Delcam has the same problems with importing step & parasolid assemblies.

Parasolids import is relatively new in VX and currently we do not support multiple bodies. You should be aware that exchanging data as a Parasolids file can be the least desirable solution because Parasolids is very much a moving target. It is wrong to assume that because a program is based on the Parasolids kernel, it will import/export Parasolids files that other Parasolids programs can export/import - simply not so! Thus, if the Parasolids guys are having trouble with their "standard", you can understand that it is difficult for VX too.

Concerning STEP, there are issues with the import of multi-body assemblies, but mostly the data will be imported. The problems are partly due to the way the VX translator currently works, and partly due to the different ways the data is managed/exported by other CAD applications. However, having a 100% perfect STEP translator in VX will still not always give you a perfect result because so many applications currently produce STEP files that do not meet the defined standard. We have even published tools on our website to help the developers of rival CAD-CAM products, because we believe it is in the best interests of everybody's customers to get STEP sorted out. Not going to happen overnight.

STL is widely used for things other than it's original purpose and realizing this, VX has excellent functionality to produce top-quality STL files. If there are faults in an STL file, it is most likely due to User errors in the VX model........ VX offers a neat "fine tuning" option for the triangulation and I have not seen any app, including Materialise's Magics, that can produce better quality than VX. If you do find that VX has produced a bad STL file, then we need to see both the STL and the original VX file so that we can find out what went wrong.

IGES was not designed for multi-body assemblies and has no means of "telling" the importing application which geometry describes which body. However, VX does do a very good job of importing such files. We do offer a means of separating the bodies into individual Part Objects and then building a component-based assembly from these via two free VX DAL programs - BatchCreate and MultiComp.

So, in conclusion, data exchange is not a perfect part of the CAD-CAM world, but VX is certainly amongst the best available and by far the fastest too. I'm sorry but everyone will hit a problem from time to time, despite our best efforts. Note also that most file exchange problems are actually caused by the User who exports the data, either with a poorly defined model or by not outputting the optimum "geometry flavour" to suit his work. When you do have a problem, your Reseller will do everything possible to help, and if the file can be forwarded to VX Corp, the developers can study it and enhance our code accordingly.

Chris,
I understand there is no perfect translation in the Cad/Cam world. VX's exports work well with most apps, except for Pro/e. For some reason, Pro/E doesn't like VX's iges and step files. YMMV though

The only thing IMHO that needs immediate help in VX's import end of things are:

1.) Get Step import of assemblies working. I understand some apps do step assemblies differently. I mainly recieve assemblies from Solidworks and Pro/E. If VX's developers would like some of the assembly files I've had trouble with, just say the word.

2.) Get multi-object parasolids working.

3.) I also understand that Catia's iges export sucks big time. But it seems everytime I get a Catia iges file that I have problems with, I send it off to a buddy of mine who has SolidWorks, and it imports perfectly 99% of the time. He then exports it as a Parasolid file, and voila... I have a perfectly healed solid. If you'd also like an example or two of this, I can upload some of the Catia iges files in question. The file posted in this thread is a perfect example. I'm told it opened up perfectly in SolidWorks. He then exported it as a Parasolid file with both objects in it. Of course it failed to open in VX. Then I asked him to export it as two seperate entities. Worked like a charm, and came in to VX perfectly.

Yes, we would very much like to see your problem files so that we can further enhance VX importing.

Important point though is that your Catia IGES import problems are not the norm - VX usually imports Catia IGES very well, even when the geometry is poorly described in Catia. We have Aerospace customers that use VX to import both Catia EXP and IGES. In fact, Catia's translators (there are 3 modules available for CatV4!) are good, in the right hands. However, very very few people know how to export from Catia properly. I know this sounds stupid, but it is true, even the IBM Catia guys have struggled in the past (despite the fact that I was paying them huge sums of money to do our translations. In the end, I worked out how to do it properly through trial and error). UGS is not much better either, because the interface is more akin to what a developer understands than what an engineer might wish to see. I could go on, but it is not my intention to make excuses for weakness in VX, just to give a better perception of what the real CAD-CAM world can currently deliver.

We know that, overall, VX translation compares very favourably with all other products. We want to continuely improve because we appreciate how important the function is for most customers, and appreciate it when customers spend 10 minutes to report a problem and send us their file - without this feedback, the enhancement rate would be much slower. A customer once complained to me about a bug that had "been there since day one". Nobody else had come across the problem and so nothing had been done to correct the fault - what a shame he did not mention it sooner! Of course, much as we would like to, we cannot do everything immediately.

One of the gripes I have with many CAD software developers is that you can create geometry that is not going to be able to be used by anyone else because of "user errors".

For example, last year I designed a fairly complex clam shell type enclosure using Ashlar-Vellum Cobalt. I used standard tools "properly" yet the final geometry was riddled with errors. This created merry hell when trying to export to stl, IGES and Parasolid. Similarly I did a job in SolidWorks 2003 last year and once again at the VERY end of the design process I started getting errors. I can tell similar stories for Think Design, VX and others.

I know 3D CAD is complex but FROM A USERS PERSPECTIVE modelling errors should not occur. If an operation is successful the model should be error free. If the modelling operation does not generate error free data it should fail. I do not want to spend 5 hrs modelling and then 10 hrs repairing! Trust me, as someone who has spend 100's of hours fiddling with "tolerant edges" or "non manifold solids"!!

Hence my comment on focus for v11.

I would much rather see a robust reliable modelling environment that always works, that always allows error free exports and never lets you model data with errors in it. Having used many of the so called "conceptual design" apps (VX, Think, Ashlar) these are VERY prone to allowing modelling errors simply because they allow so much freedom in how to generate shapes.

On the subject of translators I would ask this, again from a users perspective. I want to be able to save a file in any format without having to delve into arcain "settings" that mean nothing to most of us. I want to be able to do this:

In my experience the most common error in exporting data is not setting it in the correct format for the receiving app. The classic is saving, say, an ACIS v12 file for an app that only reads up to ACIS v8. Problem is how many (average) users know the kernel version of their software?

The issue for companies like VX, Think3, Ashlar etc are that they are small players. The big players are Dassault (CATIA and SolidWorks), UG (UG/IDEAS and SolidEdge), Autodesk (Inventor) and PTC (Pro/E). We have to communicate with these apps. Now I know VX already does this very well, but, lets make it even easier! I hate having to ask others to try opening files that I have saved to see if they work!! Like Steve I have colleagues using SolidWorks and CATIA v5. They very rarely ask me to try files out.

Sorry to bleat on about this but it is critical, and I have seen (and used) too many potentially good apps fall by the way side because they make the task of getting data in and out too complex, or more importantly, too difficult for the receiver to use. Lets face it, if you are buying in services who would you rather use - someone who can supply data you can use natively or without errors or someone who's data is going to cause hours or days of rework?

Thats the issue we all face day to day and its an issue ALL 3D CAD developers forget in the race to create new "super features".

Your post has gone a bit off topic but what you have to say is real-world true (but I cannot accept your comparison of VX with Think3 and Ashlar, VX is completely superior).

What CAD systems deliver today is what we can do today given current programming technology and current knowledge. The utopian condition of anticipating whether a User really did want the particular shape he just defined is a tricky one - easy for the human to know the difference, but the system is currently delivering what you ask of it. I would say though that if you really do have so many models with so many errors, you should take a critical look at the way you manage and create your geometry.

You are right about pre-flavoured file exporting, we should have this (and a similar arrangement for importing). It would certainly make life easier. I have previously proposed this kind of thing, with User defined flavours as well e.g. Once you have found the best IGES flavour for CustomerABC, save those settings as "IGES to CustomerABC".

Now, don't worry about the VX Development Team, it does not have it's head in the clouds and VX Corp is certainly not detached from it's Customer Base - we are all ears, striving to deliver what the Customers need. Most new functionality that gets introduced is in response to enhancement requests. Of course, if we think we have a great idea that will be useful for all, we are going to try to put that together too - important because we need to differentiate VX from the rest of the crowd.

Maybe mine is well on the way out because of those other apps then? Accelerated hair loss due to poorly defined geometry :-)

Sorry Chris, didn't mean to ramble so much, but this is an issue very close to my heart. Taken across the board VX is well up there with the best (no names) - thats why I bought into it after all! I would have done so 10 years ago as well if it hadn't have been just Unix either! (I was kind of put off by spending

Yes, Macros and similar are used extensively in testing VX. A live library of data files from the Customer Base could be usefull, but of course we would need exact records of precisely which application version the file was exported from. Then of course, the waters are muddied further by the options or flavours that the app can output. In principle, it sounds easy, but in practice, there are hundreds if not thousands of variations to deal with.

Some years ago I produced an export test suite - a set of small, verifiable model files that could be exported in all formats and all format flavours to "funnel down" to the best file type for export to other systems. I'm in the process of producing a new suite, but have had to put it on hold as other priorities consumed the time available.