Ton Plomp Posted April 19, 2008 Report Share Posted April 19, 2008 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. Quote Link to comment
Götz Becker Posted April 19, 2008 Report Share Posted April 19, 2008 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. Quote Link to comment
Rolf Kalbermatter Posted April 19, 2008 Report Share Posted April 19, 2008 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 Quote Link to comment
Ton Plomp Posted April 19, 2008 Author Report Share Posted April 19, 2008 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 Quote Link to comment
orko Posted April 19, 2008 Report Share Posted April 19, 2008 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 Quote Link to comment
Ton Plomp Posted April 20, 2008 Author Report Share Posted April 20, 2008 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 Quote Link to comment
Rolf Kalbermatter Posted April 20, 2008 Report Share Posted April 20, 2008 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 Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.