Nominals in DIMENSIONS keep changing!

It has no affect on the PC-DMIS dialogs. It changes the behavior of the level command slightly so that when we do a level, it keeps the other two axes as close to what they were as possible. This was a change from prior versions of PC_DMIS so that in case there were problems, we could turn this new behavior off by setting the option to zero. Normally unless there is a problem with the alignments, this option should be one.

I did some testing today with 2012 RC. I tested this issue of 2D feature theoretical values changing after a Level alignment prior to the Rotate command.

It is certainly repeatable and doesn't matter if CAD is imported or not.

The UseTheosForCADToPartLevelAlignment setting seems to take care of this problem for the tests I ran today. It looked good.

<< Xxxxxx Yyyyy (Development Notes) -- 05/13/11 14:26:33>>
Code appears to be working correctly; the main issue is the user has used an alignment that hasn't had it's ROTATE set, so the theo values of the measured circles will drift some based on the measured values. However, internally, the CAD to PART transform really is not changing.

There are two reasonable ways to eliminate the drifting theo values:
- lock down the final rotation of the alignment before using it to measure the circles (the program will need to be run again in order to clean up the theos, but after that they will be stable)

- set the PC-DMIS setting UseTheosForCADToPartLevelAlignment to TRUE using the Settings editor. Refer to the help manual, Home > PC-DMIS Settings Editor > Option> UseTheosForCADToPartLevelAlignment. The program will need to be run again in order to clean up the theos, but after that they will be stable. (as a side note, I had to search on 'Alignment' or 'CAD' in order to find this setting in the help manual; 'Use' and 'Theos' didn't work...)
<<END>>

Use Theos for CAD to Part Level Alignment
Introduced in v2010 MR2, this entry only does something in those cases where a level alignment exists without a successive rotation constraint. In this case PC-DMIS needs to decide the rotation direction of the secondary axis about the primary axis (the level axis). It will affect feature theoretical values following this type of alignment.

Entry Name: UseTheosForCADToPartLevelAlignment

Entry Type: Boolean value. The default value is False. False is the legacy value. Part programs prior to the creation of this registry setting behaved as if this setting were set to False.

When set to False, the rotation about the primary axis is determined by the measured values of the input features and the change in rotation of the CAD to PART transform about the level axis is approximately the same as the change in MACHINE to PART.

When set to True, the rotation of the CAD to PART transform is not dependent on the measured values of its input features; instead, it is based on the current CAD to PART transform.

It has no affect on the PC-DMIS dialogs. It changes the behavior of the level command slightly so that when we do a level, it keeps the other two axes as close to what they were as possible. This was a change from prior versions of PC_DMIS so that in case there were problems, we could turn this new behavior off by setting the option to zero. Normally unless there is a problem with the alignments, this option should be one.

I did some testing today with 2012 RC. I tested this issue of 2D feature theoretical values changing after a Level alignment prior to the Rotate command.

It is certainly repeatable and doesn't matter if CAD is imported or not.

The UseTheosForCADToPartLevelAlignment setting seems to take care of this problem for the tests I ran today. It looked good.

<< Xxxxxx Yyyyy (Development Notes) -- 05/13/11 14:26:33>>
Code appears to be working correctly; the main issue is the user has used an alignment that hasn't had it's ROTATE set, so the theo values of the measured circles will drift some based on the measured values. However, internally, the CAD to PART transform really is not changing.

There are two reasonable ways to eliminate the drifting theo values:
- lock down the final rotation of the alignment before using it to measure the circles (the program will need to be run again in order to clean up the theos, but after that they will be stable)

- set the PC-DMIS setting UseTheosForCADToPartLevelAlignment to TRUE using the Settings editor. Refer to the help manual, Home > PC-DMIS Settings Editor > Option> UseTheosForCADToPartLevelAlignment. The program will need to be run again in order to clean up the theos, but after that they will be stable. (as a side note, I had to search on 'Alignment' or 'CAD' in order to find this setting in the help manual; 'Use' and 'Theos' didn't work...)
<<END>>

Use Theos for CAD to Part Level Alignment
Introduced in v2010 MR2, this entry only does something in those cases where a level alignment exists without a successive rotation constraint. In this case PC-DMIS needs to decide the rotation direction of the secondary axis about the primary axis (the level axis). It will affect feature theoretical values following this type of alignment.

Entry Name: UseTheosForCADToPartLevelAlignment

Entry Type: Boolean value. The default value is False. False is the legacy value. Part programs prior to the creation of this registry setting behaved as if this setting were set to False.

When set to False, the rotation about the primary axis is determined by the measured values of the input features and the change in rotation of the CAD to PART transform about the level axis is approximately the same as the change in MACHINE to PART.

When set to True, the rotation of the CAD to PART transform is not dependent on the measured values of its input features; instead, it is based on the current CAD to PART transform.