LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

This code cannot possibly fail. Why is it failing?

Solved!
Go to solution
Solution
Accepted by topic author CoastalMaineBird

I run it in 2010 and i instead also changed the indicator to 12345 as default, and it immidiatly changed to 0 when running reentrantly.

 

/Y

G# - Award winning reference based OOP for LV, for free! ADDQ VIPM Now on GitHub
"Only dead fish swim downstream" - "My life for Kudos!" - "Dumb people repeat old mistakes - smart ones create new ones."
Certified-LabVIEW-Developer
Message 21 of 31
(463 Views)

I run it in 2010 and i instead also changed the indicator to 12345 as default,

 

Perhaps you're misunderstanding the instructions.

The error shows up when the CHAN SELECTOR is set to NONE as the default.  The default of the VALUE indicator is irrelevant.

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 22 of 31
(459 Views)

On the other hand, you're on to something, Yamaeda.

 

If the DEFAULT VALUE of the indicator is 0, and the initial value is 12345, I see the misbehavior: the indicator stays at 12345.

But if the DEFAULT VALUE of the indicator is 1 (or 1000 or probably anything else), and the initial value is 12345, I see "1" (or "1000") until the update comes, then I see 0.

 

Weird.

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 23 of 31
(456 Views)

Confirmed.... If the default CHAN SELECTOR is -1 (None) and the default VALUE is 0, and the initial value is 12345, and it's run reentrantly, then the 12345 stays in the indicator (misbehavior).

 

If the default CHAN SELECTOR is -1 (None) and the default VALUE is ANYTHING OTHER THAN 0, and the initial value is 12345, and it's run reentrantly, then the indicator shows the default value until the first update event, then goes to zero (expected behavior).

 

Setting the VI's CLEAR INDICATORS WHEN RUN property doesn't change anything.

 

It turns out that this is not really a problem for me - the only reason I had the initial value at 1,2,3,4 was so I could ensure that I was connecting selector 1 to indicator 1 and units indicator 1....  But the wonky behavior made me worry.

 

So the solution seems to be to set the DEFAULT value to 1e-16 or something innocuous, and leave the code as is.

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 24 of 31
(455 Views)

It looks like the problem boils down to this:

 

In REENTRANT mode, the indicator fails to recognize that the value it is actually showing is NOT what it has stored in it's local copy.  

 

When it's DEFAULT value is zero, then it's local storage starts out at zero, and when given a value of zero to display, it thinks it doesn't have to change the display because it's not a value change.

 

When the DEFAULT value is NON zero, and it's local storage IS zero, it knows that it has to update the display.

 

The live channels worked because they were non-zero (non-default, to be precise).

 

The index had nothing to do with it - if a live channel had been a constant 0.0000, the same problem would show.

 

 

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

Message 25 of 31
(447 Views)

CLEAR INDICATORS WHEN RUN doesn't change anything for the same reason - it sets the indicators local value to 0, but the indicator itself doesn't recognize that as a change, so it fails to update the display.

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 26 of 31
(449 Views)

All I can say is (In a Walter Sobchak voice):

 

"Way to go Forum users!"

 

Crowdsourcing at its best.  I hate when I get landed with these awkward kinds of bugs......

Message 27 of 31
(441 Views)

Did you try my suggestion from the previous post of forcing the indicator to update?


___________________
Try to take over the world!
0 Kudos
Message 28 of 31
(429 Views)

Did you try my suggestion from the previous post of forcing the indicator to update?

 

 

Yes, I did, and thank you.  Sorry I didn't report.

 

Using a VALUE Property Node makes the issue go away. My guess is that the property node bypasses the "Do I really need to update the display or is it the same as last time?" logic inside the indicator.

 

(Hmmm. that would explain why a VALUE(SIGNALLING) property will always fire an event, even if the value is the same as before, I suppose).

 

But a property value is not a good solution in my case, as the performance penalty is severe.  Here are notes from a test I did a month or two ago:

Time it takes to generate a random number and:
feed to chart terminal:   0.185 uSec
feed to local variable of chart:  0.217 uSec
feed to direct Property Node (VALUE) of chart on this VI:  495 uSec 
feed to reference property node (VALUE) of chart on another open VI:  477 uSec
feed to reference property node (VALUE) of chart on another CLOSED VI:  55 uSec.

 

Note that its 2000+ times the time to use a Property node (for a chart, anyway).

 

 

 

 

Explicitly setting the value to 0 via local variable at startup didn't work, because the indicator thinks it's already showing a zero, so it thinks it doesn't need to change.  It's a bug within the indicator itself.

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 29 of 31
(420 Views)

You could just use a value property the first time around (outside the loop or when First Call returns True).


___________________
Try to take over the world!
0 Kudos
Message 30 of 31
(417 Views)