LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Can we ask LV why it shows a coercion dot?

I have an unexpected coercion dot. Can I get LV to tell me why something needs coercion, or provide some other clues?
 
The coercion dot happens where I pass a complicated cluster into a subvi. The complicated cluster contains seven arrays of references (to booleans or to numerical I32 controls) plus one cluster. This inner cluster contains references to four tab controls and to one boolean. The subvi manages disabling some referenced controls and graying them out, and enabling and ungraying others, according to the state of the state machine (on the blue wire) which is also the calling vi. The subvi uses a strict typedef control on its front panel to accept this complicated cluster. I originally created that strict typedef by right clicking the cluster wire in the calling vi block diagram, creating a control, and customizing that control (and then deleting it from the calling vi which doesn't need it). I think the coercion dot did not appear at first, but appeared later (don't remember changing anything here though).
 
Subsequently passing this complex cluster to further instances of the subvi does not create coercion dots on them. Inspecting the clusters and controls and vis and experimenting with them hasn't turned up an explanation yet. I'm aware of different data types in general and don't have any other coercion dots in this big project. Everything seems to work as intended, but unexplained and unexpected coercion dots don't seem like a good thing to ignore.
 
The project is proprietary and I can't post it, and I don't know how to reproduce this in an example. But FWIW I have included part of a screenshot, without labels.
 
0 Kudos
Message 1 of 7
(3,528 Views)

When using typedefs you can get a coercion dot because LabVIEW is technically doing a coercion from a non-typedefed structure to a typedef structure.   ie, if I have a typedef that is a cluster of two booleans, and I pass it a cluster of two booleans, the coercion dot will appear.  I don't believe that this causes any code slowdown, but am not sure.

 

One way to check for this, is use the help window with the wireing tool, and see if one side has a typedef declaration as part of the wire structure.  Something like this

Side A :

Cluster (cluster of 2 elements)

   Boolean 1 (Boolean (TRUE or FALSE) )

   Boolean 2 (Boolean (TRUE or FALSE) )

 

Side B:

Cluster 2 ( typedef 'Control 1.ctl'[non-strict])

  Cluster 2( cluster of 2 elements)

    Boolean 1 (Boolean (TRUE or FALSE ) )

    Boolean 2 (Boolean (TRUE or FALSE ) )

 

If it looks like that, its a typedef coercion is all.



Message Edited by Mythilt on 07-14-2008 02:53 PM
Jon D
Certified LabVIEW Developer.
Message 2 of 7
(3,526 Views)


cebailey wrote:
 
The project is proprietary and I can't post it, and I don't know how to reproduce this in an example. But FWIW I have included part of a screenshot, without labels.
 


You need to attach your screenshot to your message.  You just inserted an image that is linked to a file on your c:\ which for obvious security reasons, we don't have access to.
 
Message 3 of 7
(3,513 Views)

>When using typedefs you can get a coercion dot because...

I get the messages attached in help_on_wires.gif. Maybe that's it, though it's not exactly as you describe. "strict" appears in both cases. The difference I see looks like everything is nested another layer deep in the righthand, after-the-subvi version. Though, coercion couldn't repair a difference in how many layers deep something is nested, could it? Am I seeing a typedef coercion or something else?

The context help with wiring tool is nice, I didn't know about it. Thanks!

 

>You just inserted an image that is linked to a file on your c:\ ...

Oops. Sorry. I wondered if the reference to "link" meant that, but did a Preview Post and guessed wrong that seeing it work there meant others would too. I attached the screenshot too.

 

Thanks!

Download All
0 Kudos
Message 4 of 7
(3,502 Views)
Hi cebailey,
connect your typedef to the input of your bundle block. I recommend to use "bundle by name".

Mike
Message 5 of 7
(3,491 Views)

Thanks, Mike, connecting the typedef to bundle nails the dot. I usually bundle by name and may change this to do so.

 

So, for future reference, IS there any way to ask LV why it shows the coercion dot? LV must have known some reason to do so, right?

0 Kudos
Message 6 of 7
(3,459 Views)
Hi cebailey,
you can see it in the help as you have shown before. See the first row, one is "strict type def" and the other one is only "type".

Hope it helps.
Mike
0 Kudos
Message 7 of 7
(3,431 Views)