Cabinet Vision: The Last Mile/User-Controlled Standards Techniques

Introducing ULUCVUCS

Hexagon doesn't provide a name for the language used to write UCSs. Names are useful shorthand, and so, this document will call the UCS language "ULUCVUCS", which is an acronym for "The Unnamed Language Used by Cabinet Vision for User-Created Standards".

Techniques and Conventions for Variables (custom Parameters)

System Parameters versus Custom Parameters

System Parameters are those data members of the Object Tree provided by Cabinet Vision. Most of them are listed in the User Created Standards | System Parameters or User Created Standards | Material Parameters pages of the Help File. Custom Parameters are Parameters with names the user invents and types the user specifies. Custom Parameters never change the state of the model until their value—or an expression calculated from one or more of their values—is assigned to a System Parameter. In this sense, they are almost always akin to "temporary" variables. The main exceptions would be when they are used in "delayed evaluation" or to transmit their values into the Report Center through the Part.Parameters field.

Data Types

The best practice is to always declare a custom Parameter's data type when you create it or assign to it unless you intend for it to be a floating-point <meas> value (which is the default type when no type is specified). Prior to CV 12, CV was more forgiving about custom Parameters with undeclared data types than in later versions. So, for example, when looping through indexed Parameter names (e.g. FS@{fs_index}.DY) CV used to allow the indexer (in this case "fs_index") to be created and assigned to without a data type. In newer editions, if the indexer is left with an undeclared data type, the above expression would evaluate to "FS@1.00000000.DY", rather than "FS@1.DY" on the first time through the loop. Since there is never a system Parameter named "FS@1.000000000.DY", this expression would refer to a null Parameter. System Parameters retain their data type permanently. It is not necessary to declare a data type when assigning to a system Parameter.

Bear in mind that—in contrast with most other languages—Parameters (i.e. variables) do not automatically retain the data type they were first declared with on subsequent assignments. So, when you declare and assign my_param<deg> = 90, and then reassign it later to my_param = 80, on the second of these two assignments, CV changes its data type to the default type of <meas>. So, even when you have already established a data type for a custom Parameter, you must repeatedly specify its data type on subsequent value assignments unless you want its data type to change to <meas>.

Delete Temporary Parameters

The Object Tree in CV can get cluttered, and when this happens, it becomes more difficult and error-prone to assess the state of the model it is describing. Custom Parameters are used mainly to hold temporary values that later supply values for system Parameters. In practice, you can usually delete custom Parameters in the same UCS that declares them, and it is good practice to do so. The only exception would be when using "delayed evaluation". In order to assist in determining which custom Parameters should be deleted, it is helpful to give them a special prefix such as "t_", so that they group together in the Object Tree. That way, if you forget to delete some, you don't end up with your Object Tree polluted with various Parameters that you're not sure whether or not you can safely delete.

"Where is this Parameter Coming From??"

It can be difficult to find the location in your UCSs where a Parameter is being declared and assigned to. In the Report Center, there is a helpful CV Report called "User Created Standard List". You can run that report, click inside the window where its contents appear, press CTRL-F, punch in the name of the Parameter you are interested in, and click "Find Next" repeatedly to scan through a listing of all the places it appears.

Naming Conventions

It is helpful to name custom Parameters in a way that allows them to be scanned easily in the Object Tree, grouped by area of concern. The first objective is to have all custom Parameters grouped separately from system Parameters. Since CV uses a leading underscore "_" to name about half of its system Parameters, one technique is to double up on the leading underscore. In some non-compiled languages (such as VBScript) there is a tradition of naming variables with a prefix that indicates their intended data type. For example, an integer-typed variable might be named something like "int_my_variable", so that when it is referred to later, there is no confusion as to what data type it is intended to contain, nor any need to track down its initial declaration and value assignment to ascertain this information. In CV, there is no benefit in following this tradition, because (as mentioned above) data types are required on every value assignment to a custom Parameter unless the default type of <meas> is desired.

The difference between == and =

Simplest way to decide how to use one or the other is:

• If you need to ASSIGN use =
• If you need to REFERENCE use ==

So, for example:

If cab.DX == 20 THEN
  someparameter = cab.dx
End If

The Difference between = and :=

Simplest way to decide how to use one or the other is:

• If you need to ASSIGN code to a parameter use =
• If you need to ASSIGN a value using code to a parameter use :=

So, for example:

someparameter := temporaryvariable + cab.dx  ;will assign the value of the equation to the parameter

someparameter = cab.dx + 2  ;will assign the equation to the parameter

The Difference between Null and 0

• If a parameter does not exist, then it is Null.

• If a parameter does exist, but it's value is set to 0, then it is not Null, but 0.

Example:

If someparameter == Null Then
  (Do Something)
End If

This condition will fire (Do Something) if the parameter does not exist.

The condition will not Fire if the parameter exists and it is set to 0.

• But if a parameter does not exist, and if you test it for a value, then it's value will be 0.

Example:

If someparameter == 0 Then
  (Do Something)
End If

This condition will fire (Do Something) if the parameter does not exist.

The condition will also Fire if the parameter exists and it is set to 0.

Using an Exit statement correctly

With an EXIT statement, you want to use != AND for all the stuff you want to INCLUDE and = OR for the stuff you want to EXCLUDE

This will make the UCS EXCLUDE door styles 2, 3, 119, 511, and 1:

If DoorstyleID = 2 OR DoorstyleID = 3 OR DoorstyleID = 119 OR DoorsstyleID = 511 OR DoorstyleID = 1 Then
Exit 
End If

This will INCLUDE only door styles 15, 36, 17, and 4:

IF DoorstyleID != 15 AND DoorstyleID != 36 AND DoorstyleID != 17 AND DoorstyleID != 4 THEN
EXIT
END IF