FP default-values and diagram "constants" can change in LabVIEW 6.1 and 7.1

[Dynamik]

Hi Folks,

      I'm posting here [instead of bug report] first, in case this isn't really a bug.

I created a bunch of similier VIs with type-def cluster inputs, and, on each VI, gave the clusters a default-value.  I'm finding that when these typedefs are changed by removing an element, the default FP values are corrupted.  In my case it gets worse.  When I used these VIs on diagrams, I frequently created a cluster-constant - derived from the VI's cluster-control (described above.)  The remaining elements in the diagram-"constants" are also changing.

Regards

P.S.  Sorry if topic has already been discussed! (I did search a "bit", first...)   

Message Edited by Dynamik on 10-28-2005 10:44 PM

[Odd_Modem]

Yes, that happend. If you build the constant with the bundle function the value stays stable. Just make a VI with the cluster as the output and manually build up the value from intrinsic data types. Use that instead of the constant. OTOH, if you don't change the structure of your cluster then nothing out of the ordinary will happen. I am not sure what is the justification for this behavior but it might be something similar to a reset of a shift register value to default when the vi is recompiled.

[Ben]

This sounds like it could be a bug AND normal operation.

There are bugs in LV 7.1, 7.0 and possibly earlier that cuases LV to choose the wrong value when bundling and un-bundling by name.

I have been told these are fixed in LV 8.0

See this thread for more details on the bug.

http://forums.ni.com/ni/board/message?board.id=170&message.id=105455&jump=true

Now as far as the constants that are based on the typedef changing, tht is normal behaviour. As Odd_Modem mentioned, doing an explicit bundle by name is the way to handle this. If you use the same "constant" repeatedly in your code, a sub-VI that does the bundling makes your code a lot easier to read.

Here is a code snippet

and the source for that example can be ound in this thread.

http://forums.ni.com/ni/board/message?board.id=170&message.id=148471#M148471

Ben

Message Edited by Ben on 10-29-2005 10:42 AM

[Dynamik]

Thanks for the link, Ben,

      Phillip C.'s post seems most helpful.  He makes the distinction between object-references and control-references.  Looks (to me) like "Make current value default" updates a table of default-values - which are applied sequentially to objects in the cluster (when the user selects "Reinitialize to default value" OR whan a type-def change is detected.)  But the defaults-list isn't being updated [correctly] when a cluster-object is removed - so obsolete default-values start getting forced onto a new list of objects.  I'd have thought that a "default value" would become a property of (stored "inside") the cluster-object, and, so, follow the object.

Thanks for the work-around!  Of course if someone needs the constant/defaults in many places, they would want to use a sub-vi, refer to a global value, or employ some solution to constrain the damage caused by typedef changes.

Regards