CAD/CAM discussion forum > Other CAD/CAM Technology > Tips in creating a robust model?

Tips in creating a robust model?

Rank: 1

OldForumPost

Newbie

posts: 0

Registered: 2012-1-14

Message 1 of 14

 Tips in creating a robust model?
06-10-2005 12:45 . am | View his/her posts only
Lately I have been having trouble with my models crashing during seemingly random executions. The longer the model histories get, the more often VX crashes.

My current models have about 140 to 160 history operations so far. I'm a beginner at VX so I know that I have a lot of unnecessary and blanked steps in my model histories.

What tips or workarounds have you found to help in creating robust models?

My tip: I found that when modifying connection points and lines in lofts, drive curve lofts, bi-rail lofts and most likely any other place connection points and lines are found, USE WIREFRAME VIEWING MODE. When in shaded mode it seems to crash a lot more often.

Disclaimer: I'm not sure if it is a hardware problem, video card driver problem, VX program problem, or my model history problem.

Rank: 1

Kevin

Newbie

posts: 0

Registered: 2004-4-26

Message 2 of 14

06-10-2005 05:21 . am | View his/her posts only
Quote

Originally posted by: clintonyee


When in shaded mode it seems to crash a lot more often.


To me this would imply some kind of issue with the VX/graphics card combo. What are you using?

Rank: 1

ChrisWard2k2

Newbie

posts: 2

Registered: 2011-11-22

Message 3 of 14

06-10-2005 11:43 . am | View his/her posts only
Hi Clinton

We would be interested to receive a sample file if the crash is always reproducible (which would indicate a VX problem). If you are having random crashes that are not specific to one VX file, then you have probably got a hardware memory fault. Although you mention problems with the model shaded, if it is a hardware fault, it is most likely your RAM rather than Graphics RAM. However, if the crash takes you all the way to the dreaded blue screen, then that could be caused by the graphic card's driver or, unfortunately, it's RAM (which cannot be replaced on most cards). Make sure that your system is not over-heating (the most common cause of problems) and defrag the hard drives. Testing RAM for errors is difficult because you need to run a "soak test" for a very long time (hours). However, you could leave a memory test program to run over night. Let us know how you get on.

Rank: 1

OldForumPost

Newbie

posts: 0

Registered: 2012-1-14

Message 4 of 14

06-10-2005 12:54 . pm | View his/her posts only
I have a Nvidia Quadro 1400...the "low end" of their CAD cards. It's hard for me to call my $500 video card low end

Problems occur whether I am in "Software openGL driver" or not in the configuration menu.

When I am using Geomagic Studio with HUGE files using nearly ALL my 2 GB memory. Geomagic Studio is rock solid, I can't remember a single instance when it has crashed.

When using VX, I never get the Blue Screen of Death (BSOD ). VX merely disappears...poof !

I would have issued a PCR but I have not been able to pin down a reproducable set of crash circumstances. BUT is does seem to happen very offten when I hit "rebuild" or use the replay buttons.

I do have an AMD64 with AMD's Cool'n'Quiet power management enabled, it throttles the CPU speed and voltage according to demand. Perhaps that is why when VX crashes, it is always doing something that is CPU intensive. I'll turn this Cool'n'Quiet thing off and see it it helps. Update: Nope it didn't help turning it off.

I'm going to run a couple RAM memory stress tests overnight to see if it comes up with RAM errors.



Rank: 1

ChrisWard2k2

Newbie

posts: 2

Registered: 2011-11-22

Message 5 of 14

06-10-2005 05:50 . pm | View his/her posts only
Hi Clinton

Really hard to pin the fault down. Holding large amounts of data in RAM is only part of the story, especially when you are talking points data because the software needs to tolerate "bad" data lines anyway - so whether the bad data was stored in the file by the digitiser/laser, or lines of data became bad by being corrupted in memory, both Geomagic and VX have a good chance of surviving . The real test is memory in - memory out activity, when a program is calculating for example. When the RAM required goes over the size of the physical RAM available, the pagefile on the hard drive come into play. The drive and the pagefile need to have minimal fragmentation for good performance as Windows tries to juggle between RAM and Virtual RAM (the pagefile). If things go wrong at that stage, Windows itself often "locks up".

Now, you are hitting the problem in VX when the RAM is nowhere near being maxed out? Let's see if the memory test gives any clues.

Rank: 1

OldForumPost

Newbie

posts: 0

Registered: 2012-1-14

Message 6 of 14

06-10-2005 07:11 . pm | View his/her posts only
VX is nowhere near my RAM memory max.

I will run Super Pi and Prime95 as memory tests tonight. They have helped me locate bad RAM in previous PCs.

Have you ever heard of sloppily made history models causing VX to crash during seemingly random operations such as "regen", "redefining", or modifying connection lines?

I can understand that those types of operations may cause a model to fail to regen completely but for VX just to disapear is a whole different thing. I'll install VX 11.4 on another computer and see if my model causes VX to die in the same manner. I'll also fully constrain my sketches.

Rank: 1

OldForumPost

Newbie

posts: 0

Registered: 2012-1-14

Message 7 of 14

07-10-2005 10:25 . am | View his/her posts only
I ran Prime95 and SuperPi last night as RAM stress tests. All results were normal.

I expected this result because I installed VX on my coworker's PC and it exhibited the same crashing problem as my PC. His PC is a couple years old, very basic, AMD 1800, built-in video card.

Rank: 1

ChrisWard2k2

Newbie

posts: 2

Registered: 2011-11-22

Message 8 of 14

07-10-2005 12:10 . pm | View his/her posts only
Hi Clinton

Well, that is good, at least you have eliminated the RAM as the possible cause. I trust that you have defragged the hard drives and pagefile.

I wanted to test your VX file on my PC but I could not find the PCR - what is the number of the PCR that you raised?

It is possible that a VX command is causing a crash when it receives some form of unexpected data. We test thoroughly for this kind of thing but of course the scenarios are infinite. However, if it was a fault of this kind, the crash would be reproducible, always happening at the same point in history.


addendum 1 - my mistake, you have not raised a PCR. Since you have a file that crashes two PCs, that is a good example file to upload to the PCR system.

addendum 2 - the programs you have run tests with are not dedicated to RAM testing. Use MemTest:
MemTest86

Disclaimer: VX Corporation is not associated with the makers of MemTest86. Using MemTest86 is entirely your own risk.

Rank: 1

OldForumPost

Newbie

posts: 0

Registered: 2012-1-14

Message 9 of 14

07-10-2005 12:46 . pm | View his/her posts only
I never submitted a PCR because I have no idea how to classify or describe the problem.

Do you think I should submit a PCR with the limited info that I have?

Rank: 1

ChrisWard2k2

Newbie

posts: 2

Registered: 2011-11-22

Message 10 of 14

07-10-2005 12:58 . pm | View his/her posts only
Hi Clinton

Yes, we would like to see the file that has crashed two PCs.

Rank: 1

OldForumPost

Newbie

posts: 0

Registered: 2012-1-14

Message 11 of 14

07-10-2005 02:51 . pm | View his/her posts only
I put up the PCR 17715 and will run memtest.Thanks.

Rank: 1

ChrisWard2k2

Newbie

posts: 2

Registered: 2011-11-22

Message 12 of 14

07-10-2005 04:58 . pm | View his/her posts only
Hi again Clinton

We would not normally progress this problem on the forum, but I think other customers may find the case of to be of some interest and hopefully helpfull - hindsight is a wonderful thing.

I'm currently unable to get VX to crash on your largest file, but I cannot do a complete regen of the Part Object "scoop" anyway (fails on fillet 15). It is difficult for me to track the history of the geometry but there are some obvious problem causers (this does not excuse VX for crashing, which is always unacceptable) :

1) You have used the minus sign in your Filenames and Object names. It is unwise to use any metacharacters because they could cause calculations to fail (e.g. the system parses an expression and thinks that the minus sign in the name really is a minus sign, and thus tries to subtract). VX is in fact very robust and tolerant, but my advice has always been to play safe.

2) Right at the top of the history of your "main" Part Object, you have an import - this should never be done, because every time that object is regenerated, VX will have to find, import (and on-the-fly heal) the external data file. There is no guarantee that the geometry built will be allocated the same database entity ids, and thus subsequent history can fail (This may very well be leading to the crash, since the scoop references). Best practise is to import the geom into it's own Part Object - do not do any work on it, just keep the Object as-is. You then have a reliable, verbatim reference model. To avoid a re-import (or lost import should the external file get moved or deleted), Encapsulate the history. Now, back in your "main" Part Object, you can insert the Import Part Object as a component, and merge. If the imported geom is of poor quality and requires a lot of repair work, I would recommend that you do this in a further part object - keep repair work seperate from design work. So, to recap, you would then have an Import Object, a Repair Object and a Design Object. This "good housekeeping" leads to cleaner, more easily understood histories that are shorter and regen more quickly.

Rank: 1

OldForumPost

Newbie

posts: 0

Registered: 2012-1-14

Message 13 of 14

07-10-2005 07:35 . pm | View his/her posts only
Chris,
I think I understand how to use your suggestions in 2. on the correct way of importing objects.

For this example: I use an imported stl file to build my models around. In this instance, the stl is an engine bay and I want to design my parts so they do not colide with that stl engine bay.

According to your importing advice, let me see if I got this straight:

Step a. Import my stl file into a vx part file. Then "encapsulate history". Save it, this you called the "Import Object"

Step b. Make a new object that you refered to as "Repair Object". Import the "Import Object". Then "Encapsulate history". Make the necessary repairs to the stl file. Save.

Step c. Make a new object that you refered to as "Design Object". Import the "Repair Object". Then "Encapsulate history". Design my part using the "Repair Object" as my references.

Do you recommend that all three of these objects be stored within one .vx file?

If the answer is "yes" would the following be good?:

Step a. Import my stl file into a vx part file. Then "encapsulate history". Save it, this you called the "Import Object"

Step b. From the "VX Objects" window, copy and paste "Import Object". Rename the newly pasted file to "Repair Object". Open it. Make the necessary repairs to the stl file. Then "encapsulate history". Save.

Step c. From the "VX Objects" window, copy and paste "Repair Object". Rename the newly pasted file to "Design Object". Design my part.

Thanks!
Clinton

Rank: 1

ChrisWard2k2

Newbie

posts: 2

Registered: 2011-11-22

Message 14 of 14

07-10-2005 08:51 . pm | View his/her posts only
Hi Clinton

I had already responded to your email before I saw your latest forum post.

Firstly, unless unavoidable, STL is not a good choice for this kind of work, but it does sound as though you have no choice. You probably do not need to repair the STL data? If not, there is no need to create a Repair Part Object. However, using copy-paste in the Root Object Window is not suitable for what we want - Each time, create a new Part Object, right-mouse click in model space and Insert Component, then right-mouse click on top of the model and Merge. For the benifit of other customers:

How to Import safely:

1) Create a new Part Object for the Import;
2) Import the external file (IGES, STEP etc);
3) Encapsulate the History (Edit/History Operation/Encapsulate);

4) Create another new Part Object for Import Repair (only if the import needs repair);
5) Right-click in model space and select "Insert Component", select the Import Part Object that you have just created;
6) Right-click on top of the component just inserted and choose "merge".

You now have dumb geometry that can be safely repaired.

Once the repairs are finished:

7) Create a 3rd Part Object for your design work.
8) Right-click in model space and select "Insert Component", select
the Repair Part Object that you have just created;
9) Right-click on top of the component just inserted and
choose "merge".

You now have geometry that you can modify/add to.

I prefer to have all of my data in one VX file. VX is designed to do this and it makes design life easier. However, individual files (one object per file) are fine if that is your preference or a requirement of your data management system. Save file frequently throughout the day and make sure your backup is actually backing up properly.
See also