Skip to main content
C
cadcam1-Visitor
1-Visitor
May 10, 2018
Question

Problems with loosing features in a part - Creo 4.0 M020

  • May 10, 2018
  • 1 reply
  • 1464 views

We have just been running a training course with about 340 participant (typ80+ in four 'identical sessions'). The basis of the course has not changed much in the last couple of years, but this year we have been using Creo 4.0 M020. We have been seeing a strange failure in about 2-5% of the participants. They will be manipulating/using an assemble constructed of presaved components (A mixture orginally constructed on various versions of Pro/E-Wildefire-creo) when the assembly will suddenly fail. The failure is that one component suddenly looses all the features except the initial datum planes (possibly 1-2 additional datum axis). NB Normally occurs in Assembly mode, but has also been seen in mechanism

 

  In all cases clearing the memory and trying to reload the component either as a part of an assembly or as an seperate part does not recover the part. Inspecting the directory shows the original file either with no indication of size change or a new copy larger than the original. In the latter case deleting the later file normally allows the original file to be recoved. If no secondary file is written the only solution seems to be to delete/replace the original file with one from an archive. [If overwritten Windows indicates that they are files of the same size. [Unfortunately in the pressure of the sessions we have not yet done detailed work on diffs etc.]

 

     Has anyone seen any similar issues, before we spend significant time trying to obtain more pointers?

 

   Platforms - Intel I3/5 , Windows 7, various low end graphics cards. NB We have been running this configuration of machines with M020 since October 2017, and although we have had issues which I could raise elsewhere, this is the first time this problem has been seen.

   

    Many Thanks

1 reply

D
dschenken1-Visitor
1-Visitor
May 10, 2018

I would create a trail file that does the entire exercise and then have the students run that first. If it fails, then you can capture the trail file to see if there is a failure identified or if there is something in common among the failed machines.

 

Seems to me like there are presently too many variables, especially the dependence on low-end graphics cards.

 

You could also re-run the trail file with "graphics win32_gdi" to eliminate the graphics cards as a problem on the ones that failed the first time. On repeated classes you can see that it only happens to particular machines.

Terms & ConditionsCookie settingsAccessibility statement