Logging Analog Inputs Continuously (Clipping)

[Kbaker4]

Hardware:

(1) NI CDaq-9174 USB Chassis

(2) NI 9234 Analog Input Modules

(1) NI 9402 Digital Input Module

Goal/Requirements:

To read analog inputs continuously only while digital input goes 'high'

Problem:

Time stamp in log file prooves that the logging isn't continuous. It appears the first 0.6 seconds of each second is recording, I imagine the other 0.4 is being used to write to measurement? I can not use SignalExpress VI for this application since logging needs to be triggered by a high digital input.

File is attached! Thanks all !!!

[johnsold]

It appears that you have set the sample rate to 1000 samples per second and the number of samples to read to 1000.  Some simple math will show that it takes 1 second to get that much data.

Who knows when that digital Read executes! It may run before or after the Waveform Read.  Why not just extract the appropriate data point from the waveforms?

You only read the digital input one time per second so it is not clear how that meets the stated Goal/Requirements.

It might make more sense to read continuously and only save the data while the digital input is high. Simply discard the other data.

Lynn

[Kbaker4]

It might make more sense to read continuously and only save the data while the digital input is high. Simply discard the other data.

This is exactly what I'd like it to do. I have no clue what you mean by extracting the appropriate datapoint from the waveforms or how to implement it.

Are you  implying the that the read VI should be outside of the while loop? would this constantly read?

[johnsold]

No.  If the Read VI was outside the loop it would only be read one time until the program stopped and was started again.

You have two DAQmx Read VIs connected to the same task ID wire, so they are reading from the same data source.  The 1 Line 1 Point read generates a single boolean.  I do not have DAQmx available so I am not sure which line from the port it might read. The 1 Chan N Sample Waveform read obtains 1000 samples at 1000 samples per second each time it is callled.  Again, I am not sure which line is read. Maybe all of them since it generates a 2D array of booleans.  Because the two read VIs have no data dependency, you have no way of knowing which one will execute first or whether they will execute in the same order on different iterations.  Because they both are using the same task, the cannot both run at the same.  As a result the single point read will either occur just before or just after the 1000 samples of the waveform read.  I wonder whether the single point read throws an error since you are acquiring continuously.

If the waveform contains 1000 samples for each of the 8 lines in the port, then ALL the digital data is there. Extracting the equivalent of the Digital Input Status simply requires using Index Array on the 2D boolean array. You now can look at the status of that line at each millisecond and that will allow you to log the data you want.

With continuous acquisition and gating the data after acquisition, you no longer need the Start Task and Stop Task VIs in the analog input code.

Lynn

[Kbaker4]

The weird thing is, I have the analog portion working exactly the way I want it to, and the digital working the way I want it to in two separate VIs, but when I bring them together in the same VI (not connected yet just to see if they can work in the same VI), about 10 seconds after running, i get an error to increase buffer size. Doesn't make sense why I don't get this when they are separated from eachother in their own VIs

[johnsold]

Exactly what error code are you getting? Usually a Buffer overflow error is a result of data not being read as fast as it is acquired. Sometimes file writes can take a long time, but ten seconds seems brief for getting to the point where file reallocations would become an issue.

What values are you using for the Physical Channel 2 and 3? The default values are identical.  Running that way would probably generate a Resource reserved error on one of the tasks.

Lynn

[Kbaker4]

I was able to figure out what my problem was... the digital input was not being read continuously and I needed a start/stop task for each while loop iteration ... This fixed the problem and I get the VI to do exactly what I hoped for...

I'm trying to add one more piece of functionality... should be rather simple but I think I'm overlooking something: For every event (everytime the digital input goes high) I'd like the data to go to a new file... I can't use the new_file input to the write to measurement since on every iteration it see's true and creates a new file on EACH iteration rather than when the input changes from high to low... im thinking a pulse train would work triggered by the case structure input but not sure how to do this.... 

[Kbaker4]

Here's the program:

[johnsold · Accepted solution]

To detect changes in the digital input you need to compare the current value to the previous one. The simplest way to do this is to wire the output of the Digital Read to a shift register. The the Boolean Implies function will tell you when a transition has taken place.  See the middle part of the image below. If you interchange the True and False cases of the case structures, you would not need the Invert function.  Look at the help file for information on what the Implies function does.

You also need to change the wiring of the Filename input to the Write to Measurement FIle.vi so that the name is automaticlly changed.  Depending on what you want the naming system to be, this might be simple or rather complicated.

Lynn

[Kbaker4]

This is a great response... I was able to solve the problem by using a Boolean positive edge trigger I found... it seems to work absolutely fine on the development machine. My problem is when I create an installer, the signal that appears on the analog input graphs are very random and show that the accelerometers I am reading are experiencing 10 G's which isn't possible since they are stationary and should be showing a flat line under the 10mv/G spec... I get spikes of information at the left of the graph repeatedly, nothing even close to what I was experiencing on the development machine... any info would be much appreciated!!