issues making a program for vacuum chamber bakeout control

[modi81]

So now that I got things pretty much ok on the previous problems, I can't get it to pass a True boolean from my thermocouple loop to write a digital out +5V.  If the thermocouple is running, then it needs to be outputting a +5V, and 0V when it isn't running.  The module is what I was working with, the control was what I have been adding to.  I just copied the module bits into the control three times, since there will be three thermocouples.  But now the digital write bit needs to get fixed.

[RavensFan]

You have serious problems understanding dataflow.

Your problem is that the while loop for your digital write is dependent on the completion of the first while loop.  Your first while loop runs continuously until the comparison becomes false (because you have a run while true condition for that loop).  Only then does the boolean value of false exit the loop and the 2nd while loop can begin.

In your Bakeout module VI, you have false going into the loop.  (It can never be True because if it was, the first while loop would still be running and the boolean coming out of the loop wouldn't be there yet.)  So the digital write in the True case doesn't occur, the boolean is still false, and the 2nd while loop exits after the one iteation.

In your Bakeout control VI, you have a different situation.  You still have a false going into the 2nd loop.  The while loop begins its first iteration.  Because i=0 (true) is ORed with the false, the True case will execute and the digital write will put out the false.  Because there is no error to stop the 2nd loop, it will iterate again.  Now I=0 is false ORed with the that came in from the 1st loop.  The false case will execute, nothing happens, there is no error and the loop won't stop because it only stops on an error.  You are now stuck in an endless while loop executing as fast as the processor will allow it.

What I believe you want is two independent while loops.  You can't pass that boolean by wire.  You will either need to use a local variable or a notifier to get the value from one loop to the other.  Also, in the Bakeout control version, you will need some other alternative to stop that while loop besides just an error condition.  Otherwise those loops will continue to be endless, and your master while loop will never get past the initial iteration and you would still need to abort the VI to stop.

I would recommend looking at the online LabVIEW tutorials
LabVIEW Introduction Course - Three Hours
LabVIEW Introduction Course - Six Hours

[modi81]

So will this work?  It uses the local variable to pass the boolean.  However, now my issue is that the DAQ is continuously outputting +5V for some reason.  I went into the Measurement and Automation panels and reset the card, that didn't fix it. Then I went to the test panels in there, to the Digital I/O tab and set all to output and then started the test and then it went down to 0 V and was ok.  Then when I ran the vi it started giving +5V again, which is good, except when the shutoff kicked in it didn't turn the voltage off. 

[RavensFan]

One problem you have is that if Shutoff goes False, the top while loop stops.  It has no way of restarting.  To stop the upper while loop, you should just use a local variable of the stop button.

The second problem is that in the lower loop, the only value that can be written to the DAQ is true, If shutoff goes false, the False case executes where nothing happens.  I would recommend getting rid of that case structure. 

I would recommend that in the lower while loop, you move the DAQ create task and the Daq Clear task outside of the while loop.  There is no reason to create and clear the task on every iteration of the while loop.  Let it create it before the loop, write True or false inside the loop, Clear the task after the loop.

[modi81]

That helps, thanks.  I think I have it just about finished.  I tried using another simple vi to output a voltage from the analog output to the input to simulate the pressure, and another vi to read the digital ins from the thermocouple circuits' digital outs.  It gave me a couple of errors that I give below, except the first two errors are 12 and 14 instead of 14 and 16.  I thought that I had made sure all of the analog I/O and digital I/O were separated (ao0 to ai0+ and aoGND to ai0-; P0.1 to P1.1 and P0.2 to P1.2 and P0.3 to P1.3).  Can I not output and input at the same time?  If so I will have to actually hook up the I/O to the real equipment and try it instead of simulating it.

I tried to run it without the extra vi's now, but these are the errors I get.  

Error -50103 occurred at DAQmx Start Task.vi:14      Possible reason(s):  The specified resource is reserved. The operation could not be completed as specified. 
Task Name: _unnamedTask<3A>

Error -50103 occurred at DAQmx Start Task.vi:16   Possible reason(s): The specified resource is reserved. The operation could not be completed as specified.
Task Name: _unnamedTask<3B>

(Now it highlights the Close File icon):

Error -200453 occurred at DAQmx Read (Analog DBL 1Chan 1Samp).vi:8   Possible reason(s): Measurements: Specified timeout value is not supported.  Supported timeout values are 0 (try or check once and return), positive numbers up to 4294967, and -1 (try or check until success or error).
Specified Timeout(in seconds):  4.294967e9
Task Name: _unnamedTask<39>

Error -200453 occurred at DAQmx Read (Analog DBL 1Chan 1Samp).vi:8  Possible reason(s): Measurements: Specified timeout value is not supported.  Supported timeout values are 0 (try or check once and return), positive numbers up to 4294967, and -1 (try or check until success or error).
Specified Timeout(in seconds):  4.294967e9
Task Name: _unnamedTask<39>

Do I have to change the max/min from the 'minimum samples to read' to the DAQ Read.vi? 

[RavensFan]

In your topmost DAQmx read, you are comparing the # of samples available with the min number of samples to read and taking the maximum of those 2.  Okay.  But why are you feeding it into the timeout connector of the DAQmx read?

(Slide your close file function outside the while loop.  Right now you see it has a shadow.  That means it is not a part of the loop, but happens to be overlapping it.)

[modi81]

Ok, that makes sense.  I used another old vi as a starting point when I began this project.  It didn't seem to be a problem before.  Shows how much I know.  Anyway,  so I don't need to feed the # of samples into the timeout, should it feed into some place else?  Thanks!

[modi81]

I have everything done, except for the debugging.  All of the controls for the bypass and hysteresis' are finished.  I had to use case structures and local variables to do it.  Now it has the errors I had previously, it says that the specified source is reserved.  Any ideas?

[RavensFan]

Your code needs a lot of work and has major architecture problems.  I am reattaching the VI with notes scattered throughout the diagram marking as many trouble spots as I see.

1.  First you use too many local variables and in ways that would lead to race conditions.

2.  You will have endless while loops.  If a local variable is true (e.g.  Thermo X on?)  the loop will run endlessly as the local variable will never go false.  The only place that variable gets updated is a piece of code outside the loop and that won't get calculated again until all the nested case structures end and the outer while loop ends.  On/Off Master has the same problem.  If true, the loops will run forever.

3.  I believe this specific error is occurring because you have 3 sample clocks with finite sample of 1000 being created at the beginning.  If these clocks all get generated at the same time (as I believe they will), they conflict with each other.  Also there is a sample clock with continuous samples at the beginning of code.  I don't know how many sample clocks you can create at once.

4.  Since you are primarily using lower level DAQmx functions, there is no need for the DAQ assistants at the beginning of the code.  They really aren't doing anything but defining the channel.  Just use constants for the appropriate channels fed into the lower level DAQ functions.

5.  You duplicate a lot of code between true and false cases with very few differences.  So you wind up with 4 times as much code as you need. 

6.  You have 3 loops that all do the same thing, just on different channels.  These could all be subVI's.  So now your are 12 times as much code as you need.  I think this is why your VI is so large at 626 kB for something that should be rather simple.

7.  What you really need is a producer/consumer architecture with state machines.  Put all of your DAQ functions in a single loop.  The 3 4 analog inputs should be merged into a single task.  I would write their values to the indicators, or better yet use an Action Engine to store their latest readings.  Other parts of code can use the action engine to read the latest value.  Keep your decision code in separate while loops.  Keep your data logging in a separate loop, you can pass what you want to write to file through a queue.

I would recommend you take a few steps back and get things working with 1 analog input first.  Then add the data logging functions.  Then expand your code to work with 3 channels instead of just one.

Message Edited by Ravens Fan on 07-16-2008 11:09 PM