LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Reinitialising a vi?

Reinitialising  a vi?

 

I have this sub Vi which controls a 2 syringe  pumps (pump.vi). the theory behind the control is as follows. The process starts with pump A full, and pump B empty.  A begins to empty and thus B begins to fill. Until A is empty and B is full, a shuttling process. this is the A-B part of my sequence. I then have a small delay as a 2nd sequence.  Then the 3rd sequence is B-A which as you can imagine is the reverse. My pump.vi can do both, depending on what constant I select. 

e.g.

 

sequence 1 – pump.vi has the “empty pump A” enumerated constant selected.

The pumps are ramped up to max flow rate, maintain steady state for desired time, then ramp down to rest.

 

Sequence 2 – Delay of n seconds

 

Sequence 3 - pump.vi has the “empty pump B” enumerated constant selected.

The pumps are ramped up to max flow rate, maintain steady state for desired time, then ramp down to rest.

 

Now for about 80% of the time is program does what it says on the tin, but there is that small percent where it doesn’t and i have my suspicions as to why.  

 

Sometimes when it goes into sequence 3, which calls the pump.vi again but with a different constant to send it in the reverse direction.  Its almost like it skips past most of the code inside pump.vi because of Boolean alues which were controlling while loops etc retained the previous values when it was first called, so exited the loops 

Prematurely.

 

Does that make sense?? This is what i think is happening as it doesn’t happen all the time, often it works perfectly, which suggest to me that this is a timing issue. When recalling the same vi

Is there any way i can re-initialise the vi before its called to run the 2nd time

 

 

 

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

Its better to use reinitialize to default for all the indicators and controls at the start up. In this case you will ensure that when you are running same VI many times the variable will act as intended and it doesn't hold the previous value, In your case the sequence 1 just ended and variable holds its value, when you call that vi again & if you are not re-initializing then variable will continue with last value as its default.

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

 


@systemcrash wrote:

Its better to use reinitialize to default for all the indicators and controls at the start up. In this case you will ensure that when you are running same VI many times the variable will act as intended and it doesn't hold the previous value, In your case the sequence 1 just ended and variable holds its value, when you call that vi again & if you are not re-initializing then variable will continue with last value as its default.


 

That is simply not true. When you call a VI you provide its inputs from the block diagram. If you do not wire an input, then the default value for that input is what is used. The VI will not "magically" remember what its inputs were from the previous call. Don't believe me? Try this:

 

 

In the second call the Mean VI does not magically remember its input from the previous call.

 

Where did you get this idea from? It sounds to me like you're confusing running a VI on its own from the front panel, and calling it as a subVI.

 

 

To poster: please post your code. We are not mind readers, so we cannot see what your eyes see when you are looking at your computer screen looking at the code.

0 Kudos
Message 3 of 14
(3,165 Views)

I m sorry Smercurio, my bad that I did not write regarding the block diagram inputs, Try this one too, Have a VI with while loop and stop button (switch action)

 

 to stop the while loop. Write the VI in such a way that Stop button is not re-initialised to default at start of VI, Let this stop button be user interface button, So you stop the

 

VI by pressing stop. But you call the same VI somewhere later , the VI runs but stops immidiately because the STOP button was still true. I was reffering this situation while answering the post.;

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

As I suspected, you are talking about an example where you are dealing with a top-level VI. That's totally different than when you are "calling" VIs on the block diagram. When you click the run button in the toolbar you are not "calling" a VI. You are running it as a top-level VI. In this case the VI runs with the current state of the controls. This is by design, and it should operate that way. "Calling" a VI, on the other hand, means you have it on the block diagram, and you provide its inputs programmatically. All unwired inputs means the VI will use default values for those controls that are not wired.

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

I completely agree to what you say no questions. It would be better that labnoob posts a image of the code

0 Kudos
Message 6 of 14
(3,153 Views)

It will be difficult to give you advice regarding your problem without seeing the code. Do you have or use uninitialized shift registers in your subVI? If so, this could be the cause of teh problem you are seeing. Do you use local/global variables? If so you could be encountering a race condition which is causing your problem.



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

Hi Mark,

 

Code attached for the pump contro PID.vi is themain Vi. Im now wondering if it is race conditions as you say, since i am using Boolean locals to control other loop conditions.

The VI works ok when its executed alone (as far as I have witnessed). When its called to run as a sub vi from another vi, its behaviour is unpredictable as described in original post.

 

Theory of operation:

2 pumps being controlled.

Primary pump tracks the ramp up, steady state, and ramp down profiles that are generated.(when the VI is called to run the second time, its like it skips a bit of the code (the main While loop for primary control, which incidentally is being controlled via a local variable)

 

Secondary pump  tracks the volume error and adjusts its flow rate proportionally, and relative to the primary pump flow rate, to maintain a constant volume.

As mentioned earlier i have been using local variable Boolean values as flags effectively to trigger events in the other loops, i.e. exit conditions etc. I’m  now wondering if this could be the cause of the unpredictable behaviour.

 

 

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

Could you pls down convert to 8.6.

0 Kudos
Message 9 of 14
(3,109 Views)

8.6 attached.

 

I've reduced the number of local variables since the first attachment to see if it helps.

 

one thing I’ve noticed which could be fundamental to solving:

 

WORKS - when VI is run alone

WORKS when called from main application as a subvi, PROVIDING i manually open the vi first, and just minimise it to my desktop

DOESNT WORK reliably - when its called to run from the main application without it being opened first. 

0 Kudos
Message 10 of 14
(3,103 Views)