Jump to content

Not wired indicators losing data


Recommended Posts

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:

post-2399-1208543588.png?width=400

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

post-2399-1208543658.png?width=400

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.

Link to comment

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:

post-2399-1208543588.png?width=400

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

post-2399-1208543658.png?width=400

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 :shifty: (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

Link to comment

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

sorry, I thought the llb had two VIs

QUOTE

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

Link to comment

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

post-3266-1208551413.png?width=400

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

Link to comment

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

Link to comment

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

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.