PC-DMIS Crashing at the Start of a Measurement

First thing to determine is if your routine's ID's are LETTERS_NUMBERS_UNDERSCORES_ONLY.   No commas, no periods, no parenthesis or hyphens. The demon sees all of these as active math functions and will mess routines up really bad.

Second thing is to find out if the code has groups.  If it does, make sure you have a starting group definition AND an ENDGROUP definition at the end of each.
--Groups tend to screw up routines the most in my experience.

After you have confirmed your grouping is correct, make sure you don't have redundant feature or alignment names.

If none of that works, and you've already affirmed that your machine isn't resource-strapped... i would "shell" the routine (IE: create a new blank routine, then copy/paste the code into the new blank routine, save as new filename, and test).

I checked the first suggestions, and everything is letters and underscores. 

We do not have any groups used in this program. We use loops and if statements to control the quantity entered, and for the location of the parts.

I was able to replicate the issue. This appeared to only happen when using the max 4 parts. When the program crashed, i did not see any spike or increase in the machine processing. I am going to shell the program and try testing.

I've got 16cavitiy routines which are looped and have run consistently (we are a 24/7 production facility as well) for over 7 years. 

The only other thing I can suggest, is to schedule a weekly PC restart using Windows Task Scheduler.  Google it, it's pretty easy to do, and you can set rules to make sure the system is idle before it reboots.  You might have temp, registry, or cache files that are getting too big (since you never shut down) and wigging out the software.

I've got 16cavitiy routines which are looped and have run consistently (we are a 24/7 production facility as well) for over 7 years. 

The only other thing I can suggest, is to schedule a weekly PC restart using Windows Task Scheduler.  Google it, it's pretty easy to do, and you can set rules to make sure the system is idle before it reboots.  You might have temp, registry, or cache files that are getting too big (since you never shut down) and wigging out the software.

I'll take a look into the task scheduler. During the training of the new operator, I do walk them through on how to properly shut the machine down and restart the computer for when they run into problems/issues.

I never checked the temp, registry, or cache files. Is there a special way to do this, or do i just need to look through file explorer for them?

I have no idea how you can quantify any "smoking gun" parameters that cause PCDMIS crashing. 
All I do know, is that I've implemented this weekly scheduled reboot.  Although it hasnt been long enough to really say it's THE solution to the issue...  I haven't heard from the techs of PCDMIS crashing out since.