Synchronizing data saving of high and low speed Daq with a triggering event

[ultrawhale]

I am currently having issues with synchronizing my data saving for my labview code. Attached is an image of the block diagram of my code. What I am trying to do is to collect high speed and slow speed data and to continuously display the data on the front panel. Then when I trigger the injection event (as seen as the slow event) I want to save the data that is being read for three seconds following a digital TTL trigger. My current design is to always be polling for a write to measurement file in the while loops for the high speed and slow speed data collection and have them initially set to false. Then, when I trigger the system in the slow event I also set the boolean to true for the write to measurement file to start saving data. I then have two more while loops that will delay switching the the save data booleans to low for 3 seconds. This is my first time using labview and so it was the best design I could come up with but it is clearly lacking. I am unsure if the data is truly synchronized with each other, and synchronized with the initial pulse output in the slow event. I have done some research into a better strategy but I have not been able to find a solution that allows for me to continuously collect high and slow speed data, and then to synchronize the data collection with a given ttl trigger. I was hoping someone might be able to provide me with a little guidance on a better direction to take to accomplish the continuous data collection and the synchronized data saving. Also, the slow speed daq is NI cDaq-9174 (with modules three of 9214 and one 9202) and the high speed daq is NI USB-6356. The high speed daq is also what I am looking to use to create the trigger for the data synchronization (it is also being used to start our experiment). Thanks.

[Bob_Schor]

• Please read the "Unofficial Rules for the Forum" (really, they are Suggestions To Help You Help Us Help You).
• In particular, there was nothing "useful" attached.  As the Unofficial Rules state, you should never attach a "picture", but rather with one or more VIs (files with the extension ".vi"), or if there are many sub-VIs, compress the folder containing everything (including your Project file) and attach the resulting .ZIP file.
• What do you want to have happen when there is no trigger?  Is there any reason for the A/D to sample when there are no triggers?
• Can you describe in more detail the data acquisition you hope to do, including the sampling rates you want to use?  Are the High and Low speed channels looking at the same data?  For example, you "monitor" the Low speed channel, see something of interest, "trigger the injection Event" (whatever that means), and then take 3" of data on the high speed channel.  Note that if the two channels are looking at the same data, there's no need to also take 3" of low speed data.

I haven't looked up your cDAQ modules, so some of this may be wildly wrong.  But it seems (to me) that the most important thing for you right now is to "synchronize data saving of high and low speed DAQ with a triggering event".  Your device makes a TTL pulse that you want to use for the trigger.  Well, DAQmx allows you to start A/D conversion on receipt of a Digital Trigger.  So you could have two Tasks set up -- Low Speed A/D from one set of channels, and High Speed A/D from another set of channels.  You set them both up to use the TTL trigger, so when it come, both A/D tasks start to run, in parallel (because you have them in separate While loops, configured so there is no data dependency between them).  Depending on the data rates, you might be able to simply "sample for 3 seconds", and then do whatever you need to do with the two sets of data.

Synchronization is accomplished by using one signal (running in a physical wire) and connecting it to two triffer inputs on cDAQ Input modules.

Bob Schor 

[Bob_Schor]

---

@Bob_Schor wrote:

• Synchronization is accomplished by using one signal (running in a physical wire) and connecting it to two triffer inputs on cDAQ Input modules.

---

Oops -- that should be two trigger inputs (close, but no cigar) ...

BS

[mcduff]

You can use a trigger to synchronize the start of data acquisition but that does not necessarily mean you have synchronized data. To truly have synchronized data you need to have the digitizing clocks synchronous, which they are not between modules. You can either use the same clock for both digitizers of have both of them synchronized to some reference. Your html file shows nothing on my computer, so I cannot make any comments.

mcduff

[ultrawhale]

Hi Bob,

Thanks for the advice. To explain more clearly what I am trying to do, I am trying to have the data saving start at the exact same time as the TTL trigger for both the high speed and low speed. The low speed is collecting data at roughly 60 Samples/second and it is mainly taking temperature measurements, and then a few voltage measurements (to check pressure of our system). The high speed is collecting data at about 2500 Samples per second and it is taking voltage measurements of pressure (this pressure is a highly variable that we are more interested in, which is why it is in our high speed collection) and then various measurements of voltages in different electrical systems of our experiment. The main point being that the low and high speed are collecting different data. The way I was hoping to have the system work is that I am always monitoring the high speed and slow speed data and displaying the data to the user. When I reach the conditions I am interested in (mainly the slow speed temperature and pressure values) then we trigger the injection event (a button on the front panel that starts our experiment). I then want to take 3" of data on both the slow and high speed DAQs with the initial time of both of them starting at the same instant as the TTL trigger. I have attempted this but my issue seems to be in the no trigger instance. If there is no trigger, I still want the DAQ to be collecting data and displaying it to the user. I always want data collected and displayed on the front panel. Only once the injection event is triggered, do I want to save the data that is collected. The problem with the wait for trigger for the DAQs is that they do not collect data until the trigger event occurs.

As to saving the vi with all the sub-vis, I am unsure how to put this all into a zip and make sure all the references in the labview code still work. I can try if you would like but I do not need help explicitly with my vi, I am more looking for direction on how to collect data continuously, but only start saving the data at a specific time from a trigger.

Thanks for the help!

[ultrawhale]

Mcduff,

Yes, you are correct. Sorry, I should have been more explicit, I am only interested in synchronizing the start of data acquisition at the moment, and not synchronizing the data. So the different timing from the clocks of the two different DAQs is not an issue for me thankfully. Thanks for the feedback!

[Bob_Schor]

Let's think about this as though we were using a State Machine with two States (there will really be more, but this is just a "Thinking Out Loud") -- Monitor, where we collect Temp @ 60 Hz and Volts at 2500 Hz, and Collect, where we Collect 3" = 180 samples from Temp, 3" = 7500 samples from Volts, start them both at the same time, and save them to a file.

In the Monitor State, we want to "monitor" the data, which I'll take means "Plot it to show it to the Experimenter".  As a result of our Monitoring, we may see (or the Data may "present") a condition that makes us want to switch to the Collect State (where we may, or may not, care about seeing the data).

Consider the following scheme -- you set the Temp A/D to run Continuous Samples at 60 Hz, collecting 6 samples at a time, and you set the Volts A/D to run Continuous Samples at 2500 Hz, collecting 250 samples at a time.  Suppose, further, that you start these two A/D Tasks in synchrony (say by using a Trigger signal from a TTL input).  We've just solved the "synchrony" problem.  But what about the two States?

[Hmm -- not sure the State Machine metaphor is going to last, but never mind ...]

We've got an Acquire loop that runs both Channels, spitting out data 10 times a second.  If we are Monitoring, we "look at" the data (perhaps plotting it on a Chart, though we may want to decimate or "block average" the Volts signal since we don't really want to see 2500 points whizzing by every second).  Once we reach the condition (it could be the User presses a button, or you analyze the incoming data and decide "We Crossed Threshold!") to switch, you start saving those data packets (possibly also displaying them) until you've saved 30 = 3", then back to Monitoring.

There, that wasn't so difficult.  I assume you've been warned against using the Dreaded DAQ Assistant (and its Evil Twin, the Dynamic Data Wire) to do the DAQ work, right?  If not, go read this NI Document and start using "real" DAQmx functions and real wires.

The key step (which came to me as I was writing this -- you can probably tell exactly where) is that you start the acquisitions "in synch" and keep them in synch, keeping the A/D going continuously and working within the 0.1" windows it gives you.  Better learn about Producer/Consumer Design Pattern, if you don't know it already -- it's what will let you walk (collect) and chew gum (make decisions, plot, save) at the same time.

Bob Schor

[ultrawhale]

Bob,

Thanks for advice.

Unfortunately, I have been using the DAQ assistant and dynamic data wire (I was unaware there was another option). I will read over your link and try switching to the "real" DAQ version. I also already have a producer/consumer setup to handle the code collecting all the data and being able to process all the user interface buttons simultaneously.

My main question is how to start the saving of the system. If I understand you correctly, you are suggesting having the slow and high speed spit out its information every .1", which makes sense as they will then be synchronized for data output even though they have different collection frequencies. I understand the idea of the collect and the acquire states and switching between the two. Do we start the collection state by sending a trigger to synchronize the collection for the monitoring state (presumably during the initialization stage of the code, such that the monitoring is synchronized the entire time the code is running), and then are you suggesting to use another trigger to start the acquire/save state? I am not sure if there is a good function to save data. Currently I am using the "Write to measurement file", but now I fear that this may be too limited (similar to the DAQ assistant versus "real" daq). Do you have a suggestion for a better save function or method? The most important timing for the experiment is that we start saving the data from the low and high speed at precisely when the TTL trigger is sent. A TTL trigger is generated when the user presses a button (Inject on the front panel) and sent to various equipment in the lab to begin the experiment. I need the data to save when the equipment starts running. Hopefully I can answer these questions myself in my research about the "real" daq. I appreciate all the information, it has been an immense help already!

[Bob_Schor · Accepted solution]

I'm only going to comment on "precisely when the TTL Trigger is turned on", which corresponds to a User Button press (so how "precise" can that be?).  One nice thing about having the data in sync every 0.1 second is that you can guarantee that the data are in sync every 0.1 second, i.e. when the "Start" signal comes in, you start saving at the next "sync" point, and continue until you've saved 30 (0.1" * 30 = 3.0") of them.

So there is one more "synchronization" to perform.  The User presses a Front Panel button, which you can handle immediately with an Event Loop.  But you want to send a TTL Pulse and start the saving at the same time.  I suggested that you start saving at the next "Sampling Interval" of 0.1 seconds.  Well, you can also send out the TTL Pulse at the same time!  Your "imprecise" time is When Exactly Was The Button Pressed?, and I'd argue that knowing this to the nearest 100msec is good enough.  But you can use LabVIEW and its DAQ devices to ensure that the A/D and the TTL Outputs are precisely timed (to the nearest Hardware Clock Cycle, certainly measured in microseconds, or smaller), so your data stay synchronized.

Bob Schor

[ultrawhale]

Ah, okay. That makes sense. Thanks for all the help!