i would like the opinion of some Catia V5 surfacing guru. I just had a conversation with a master of class A surfacing on Catia V5 and his assessment was that Rhino to Catia in STP ( forget IGES it s crap we all know that ) the rhino surfaces are not that great. Work needs to be redone in some instances.
From my experience I didn t find it horrible. I was pretty satisfied ( maybe I m not as perfectionist as others or I m completely missing something) But are there any Catia V5 surfacing guru who sees that working with Rhino surfaces is not ideal ? and why exactly ?
Yeah i Guess you guys are right. I also had in the past had to clean up catia surfaces before sending it to a cnc. Too many gaps. I guess i m a bit paranoid. But one thing i noticed is that exported rhino surfaces are broken in multiple surfaces in Catia, whereas Alias surfaces come out really nice in Catia. Yet they re all Nurbs surfaces.
Agreed, i d like to look at the surfaces. I m surprised to hear that some experts in Catia say they need to rework rhino surfaces but are happy with Alias surfaces. They say rhino surfaces are broken down into much smaller ones in Catia.
We used Icem previously moving away from it due to the yearly maintenance costs, instead we purchased the Rhino plugins called VSR before they were purchased by Autodesk. We are also users of Catia, Unigraphics, Ideas and Creo.
The good point on Rhino is the direct and easy modification of a NURBS surface like in Blender and the easy transformation of a curve or surface from one degree to an other.
The good point on Catia was/is the easy analyse of the curveture by a section through the surface. But in those time Catia had problem generate or keep a closed a highlevel non-uniform surface pipe with a kink or without a kink. Every time it broke up the pipe by an Iso-line.
To add even more confusion I found that if I used code to generate my CATIA surfaces they sometimes seemed to be of higher quality with fewer IGES export issues that the same surface made the traditional way.
I remember wHen i imported Catia V 4 to rhino v3 and then rhino v4 it was a nightmare. I would import surfaces broken down into tiny tiny ones and hundreds to clean up as well. Catia v5 improved because it was working on windows platform wHereas catia V4 was Unix based. Airbus had huge problems with the a380 design because the french were using v5 and germans were on v4. I wonder how Alias does it. Never heard people complain when importing in CatiaV 5.
We run loads of different CAD packages with our Windchill System but are having problems with just one of them - CATIA. Since our recent upgrade to WC 12.0.2 and WGM version 12.1.2.0 our CATIA (particularly V5-6R2017) users working on large assemblies are suffering continual freezing/lockups of the WGM and CATIA. Which stops them working until it unfreezes - ranging from 3 to 30 minutes with no warning. The WGM and CATIA usually come back (not always) but this intermittent, can affect just small bracket parts as well as large assys. The CAD users say the behaviour has changed since WGM 12.1 as now CATIA freezes when the WGM freezes - whereas they could continue to work in CATIA at WC11.0 whilst the WGM was doing a background refresh.
We are not sure what the WGM &CATIA is doing to cause the freezing - it occurs on the regular half hour Workspace Refresh (sometimes these will complete in a second with no issue, then next time it will freeze for 5 minutes with the same models open). We also see long freezes in CATIA and WGM on Check-In / Check-Out and Opening.
Our Windchill App & SQL Servers are fine and so are the network links - indeed Creo/NX users report no performance issues, it only affects CATIA users. We have tried tweaking the various WGM preferences for refresh, item rename etc. but to no avail). We use a new Workspaces at least once per day,
We suspect that this gets more frequent the more members in the team are Checking-In / Modifying data as we approach design Gateways that have to be met. We also wonder whether this has to do with inter-part linking - as we suspect that the WGM struggles with this (any best practices to recommend here?). We also wonder whether it could be to do with updating multiple child parts and their siblings across the design team without updating the assembly that contains them (any best practice to share here)?
I have a call with PTC Tech support and have uploaded logs capturing the issues, but they have not been very forthcoming yet - so I thought I might raise this with the experts in the Community. Also, PTC are not likely to be experts at using CATIA with Windchill - us end-users may know more.
Unfortunately, we have to work in our customer's CAD package and version (Ricardo is an Engineering Consultancy), so upgrading CATIA version is not a solution for us (I think it unlikely that this is a CATIA version specific issue FWIW).
We originally had the issue at 12.1.1.0 WGM, and have had to upgrade affected users to 12.1.2.0 WGM (so we were on a supported config) in case that fixed the issue (it didn't) and so that I could log a call with PTC about the issue.
Am a bit stuck really because the WGM is not very informative about what it is doing most times with CATIA - it just locks up and looks like it has crashed, but usually comes back in time (trouble is you don't know if it will, nor how long to give it before you crash it out). What is more frustrating for the users is the CATIA hang since WC12 - they tell me that at WC11, they could continue working in CATIA whilst the WGM was doing a workspace refresh, now they can't and they are at stop waiting for it to come back.
Windchill 12.0.0.0 is also not a long term version but i still think the compatibility of R2016 and R2017 is strange. If i were you, i would install at least R2019 or latest R2022 on a test computer and check.
Unfortunately, the design team is at full stretch trying to hit an urgent Gateway - so they don't have the capacity to take someone off of the team to save the Assembly as a different version of CATIA into our TEST Windchill system and then work with it to see if this fixes the issue. Especially as (even if it did fix the issue) we could not supply the customer with models in this newer version - the project has to be carried out in CATIA 2017 version.
TBH, I don't think this is the same behaviour that my users are seeing - it seems to be related to WebGL (which is not involved in the WGM/CATIA), and my user's WGM's do (usually) come back from their freeze ups (eventually).
Unfortunately, we cannot install/run any versions of WGM older than 12.1.1.0 - due to the three high severity Chromium embedded browser security issues which were fixed in that release, and which are present in all previous releases.
WebGL is the 3D Graphics rendering engine in Chromium (and other browsers) that provides the interactive 3D Creo View model in the Structure Tab in the Windchill web page (per the article you linked to). WebGL is not used to render the the default /working view of the WGM to display workspace contents - so its unlikely to be related.
FWIW, I have just now had a response from PTC about the issue since R&D have had chance to review the logs I uploaded showing the issue - I have not digested it fully, but they seem to be saying that it is to do with the WGM needing to sync the user's workspace multiple times (hidden in the background) whilst a user is checking-in/out data... because other users on the design team are constantly checking in other related data in Common Space and the WGM needs to try and resolve all these links (with a sync) whilst doing the user's check-in/out... and sometimes it has to do this 2 or 3 times as people are constantly checking data into Common Space all the time.
So, it sounds like it might be expected behaviour - I have a ton of questions to ask them to get clarification/confirmation, not least why it seems much worse since Windchill 12 and why it is much worse in the afternoon than the morning..
I am concerned that the description of the SPR does not cover the totality of the freezing issues that my users are experiencing - so I am pressing them further to confirm whether the discovered issue also explains the CAD Sessions freezing (for between 3 & 30 mins) every time the WGM background refresh occurs (every 30mins by default). It is the CAD sessions freezing whilst they are trying to work (and not even using the WGM) that is the main concern for us - as it interrupts CAD working for no apparent reason (they should be able to work asynchronously in CAD whilst the WGM does what it needs to do in the background).
We have a large design team collaboratively working on a complex vehicle design across multiple sites, with a large Windchill BOM, change control and an electronic drawing check and release process - working outside of Windchill is not possible or desirable.
For short term solution, we identified there is inefficiency in propagating metadata synchronization around CATIA family table instances, that causes performance impact, we addressed it in Windchill Workgroup Manager 13.0.0.0. The SPR info (14400013) doesn't carry the right information because the bug was converted to product backlog.
For long term solution, we are discussing a change in the background synchronization - not automatically applying Commonspace Changes to CAD session, but notify pending updates, then users can synchronize them at idle time. The pending updates will be synchronized when save happens from CAD session. This change will be applied to both Creo Parametric and 3rd party WGMs. Implementation is being delayed due to other priorities.
I am glad that you are looking at a longer term solution as it's still a pretty major issue for us and we still see it at WGM 13.0.0.1 version (albeit marginally improved with the metadata sync changes that you had addressed in 13.0.0.0 as a result of my support ticket).
Your solution sounds like a sensible compromise - I appreciate the sync's need to happen at some point, so at least the CAD designer can chose when to force the pending changes to sync when they go for a coffee/lunch/end of day etc. rather than it just locking their CAD and WGM sessions whilst they are busy needing to work.
7fc3f7cf58