LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Coersion Dots with VI References

Solved!
Go to solution
Highlighted

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?

Seth Price, N3MRA
Lab Associate, Chemical Engineering Department - New Mexico Tech
Lab Assistant, Sodium Dynamo Project
0 Kudos
Message 1 of 6
(805 Views)
Solution
Accepted by topic author N3MRA

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).

NotARefnum.png

Bob Schor

Message 2 of 6
(785 Views)
Solution
Accepted by topic author N3MRA

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.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
Message 3 of 6
(780 Views)
Solution
Accepted by topic author N3MRA

@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.


LabVIEW Champion. It all comes together in GCentral GCentral
Message 4 of 6
(768 Views)
Solution
Accepted by topic author N3MRA

@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.  😉

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
Message 5 of 6
(733 Views)

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!!

 

Seth Price, N3MRA
Lab Associate, Chemical Engineering Department - New Mexico Tech
Lab Assistant, Sodium Dynamo Project
0 Kudos
Message 6 of 6
(688 Views)