05-13-2011 07:55 AM - edited 05-13-2011 07:57 AM
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
05-13-2011 08:06 AM
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.
05-13-2011 08:42 AM - edited 05-13-2011 08:43 AM
@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.
05-13-2011 08:50 AM
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.;
05-13-2011 08:56 AM
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.
05-13-2011 09:08 AM
I completely agree to what you say no questions. It would be better that labnoob posts a image of the code
05-13-2011 10:09 AM
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.
05-16-2011 05:24 AM - edited 05-16-2011 05:25 AM
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.
05-16-2011 07:45 AM
Could you pls down convert to 8.6.
05-16-2011 07:56 AM
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.