Input Coercion with Shared Variables

[Peter_Blume]

Hi.

I have a shared variable with custom data type based on the attached strict type defined cluster. Whenever I change the type definition, it appears I have to go to the shared variable properties in project explorer, temporarily choose a new data type to erase the previous version of the type definition from the variable's memory, then choose custom data type and navigate back to the type definition, forcing a refresh of the link. Is there a better way of refreshing the link to a type definition? In any event, I have a coercion dot at the shared variable's input terminal that won't go away. See attached screenshot. Any ideas?

Thanks,

Peter

[Elsa Fung]

For the shared variable properties, I think LabVIEW was design that way.  Same thing happens when you create a custom control and use it in the front panel.  Everytime you edit the custom control, you have to reload the control/indicator in the front panel.  So it's like a stamp instead of a link.  It'll be nice if it's a link, but that will probably require a deploy on the custom controls as well.  It'll probably make LabVIEW even slower if it was implemented that way.

As for the coercion dot, you didn't attach the screenshot.

See-Ming

[Charlie S.]

Hi Peter,

It doesn't look like anyone's posted to this thread in quite a while, but I'd like to followup anyway. What's stated above here is correct. The variable properties page is a static configuration -- it's saved in the .lvlib file. Thus, there is no link between a type definition and the shared variable like there is with a VI block diagram constant or front panel control. A custom control is simply the most direct means of specifying a complex datatype for a shared variable. You can think of it as a template. After the lvlib is saved, it does not retain a reference ("link") to the custom control -- it only remembers the datatype.

I suspect you are seeing coercion dots after changing the data type of the shared variable, because whatever wire you previously had on your block diagram no longer matches the new data type of the shared variable. For example, you could configure a shared variable to accept a cluster with a DBL in it. Then, if you change that DBL to a SGL later on, you'll see coercion dots everywhere going into your shared variable nodes on your block diagram -- LabVIEW's converting the DBL data type in the wire to the SGL data type that the shared variable expects. If I'm way off the mark here, just let me know -- I didn't see your attachment above, so I couldn't be sure.

As for a better way to do this, I'm not sure that there is one. There is a shared variable on-line creation API available with the DSC module, but it limits you on the data types for your shared variables. (The tradeoff is, of course, that you can new shared variable programmatically without using the project window!) There is also a data type property for shared variables, but that isn't going to change the shared variable nodes on your block diagram -- you would have to code with Datasocket functions instead. Furthermore, if you re-deploy your .lvlib those changes will be overwritten.

I hope this helps clear up any confusion. Please let me know if you have further questions.

Thanks!

[Peter_Blume]

Hello Charlie,

It appears as though whenever the custom control is a type definition, a coercion dot will automatically appear. The only way to remove the coercion is to change the control's type definition status to custom control. Please see the attached project.

Peter

[Charlie S.]

Hi Peter,

Thanks for the additional information. You are correct that a coercion dot will appear if you wire non-typedef'd data to a typedef'd control. This is expected behavior in LabVIEW 8.20. Since the Shared Variable is not truly typedef'd (even if you point it to a typedef using the properties page from project explorer), wiring it's output to a typedef'd control will show the coercion dot. You can see this behavior with any typedef control -- shared variable or not.

The question I have now is whether this causing an extra memory allocation. I've done some tinkering here, and I suspect this is not the case; however, I would like to be sure. I'll follow up with some people in R&D and let you know what I find out.

Thanks!