Issues with large Programs

In general, It is hard to answer you questions unless you read through the drawings and understand what kinds of sequence it is on based on different datums or alignments. For example:

1. Start with datum ABC, then measure 1-150 features, 

2. Datum DEF, then measure 1510-300 features.

3. Datum GHI ...

Then you could separate the program into small piece....

My thought  

The part only has 3 Datums despite the numerous callouts.

Am I understanding you correctly though where if all the dimensions come from one surface I would have to measure that surface in each subroutine? So if i break the program into 3 subroutines, I need to measure it 3 times?

Is your program stored in Network or on the PC? If the program is on the network, it might crash sometimes.

No I have this guy on the computer.

You can make sure to update your system and graphics; this might also cause crashes.

Restarting the PC every 8 hrs or per shift also helps.

I reboot the PC every morning. Ill have IT check the computer for updates and driver updates. Is there anyway to put in a save command into a program So it saves while its running? Maybe put in a delay with a comment and have it save during the delay?

There's an example routine and script available from the discover tab on the home page...

does the program have a HUGE cad file?  Do you NEED the cad file to make pretty pictures?

IF SO, then open the folder where the program is, make a COPY of the cad file (it will show up as COPY OF xxxx.cad.  Then delete the original cad file.  Them, in the program IMPORT a CAD file but use CAD BY REFERENCE.  This will make a cad file of 1k bytes in size and reduce the resources needed when the program is open

I'd have to agree that several smaller programs would work better than using subroutines to make it all work in one program.  During execution, when a subroutine is called, the Edit window will just highlight the line calling the subroutine.  You can not see the code of the subroutine and if there are any errors you can not see where the problems are.  You also can't just go back and re-run a single feature in the subroutine or execute from the cursor somewhere in the middle.  

A 2 hour run time with 700 dimensions is a pretty big measuring routine, but I often work with much larger measuring routines.  The software is capable of doing it.  I suggest you look closer into what is causing the slowness and the crashes.  You might benefit from a hardware upgrade.  It is also possible that you are using a software feature that is really resource intensive.  I find that sticking to legacy reporting helps a lot.  Also, avoiding any measuring strategies that have multiple imbedded features - like the Adaptive Cylinder Concentric Circle Scan.  When using that measuring strategy it will create the main cylinder feature and several imbedded circle features.  Too many features like that make my system agonizingly slow.  Unfortunately, it can be hard to tell sometimes what is causing slowness and crashes. 

I didn't know those auto features  had more info than other ones. I did end up removing nearly all the scanning I was doing. It seems to run better now, but the cycle time is much longer.