Continuously display data but only save discretely

[coolhandLV7]

I've been struggling to cleanly and correctly accomplish displaying continuous data from a DAQmx read but only saving based on a trigger event (discrete).  Instead of spending a bunch of time building a program that will likely be wrong, i thought i'd start with asking for example code to at least help me with the planning and setup of the code.

Hardware is (8) channel AI and (2) channels of DIO, meaning there are (2) discrete trigger events.  For the first event i want to log AI channels 0-3, for the second event i want to save AI channel 4-7.

What is the right approach for this problem?

[jwscs]

you could start by breaking your final goal into disctinct problems.

a) get data from channels

b) write something to TDMS/TXT

c) user interaction

pls come back with a VI that does these things

[cbutcher]

Looks like you have the same task twice, so I'd initially start by trying to do it for one half, then using a reentrant SubVI to duplicate your work.

The acquiring from analog input should be easy to arrange - there are a great many example VIs, and you can find them via the Help toolbar.

You can also find examples for DAQmx Events on digital IO using the same Example Finder - although in this case there are fewer.

You'll want to either combine those examples, or alternatively sample the DIO continuously and check for the event you want. The DAQmx Events are more powerful but a little trickier to work with.

This post might help you if you're starting out with DAQmx - Learn 10 Functions in NI-DAQmx and Handle 80 Percent of Your Data Acquisition Applications

[Bob_Schor]

As you failed to post any code, we have no idea if you have any LabVIEW experience or are just trying to get someone to do your work for you (we've seen many such posts, unfortunately).

To do this task successfully, you should have some familiarity and experience with LabVIEW, at least equivalent to having viewed as many of the Tutorials listed on the first page of this Forum as you can, and where Exercises are indicated, have done them all.  I enthusiastically agree with @cbutcher's suggestion to learn the basics of DAQmx (the "Learn 10 Function in NI-DAQmx" link) is an excellent place to start.  Try to avoid the Dreaded DAQ Assistant and its evil twin, the Dynamic Data Wire.

There are numerous LabVIEW examples under DAQmx.  You've basically described two (separate) Tasks, one involving AI0-3, the other AI4-7, each with their own Trigger.  Before trying to do both of these tasks, solve the simpler problem of developing a VI that does one of these, i.e. acquires data from AI0-3 using a particular Trigger signal.  Depending how independent your two Tasks are, once you have a "Task1" VI and a second "Task2" VI, you could, in principle, create a VI called "Do Both Tasks" and get it to run Task1 and Task2 in parallel (something that LabVIEW's Data Flow paradigm allows and encourages).  But solve the simpler task(s) first.

Bob Schor

[coolhandLV7]

first of all i don't want or need anyone to do anything for me...  I'm looking for a 10,000 foot view on how to approach the problem, as i'm learning this software on my own.  Just forget it, i'll figure it out on my own. 

[cbutcher]

Hi coolhandLV7,

I'm sure that none of us were trying to cause offense. At the same time, without some information about your level of experience with LabVIEW, it can be difficult to appropriately target suggestions or advice.

To take it to an extreme, probably you don't want the first step in your problem solution to be:

1 - Turn on the computer by pressing the power button

because that's pretty obvious (although perhaps you're using a server that's always on via some remote connection and blah blah...)

If you already know a bunch of stuff about using DAQmx, then instructions on which VI to call in which order might be too low-level, the ground-level view, to reference Erik Doernenburg (I think that's who you're referencing?)

On the other hand, if you've never used it, perhaps more introductory instructions are helpful.

The people here on the forums are happy to try and help with suggestions or guidance, along with links to existing materials or other posts, so don't feel you have to "figure it out on [your] own". At the same time, the latency here is typically hours, so you'll learn more by reading things that already exist if the time is short and the material is available.

[mcduff]

@coolhandLV7

I gave you a 10k ft view on your previous post.

See https://forums.ni.com/t5/LabVIEW/Error-200361-Buffer-Overflow-Error/m-p/3802940#M1073440

If you post an attempt here somebody will proffer help, but you need start with something. Expanding on the previous post, I would make EVERYTHING event driven, new step in bold. (Go to the example finder in LabVIEW to find examples) This is a State Machine architecture that contains an event loop, like the JKI State Machine. ( https://jki.net/tools )

1. Start the program.
2. Check if the DAQs are available
   1. If they are available first initialize and go to an "IDLE" State
   2. If they are not give message to user and exit program (or you can add a "refresh" button to re do the search for the DAQs)
3. Now DAQs are present and you are in an IDLE State
4. Wait until somebody presses the "Run" or Start Button
5. Start the DAQ DIO which is set to wait for a "Change Detection Event"
6. Depending on the outcome of the "Change Detection Event"
   1.  go record the specified channels
   2. Make the data acquisition event driven, that is, send an event at N points
7. Go back to IDLE State and Wait until the next event.

mcduff