DAQmX read trigger

[tbob]

I'm sorry but the vi is too complicated for me to determine the problem.  I don't have all day to study this beast. 

One thing I see is if both Pressure low threshold and Pressure high threshold controls are False, then the pressure data is compared to 100.  If the pressure is greater than or equal to 100, then both following cases will be true and you will be defining start time and end time as the same time.  This can't be what you want.

I also see a possible race condition in the case structure below, the one with a sequence structure within a case within a case.  In frame 0 you have local variables for start time and end time.  How do you know that you are reading the locals after the write has taken place.  There are probably times when the read happens, then the write happens, resulting in a difference of times.  Not good. 

You really need to restructure the entire vi.  Create several subvi's and make this one more simple and easy to follow.

[romesh]

Thanks for your help and your suggestion. I will implement it in a state flow inside a state flow to nail this down. But

before I do that I have a theory and I would really appreciate if you could provide your comment or confirm my theory.

In my main vi as attached I wait scan all the 60channels using daq assistant in scan state and in check threshold state 

as shown in the image I wait for a trigger(+0.5psi) on a particular channel and jump into my monstrous subvi which is a

tight while loop until I time out or I get all my reading.

1) My signal reaches 0 to 32psi in less than a second. So I think by the time I set what channel to read from the array 

inside my subvi for my create virtual channel vi followed my DAQmx timing.vi followed by start task I miss my case

statement to trigger on 2psi(signal might reach 0 - 2psi in few msecs), and I catch 30psi and 32psi to calculate flow rate.

I am not sure how much time will it take for the create virtual channel, daqmx timing and start task block to execute. Is

it like flipping few bits in the register.

2) You mentioned little bit about creating task and read the task. Is it different from the way I am doing it right now. If

so how does it differ. 

Thanks

[tbob]

Creating tasks, channels, etc takes microseconds, maybe nanoseconds.  You should not have trouble with timing.  To be safe, create your task and perform your configuration setup (timing, trigger) before you start your pressure changing.  Start the acquisition at the same time you start to change pressures.

Here is how to create a task using 3 AI channels.  Instead of creating 3 separate Virtual Channels, create the task and pass the task to Create Virtual Channel.  The rest is as usual.  When reading, all 3 AIs will be read at the same time.

[romesh]

I modified the program and developed this new vi just for proof of concept. Still I have +-100 difference in the valuve

in flow rate calculation. Please need your input. I looked at examples that come with labview and I couldn't any example that uses DAQmx read or write buffer. I would really appreciate if I get some pointers on how to use buffers with DAQmx and whether that could improve my situation. Thanks

[tbob]

GREAT improvement.  Now it is much more readable.  I've noticed that you did not propogate the queue ref out of your enqueue functions.  I did this for you.  Try the vi now and let me know if you still have problems.

[romesh]

Yes I still have issues. On the same channel I calculated the flow rate multiple time and it should not vary. If at all it

varies it should .00x. But I get +-50 variation in flow rate. It always reads this pattern 219.003(most of the time),

232.002(few times),282.034(very rarely) and this sequence repeats again and again. Just these three number. Am I

doing anything funky in initializing the shift register. I am trying to understand what does the gettime_seconds.vi

actually do. Will this give me the elaspsed time in seconds. My signal is changing from 0-32psi in 180ms. Can this

function handle this resolution.The labview help recommends to use double precision float to convert this to lower

precision value. Should I do that or just leave it in high precision. Please let me know.

[romesh]

I tried to print my pressure value on an indicator in front panel when I am inside the true case(check 1psi state and check 25psi state) just to make sure I have enough time to capture the signal. I noticed that even though I said when pressur greater than equal to 2psi capture an instant in time the indicator value varies between 2(+-0.5psi)when it captures the pressure value inside the true case. It is not always the same value and that could explain the variation in flow rate calculation. But at 1ms sampling rate I thought this variation should be really small but its not. Instead greater than equal to I tried just equal to block and I don't even get inside the true case since that pressure number is a double and my decimal not always equal to 2.0.

1) I was thinking, instead doing this real time can I log all the samples for each channel in a file and may be at the end analyze the data to calcualte the flow. Will TDMS file be helpful in this case. If so how do I read the channel data for analysis in labview and plot a graph or display the flow rate on each channel

 2) When the pressure reaches 32psi it settles down for 4sec. May be store the unscaled samples for 2sec and analyse it in realtime for next 2sec.

Please need some help.

Thanks

[tbob]

Evidently, you are reading variations in pressure because there are actual variations in pressure.  Nothing wrong with your code.  The best thing you could do is to take many samples and calculate the average.  Instead of reading every ms, just read as fast as the hardware and software will allow.  Setup the DAQ to take multiple samples at the highest rate it will go (you must consultyour DAQ card's data sheet).  Then take an average.

You should not use equal with a floating point number because of round off errors.  You will rarely see exactly 2.0000000000 psi.  Instead of using equal, you should use the InRange and Coerce function, and set the low and high limits to 1.9 and 2.1.  This will work better.

You can use any file you want to store data.  TDMS is OK.  Or simply collect your data into an array and use Write to Spreadsheet File to store the data into a file.  Rather than ask many questions here, try some of these things on your own.  You will learn better through experimentation.

[romesh]

Hi thanks for your support so far. I tried to avoid asking questions and tried different things, but still no luck. This is my first project and its little bit frustrating. A snapshot of vi's that I tried.

1) I went from scratch. I wanted to make sure that I can capture my signal with my data acquistion. I developed the "start cycle buffer.vi" where I start the instrument and when I know that my pressure is gonna increase I manually started the labview and captured 5000 finite samples in a buffer and logged into an excel. I did five difffernt runs and manually calculated the flow rate by the using the timestamp for 5psi and 30psi from my excel(as i know each sample is ms apart)and the flow rate was very close on each run. I thought pretty gud and confident

2)  Then I put together a"start_cycle_nobuffer.vi" where instead of me manually starting the labiview to get samples after the trigger (0psi) I did a simple stateflow where I read just one channel continusly (0.5ms) and when I see my voltage raise and within a range I switch to finite sample and get 5000 samples. I didn't even convert the voltage to pressure at this point just left my trigger in voltage. The thing I noticed is when my trigger happened my voltage was 1.21V and the first voltage I logged in the excel was 2.38V(the signal already crossed 15psi). All I am doing inbetween is stoping the task to reconfigure it as finite task and switching states. It takes altelast 15ms for the signal to reach 15psi. 

I am running out of options. I would really appreciate some help. When I mention onboard clock does it mean its using windows timer or a clock from my DAQ(USB6225). If its windows clock then that might explain some latency.

[romesh]

Sorry forget to attach the vi.