Coersion Dots with VI References

[N3MRA]

Hello,

I am helping someone/backing up someone who is coding a major LabVIEW project.  I am still learning LabVIEW, and I know we want to (for the most part) get rid of coersion dots.  In his block diagram, he has several that go between NotARefNum and VI References, and I can't figure out how to get rid of them.

My understanding is that this code will send a NotARefNum instead of a RefNum if there was an error along the way.  I have included a screen shot of this.  Any thoughts?

[Bob_Schor · Accepted solution]

There are lots of different things that can be Refnums, and each has a different "Type".  Because LabVIEW is strictly typed, when you wire a "generic" "Not a Refnum" constant to a specifically-type App Refnum or VI Refnum terminal, it will show a Coercion dot because it is not the specific type.

In your example, there's a way to "have your cake without coercion dots" -- use the "Use Default if Unwired" property of the Tunnel.  Here's a VI that has App Refs and VI Refs wired (in the unseen True Case) to two pair of Tunnels, the top two "regular" tunnels, the bottom two "Use Default if Unwired".  The "Default" case is, of course, "Not a Refnum".  Note that the second pair of Tunnels do not have coercion dots, yet if you run the code, the Boolean indicators will show True (Not a Refnum) for all four terminals in the False case and all False in the True case (where I wired an Application Ref to Terminals 1 and 3, and a VI Ref to Terminals 2 and 4).

Bob Schor

[crossrulz · Accepted solution]

Don't worry about those.  They will not affect you.  Worry more about numbers being coerced since these are more likely to cause memory and computation issues.

[altenbach · Accepted solution]

---

@N3MRA wrote:

I am still learning LabVIEW, and I know we want to (for the most part) get rid of coersion dots.

---

Coercion dots are typically not a problem that needs to be eliminated. They simply notify the programmer that a coercion is happening and it is up to you how to deal with it.

1. acknowledge it and leave it alone. This is often a good solution, especially with references
2. insert an explicit conversion bullet. This does not change anything except it replaces the tiny coercion dot with a much bulkier conversion (completely pointless!). The compiled code will often be identical, but there are cases where the coercion dot version actually performs better (see also). Again, just leave it alone!
3. Solve the datatype mismatch upstream, i.e. use a different, more suitable datatype from the beginning. This might need changes throughout the project and could be a gigantic task, potentially introducing other bugs.

Instead of wasting valuable time exterminating coercion dots, spend the same amount of time optimizing algorithms and improving code readability. The improvements will be more significant.

[billko · Accepted solution]

---

@altenbach wrote:

---

@N3MRA wrote:

I am still learning LabVIEW, and I know we want to (for the most part) get rid of coersion dots.

---

Coercion dots are typically not a problem that needs to be eliminated. They simply notify the programmer that a coercion is happening and it is up to you how to deal with it.

1. acknowledge it and leave it alone. This is often a good solution, especially with references
2. insert an explicit conversion bullet. This does not change anything except it replaces the tiny coercion dot with a much bulkier conversion (completely pointless!). The compiled code will often be identical, but there are cases where the coercion dot version actually performs better (see also). Again, just leave it alone!
3. Solve the datatype mismatch upstream, i.e. use a different, more suitable datatype from the beginning. This might need changes throughout the project and could be a gigantic task, potentially introducing other bugs.

Instead of wasting valuable time exterminating coercion dots, spend the same amount of time optimizing algorithms and improving code readability. The improvements will be more significant.

---

Eliminating coercion dots is drilled into you as you gear up for your CLD.  That being said, there are things that can be safely "unlearned" after passing the CLD, and this is one of them,.  Things like the coercion dots in the Quotient and Remainder node still make me twitch violently before ignoring them, though.  😉

[N3MRA]

Thank you, all of you, for your quick responses!

I think I will leave it as is for now.  I agree that adding an explicit conversion is much bulkier and does not add to the clarity of the VI at all, and since there is no important data lost in the conversion, it is not really worth addressing.

...and yes, I have a CLAD, and am studying for the CLD while working through these, so I am looking for coercion dots wherever I can!!