Events controlled by real time, not user input

[kbrigit]

Hi everyone, 

I'm a Labview beginner and I have a long question, so bear with me. I'm using Labview 2018 (32 bit), a Vernier sensor DAQ, and NI DAQ 6002.

I'm using Labview to control a reactor. First and foremost, I need Labview to collect sensor readings from my reactor 24/7. These measurements (pH, temperature, and dissolved oxygen) need to happen anywhere from once/second to once/every 5 seconds. (i.e. I don't need super fast measurements, but I do need constant ones).

During certain times of the day, I need the measurements from my pH and oxygen sensors to turn on pumps and mass flow controllers (MFCs) based on those sensor readings. For example, if the pH is over 7.3, a pump should turn on until the pH is back below 7.3. These actions should only happen during certain times of the day, though--right now I have Labview set up to activate a case structure during the given time intervals.

The problem is, likely because I'm having Labview constantly poll for the current time as well as poll for different sensor values, I keep getting the error -200279: Unable to keep up with aquisition in DAQmx, which is tied to my "Analog Express" sensor DAQ VI. This error happens after about 16 hours of run time, over which the VI gets more and more "laggy". (Attachment 1).

I've tried using a state machine that just runs different cases for different set times (also attached, attachment 2), but this isn't a great solution for me because I need to be able to hit start and have the VI figure out if pumps and MFCs should be controlled or not based on the time of day. 

I've also tried using a producer-consumer architecture (attachment 3), where the current time of day was the producer, but this system also isn't working for me--and I'm not quite sure if I've set it up wrong or if it's just a poor fit for what I want. 

Is there a way to set up an event structure where system time, not user input, is the event? Or is there some other way I can change my code so that I can run this program for at least a week at a time? 

Many thanks for any suggestions, and I apologize for the essay. 

[mcduff]

Just guessing here - I imagine that you are having problems because of all those express VIs. They make things easy short term, but long term you usually run into problems.

Most of those express VIs will re-initialize every loop, which is not need.

Take at look at this.

Once you change over to regular DAQmx people here will be able to help more. You can move all of the initialization outside the loop, and close after the loop.

mcduff

[Kevin_Price]

1. First and foremost: what happens if your program fails in its mission to control the environment and the reaction(s) going on?   Windows could crash, your control logic may have subtle bugs, etc.   What are the consequences of leaving pumps on at full flow when they need to be stopped?  Or vice versa, having them stuck in off state when you want them on?

   It may take some additional hardware, but first make sure your system fails to a safe state.

2. A system that only calls for sampling 1 time every 1-5 seconds *probably* doesn't require a hardware acquisition clock with a fixed sample rate.  You can probably leave the task in software-timed on-demand mode by never configuring a sample clock.  Then each time you call a read (or write) function, it happens right then in response to your software function call.

    Staying in software-timed mode will help you avoid error -200279 and many others.

3.  Please understand that I mean this constructively:  at present, it looks like you've paid considerably more attention to detail on your front panels than on your block diagram code.  Front panels *rarely* occupy a sizable fraction of my efforts.  With most stuff I work on, it's much more important to work right than to look nice.

    I don't really have the time to digest all details of your app and give specific step-by-step instructions all the way through.  I'd highly recommend you plan to log your system state every loop iteration for later review.  Store a timestamp, your measurement inputs, your signal outputs, and any pertinent info.  This is going to be extremely valuable when you don't like a behavior and you need to debug your logic.

4. I agree with mcduff that it'll be better to use regular DAQmx instead of Express VI's.  Just realize that it's also gonna give you a lot more task wires to contend with.  In the long run, it'll be worth it to gain clear and explicit control over your DAQ tasks. 

-Kevin P

[kbrigit]

Thank you guys for your help! I will definitely work on converting my express VIs over. Kevin, could you explain to me a little more what you mean by this? 

2. A system that only calls for sampling 1 time every 1-5 seconds *probably* doesn't require a hardware acquisition clock with a fixed sample rate.  You can probably leave the task in software-timed on-demand mode by never configuring a sample clock.  Then each time you call a read (or write) function, it happens right then in response to your software function call.

    Staying in software-timed mode will help you avoid error -200279 and many others.

---

How do I put the task into software-timed mode/not configure a sample clock? Also, is a producer-consumer architecture maybe a better idea for this type of program? If so... Any suggestions on what's wrong with mine? Thanks!

[Kevin_Price]

If you never call DAQmx Timing at all, no hardware sampling clock gets configured and the task remains in software-timed on-demand mode.

There are shipping examples for AI and AO that illustrate this, their names include "software-timed" and "on demand" respectively.   Help->Find Examples...>> Hardware...>> DAQmx >>...

-Kevin P