LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Should I use a local, global, or shared variable to control start/stop of a program?

Hi everyone,

 

I am using labview 2010 currently and having a bit problem in making my program to work the way I want. This program I am writing has a simple interface that will be deployed to a small 6" touch screen panel. This touch screen interface is basically used for displaying different measured parameters (flow rate, temperature, etc) in real time and also has some buttons to control actions.

 

In order to make this to work, I am having a vi that is continuously running in background to read the field point module and performing calculations. Then, the final values are stored to various shared variables. These shared variables are also placed in the front panel and wired to various display on the touch panel interface in order to show the values in real time. So far this appears to be working.

 

Now I am including a new function to save these data to a text file. I would like to have a button on the touch panel to control the saving, i.e., clicking the button will start logging, and re-clicking the button will stop. If clicking the button again will resume the saving, etc.

 

The problem I am having is that when I click the button, it activates the saving but when I re-click the button it does not stop the action. Since the file saving program is in the background vi, I am using a shared boolean to wire the button to and then create another shared boolean in the background vi to link to a true/false case loop for saving the data. This case loop is placed inside the whole while loop for reading data in real time. Am I doing something incorrect? I believe I can not use local variable because the display and program are in separate files, is that correct? I think I used to read from some labview notes that when I embed program I can not use global variable, that's why I choose to start with shared variable.

 

 

Tak

 

 

0 Kudos
Message 1 of 14
(3,218 Views)

hi

it s not so easy without knowing the architecture...but you can use a boolean FG, together with the other "shared variables".

trap the Event "save" to write to a FG, read the FG where you need to save data.

(if the button is used only for save, a simpler way is just to wire the button -check for correct latching on/off-to the select case where saving is done)

N

0 Kudos
Message 2 of 14
(3,212 Views)

It would ofc be easier for us if you could post the problematic vi. 🙂

The correct and beatuful way to solve it would be to send an Event or queue with the save/dont save command, but barring that it sounds like you're reading the boolean outside a loop thus not getting the updated value.

 

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 3 of 14
(3,199 Views)

Hi N,

 

Thanks for the reply.It sounds like I was doing similar to what you said. The on/off switch is a boolean on the front panel and it writes the value to a shared variable. Then in the background vi, I am reading this shared variable back and connect this to a case structure. I will capture a screen shot of the program on Monday and post it again. Sorry for the trouble because I don't have access to my work computer at the moment.

 

tak

0 Kudos
Message 4 of 14
(3,192 Views)

Hi Yamaeda,

 

You are right. I am indeed reading a boolean status and use it to control a case structure to save or not save the data. I place this structure inside a while loop that will run forever with a 100 ms wait. So I thought as long as I control the boolean by the next cycle it will read the correct state. This is obviously not the case. It just stays on once it is clicked. I will post a screen shot on Mon to explain this better. May be you can tell if such situation is better off using event or queue than what I did. Thanks in advance.

 

tak

0 Kudos
Message 5 of 14
(3,187 Views)

The boolean needs to be inside the while loop to read the updated values. Else it'll send 1 value to the loop which'll be reused. (It's rather logical if you think of it in a text based sense, if it's outside the loop it's sent as a parameter and thus not updated inside the loop)

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 6 of 14
(3,166 Views)

Yamaeda is right: you have to have not only the CASE structure inside a loop, but you have to READ the value within the loop.

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 7 of 14
(3,156 Views)

Hi Yamaeda,

 

Thanks for your reply. Here is the vi that I am having a problem and let me try to explain. I also attach couple screen shots for part of the program to explain the situation.

 

The "Touch front panel" is my front panel vi. It has 2 while loops and the one attached is wired to the button controls while the other one (not shown) is just updating the shared variables for display purposes.

 

The "Background program" is my vi (which its vi is also attached) that is actively pulling data from the FP module and then combining the data to an array and send it to another vi to save the data. According to what you said, it seems that using the case structure here is not correct.

 

My problem is that when this vi is running, clicking the "log tunnel 1" button will activate the data saving, but as you said, it will not stop when I click the "log tunnel 1" button again. I think what you said actually makes sense to me. I just look at my data file more carefully and found that the data was not updating as well, so you suggest an event structure is the best way to go?

 

Tak

0 Kudos
Message 8 of 14
(3,127 Views)

First off, your code is using infinite loops. You have False constants wired to the stop condition. The only way to stop your program is to use LabVIEW abort button. This is a very bad way to exit your program since this is a hard abort. You have no opportunity to perform any type of cleanup activities or to shut down gracefully.

 

With respect to your logging I believe you are running into a classic race condition. Since you are reading the buttons directly and depending on your mechanical action of the buttons it will not retain its value once it is read. Therefore pressing the button will only produce a momentary True and the majority of the time you will be reading it as false. I recommend that you look at using the event structure captures the button presses as well as use a notifier or a queue to send the message to your second loop that it should log the data.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 9 of 14
(3,110 Views)

Hi Mark,

 

Thanks for getting back to me and thanks for your advice.

 

Originally I did have a stop button to stop the loop but then I thought the objective of this front panel is to start up and continue to read data forever and need not to stop. I have already wired a abort button to it now.

 

In my background vi, I start to play around with the event structure. I never use this before so I wasn't quite sure if I am doing it correctly. Let me ask you this. I have now included a boolean that is true when both of my "log tunnel 1" and "save data" buttons on the front panel is on. I suppose this event structure will start when the value of the boolean is changed. But how do I tell the event structure to stop when either one of the button is not on?

 

Tak

Download All
0 Kudos
Message 10 of 14
(3,095 Views)