Error

[s.turino84]

Hello developing my application I found that the red point near the build array function. I suppose that it is an error but I can run it without problems and I don't know how to remove and see what kind of error (if it is an error ofc) is.

Thank you in advance.

[0utlaw · Accepted solution]

Hello s.turino84,

That is a coercion dot ( http://zone.ni.com/reference/en-XX/help/371361K-01/lvconcepts/coercion_dots/ ).  In this case you're seeing them because the references you are building into an array have to be upcast to a more generic type.  It's not an "error" per se, just an indicator to the developer that LabVIEW has to do something behind the scenes to make things work.

Regards,

[mikeporter]

The red dots aren't errors. They show that the datatype of the wire is being coerced, or changed into a different datatype.

In the case of you code, you are building an array of three control references. However, there are two different types of controls: a couple booleans and a string. The dot are there because LV is coercing the three input to the lowest common denominator -- which is a generic control reference.

Mike...

[s.turino84]

Thank you guys. Another question is it a good idea to correct them? And in this case how can I correct them? 

[Norbert_B]

In the code you show in the screenshot, there is nothing to "correct".

The constraints for an array is that each element must be the same type. Your are is therefore of type "control reference".

You feed the array with "boolean control reference" and "string control reference" for instance, so they have to be 'converted' to a common reference type: control.

This is called "up-cast". When trying to use control specific properties in the code later on, you have to extract the correct reference and then "down-cast" it back to the specific control reference.

You cannot remove the up-cast. You could only do it explicit before creating the array.

Norbert

[0utlaw]

If you want to store references of multiple types in the same array, you'll need to either cast them ahead of time using the "to more generic class" functions in the Programming>>Application Control palette or let LabVIEW coerce them to the most generic class that includes all of the control types you want.

The general rule is that coercion dots slow down your VI's execution speed, and getting rid of them by adding code to cast values to a specific type will speed up your program slightly.  This may or may not have a noticeable affect on your application.

This ( http://labviewartisan.blogspot.com/2012/08/whats-deal-with-coercion-dots.html ) might be worth looking at as well.

Coercion is a basic concept in LabVIEW and is definitely covered in the LabVIEW self-paced training available here (if you have a valid/active LabVIEW Serial number and support contract):

NI Self-Paced Online Training

https://lumen.ni.com/nicif/us/LMS_LOGIN/content.xhtml?du=http%3A%2F%2Fsine.ni.com%3A80%2Fmyni%2Fself...

Regards,

[s.turino84]

OK I understand. Thank you Norbert.

[s.turino84]

Thank you for the links Outlaw

[0utlaw]

Glad to help!

[mikeporter]

The other thing you could do that could actually be cleaner logically - and less error prone in use - would be to replace the array with a cluster. This chnage would allow each item to retain it's own distinct type. More importantly, though, it might represent the structure of the data better.

You see, the idea of an array is that the elements are all holding the same thing logically, so you can have an array of voltages or an array pressures. The only thing that makes one element different from the next is its value. But depending upon what you do with these references next in you code, that might or might not be what you have here.

If the only thing that happens next is that the array is passed into a loop where the controls are all, say enabled, then they are logically all the same kind of thing. They are all controls that need to be enabled.

If however, this array is going to be passed around you program so different thing can be done with them, then the elements are not all the same thing. Even if they were all booleans, they would still be three different booleans, representing and doing different things. Consequently, in order to access a particular control reference you would have to know a new piece of information that you just arbitrarily created: Its position in the array. A better solution in that circumstance is to put the references into a cluster so each item can have its own unique datatype and name, and you can use that name to get the specific item you want.

I guess what I'm really saying here is that selection of datatypes is one of the most fundamental and most important design decisions that you can make. Pick the right data structure and life is good. Pick the wrong structure and you'll be fighting with it the rest of the project.

Mike...