Sub VI triggering problem

[GeorgeR]

Hi, I hope you can help. As a complete novice to LabVIEW, this may be a very simple one to fix but I cant seem to get it to work 😞

I have a problem with triggering a subVI running in my main VI. The aim is to detect when a sensor has been broken, and if this breakage is longer than the minimum time specified it will trigger a TTL signal to be sent (using the USB 6501) to a valve which will open and deliver a reward. The main VI (Flowers) and the SubVI's (einzel blute & ventil) work fine on their own, and everything apart from the 'ventil' subVI works when the main VI is running (sensor breakage is recorded fine etc). The problem seems to be that the 'ventil' subVI only executes once the 'Stopp' button corresponding to a while loop is pressed on the front panel. Is there a way to get this subVI to be triggered? Am I

Any help would be greatly appreciated,

[MikeS81]

Hi GeorgeR,

are you sure your sub vi runs parallel to your while loop? Can you upload your vi?

Mike

[GeorgeR]

Hi, I did upload my VI before, but it appears not to be there any more, along with a different reply :-s

The advice I was given was to use master/ slave loops which I have now tried, and the subVI is triggered now although it's not really functioning properly (a pulse is sent but stays high so the valve just stays open whereas in the subVI on its own, a pulse is given to open the valve for a short period of time). Also, ideally the valve should open while the sensor is being broken but this occurs afterwards, is there any way of getting this to work?? I will attach again the VI's and subVI's with the additional master/slave version.

Thanks very much

George

[GeorgeR]

Here's the valve subVI too

[GeorgeR]

Actually, I think the problem with the pulses sent to the valve is because of the differences in loop timing but I could be wrong....  

[Tom O]

Hi GeorgeR,

I've had a look at your program and one issue that you might be facing with your digital output timing is a race condition. You had a timing node set to introduce a delay between setting the line high and low again but it was in the same frame as the original "high" command. This means that all the time could elapse before the line even goes high, depending on how the program runs. Have a go with the attached VI that I modified and see if your results are more consistent!

Regards,

[GeorgeR]

Hi Tom, thanks for your reply, I cant open the modified VI as I have an older version of LabVIEW (8.2), would it be possible to re-post it in this version?

Thanks

George

[Tom O]

Sorry about that, wasn't sure which version you were running. Give this a try and let me know how you get on!

[GeorgeR]

Hi, I've tried the modified VI but there is still the problem that, when the valve is triggered the first time, the signal stays high and dosn't go to low untill the valve is triggered again, then it seems to work (albeit slightly temperamentally) after.

Any suggestions/ ideas on why this is happening will be greatly appreciated!

George

[Tom O]

Hi GeorgeR,

I've been looking at your code as well as trying it out here with my own hardware but have been unable to replicate your problem! The sub vi is certainly fine, although I had to add a control to your main architecture to trigger it. The issue may lie with:

• The way your architecture triggers the sub vi - does it call it several times at once, making the output oscillate?
• Does your hardware use negative logic (low leads to an LED being ON, for example)? This might be complicating the issue.
• Some other issues with your hardware setup might be causing the problem, as I don't have that setup here!

I hope this helps you track down the issue a bit, sorry it's tricky for me to help from here without being able to replicate the problem.

Regards,