Not wired indicators losing data

[Ton Plomp]

I thought I understood the meaning of the VI.Execution option 'clear indicator when called'

EDIT: from the LabVIEW help:

QUOTE

Clear indicators when called—Causes an indicator, such as a graph, to clear each time you call the VI that contains the indicator. For a top-level VI, the indicators clear each time you run the VI.

I thought it meant that if a VI is called all indicator are reset, if this option isn't set the data in an indicator should be kept in memory.

So I was about to exploit this for an implicit Functional global:

I thought that if I called this subVI twice, with the first time a valid VI ref, the second time I could read out the indicators (Image and Current VI Ref):

Horror: Picture 2 is empty

Why?

Did I misunderstood LabVIEW? Is there a compiler optimization that bites me?

Here's the code:

Download File:post-2399-1208543755.llb (8.5.1)

Ton

Disclaimer: the use of the sequence structure is only for demonstration uses, do not use it in your own code.

[Götz Becker]

QUOTE (tcplomp @ Apr 18 2008, 07:36 PM)

Why?

Did I misunderstood LabVIEW? Is there a compiler optimization that bites me?

Hi,

although I can´t use your test VIs (DaDa.vi is missing), the behavior is normal. If an indicator is wired to the connector pane and only written conditionally, LV will erase its contents if it is not specifically written.

I attached a small example. The indicator which is read out using VIServer will preserves its contents.

Download File:post-1037-1208546656.vi

Download File:post-1037-1208546643.vi

Edit: I hope I understood your question right.

[Rolf Kalbermatter]

QUOTE (tcplomp @ Apr 18 2008, 01:36 PM)

I thought I understood the meaning of the VI.Execution option 'clear indicator when called'

EDIT: from the LabVIEW help:

I thought it meant that if a VI is called all indicator are reset, if this option isn't set the data in an indicator should be kept in memory.

So I was about to exploit this for an implicit Functional global:

I thought that if I called this subVI twice, with the first time a valid VI ref, the second time I could read out the indicators (Image and Current VI Ref):

Horror: Picture 2 is empty

Why?

Did I misunderstood LabVIEW? Is there a compiler optimization that bites me?

Here's the code:

Download File:post-2399-1208543755.llb (8.5.1)

Ton

Disclaimer: the use of the sequence structure is only for demonstration uses, do not use it in your own code.

I think you misunderstood. And what you want to do is the classical use case of LabVIEW 2 style globals (Uninitialized shift register in a while loop with case structure inside). No obscure reliance on indicators being cleared and maybe not based on full moon, programmer mood and NI stock price, but clear and predictable LabVIEW dataflow (With the exception of some obscure LabVIEW compiler optimization bugs in the past in more complicated situations in some very short lived and unfortunate maintenance releases).

Rolf Kalbermatter

[Ton Plomp]

QUOTE (Götz Becker @ Apr 18 2008, 09:28 PM)

although I can´t use your test VIs (DaDa.vi is missing),

sorry, I thought the llb had two VIs

QUOTE

Edit: I hope I understood your question right.

yes you did.

QUOTE (rolfk @ Apr 18 2008, 09:37 PM)

I think you misunderstood. And what you want to do is the classical use case of LabVIEW 2 style globals (Uninitialized shift register in a while loop with case structure inside).

Yes, you are right, I was trying to outsmart a LV2/functional global.

Thanks for correcting me.

Ton

[orko]

I agree with rolf, but what you are doing is actually possible... if you make the indicators dependant on the output of the comparison (bring them outside the case structure):

Download File:post-3266-1208551317.llb

Of course it totally relies on the indicators not being cleared (according to the "Clear indicators when called" setting)...

Interesting, and I don't see anything inherently wrong with the logic, but it still makes me feel "dirty" relying on this method

[Ton Plomp]

QUOTE (orko @ Apr 18 2008, 10:47 PM)

I agree with rolf, but what you are doing is actually possible... if you make the indicators dependant on the output of the comparison (bring them outside the case structure):

Of course it totally relies on the indicators not being cleared (according to the "Clear indicators when called" setting)...

Interesting, and I don't see anything inherently wrong with the logic, but it still makes me feel "dirty" relying on this method

Yes, I will go this route (but with locals for performance).

This technique is used by NI in the XY chart example.

Ton

[Rolf Kalbermatter]

QUOTE (tcplomp @ Apr 19 2008, 01:22 AM)

Yes, I will go this route (but with locals for performance).

This technique is used by NI in the XY chart example.

Ton

If performance is your concern you should go with uninitialized shift registers for sure. It is true that the Value property is magnitudes slower than the local variable but the same applies to locals in comparison to shift registers, certainly in this case since they will be copied twice for the NotaRefnum case and image datatype typically contains arrays of some size.

Rolf Kalbermatter