Incorrect waveform signal display

[rbrown83]

Hello everyone -

We are using two channels of an NI 9237 to acquire strain data from two different load cells, and a third channel to acquire a 5V TTL square waveform signal from a BnC port.  We realize that the NI 9237 cannot recieve digital input, so we have a small circuit built and are recieving signals from the BnC port using an RJ-50 adapter. 

When we connect the BnC ouput to an oscilloscope, it displays a 5V TTL signal.  When we try to view the signal using LabVIEW and the Measurement & Automation Explorer, we recieve a square wave signal with an amplitude of 12.5 mV.  We have a waveform indicator on our front panel, and also have a numeric indicator that lists the magnitude of the square wave.  Our problem is this: when we run the program, the numeric indicator oscillates between 12.5 mV and 0 mV while the magnitude of the square wave signal (as shown by the waveform indicator) is 12.5 mV.  The waveform indicator does not show that the square wave signal dips down to 0 mV at all while the magnitude of the square wave is 12.5 mV. 

We tried putting a constant 12.5 mV signal into the system, and the same problem still occured.  I have attached a copy of our code (I'm not sure how useful it will be), but if anybody has any suggestions as to why this might be occuring, we'd be really grateful!

Thanks in advance.

[tbob]

Why are you converting a waveform to dynamic data then converting that to a DBL?  Why not use Get Waveform Components to get the data points into a 1D array of DBL?  You can build a 2D array with index 0 and 1 instead of converting and combining and converting again.  (or you can build a 1D array of waveforms instead) You can queue the 2D array of DBL (or 1D array of wfm) and then not have to use the conversion in the consumer loop, except for the Write to Meas File Express VI.  But that would be only one conversion instead of 6.  You may be losing something in the conversions.

[Dennis_Knutson]

All 3 channels are also configured as strain gages. That can't be good for the scaling.

[rbrown83]

Thanks for your quick responses.  We used a voltage divider to decrease the 5V TTL signal to 1 mV to make it fit within the range of a strain gauge.  We have gotten rid of some of the conversions in our program, and used the Get Waveform Component VI as you suggested. 

Unfortunately we are still recieving values of zero when we input a steady non-zero signal into the third channel.  I have attached a spreadsheet containing the waveform magnitudes from our last run.  We need to recieve correct values from the signal in order to use it as a threshold for data acquisition triggering in the consumer loop.  We placed a probe on the wire leading to the waveform chart while the program was running, and we did not see the signal dip down to zero at any time; however, when we checked the spreadsheet, it did show several zero values. 

Thanks again!

[Dennis_Knutson]

Not sure why you would use a voltage divider instead of simply changing your code.

All that you have to do is remove the 5V channel from the existing DAQmx Create Channel function and and a second one set for a voltage measurement. Wire the task out of the first to the task in of the second. Then you can specify the input limits, connection type (ie diff, rse, etc)

[tbob]

Your data file contains the very first sample of each DAQ read.  If the first sample is sometimes 0 and the rest of the samples is non-zero, you might not see this on a waveform chart because the first sample is on the left edge.  Try using an index other than 0.  Why the first sample anyway?  Wouldn't you rather see all the data.  Use your build array with the entire Y output, not just the first sample.  This will produce a 2D array.  You will get a better picture of what is happening.  For some reason, the DAQ may be missing the first sample.

[rbrown83]

Thanks for your response.  Unfortunately, it doesn't seem as though the NI 9237 can receive input voltage signals.  In the past, we have tried several times to use the DAQ Create Channel VI set to Analog Voltage input for the NI 9237, and we receive errors saying that the input type is not supported by our device.  The NI 9237 is dedicated mainly to strain measurements.  This is why we felt it necessary to use a voltage divider, in order to bring the input voltage signal within a range that would be seen with a strain gauge. 

[rbrown83]

Hi tbob,

Thanks for your suggestions.  We only need to choose one sample because we only need one single scalar to give us a True/False value to determine which case is executed for each loop.   After reading your post, we have tried changing the index from 0 to other random values (i.e. 1, 6, 25, 184), and the same problem still occured.  Even when we input a steady signal of magnitude 0.00178 (with a small amount of noise), the data file still shows values of 0 interspersed with values of 0.00178, regardless of which index we specified. 

Following your suggestion, we then tried creating a 2D array of the entire Y output and creating a constant array of 0.0005 (our threshold value) with which to compare it, but this created an array of Boolean values after using the comparison function, and our case structure wouldn't accept this as input.  In any case, we only need one single value to put into the case structure. 

[tbob]

I'm not sure why your card is giving intermittent data.  Have you set minimum and maximum values in the first DAQmx function?  Set min to 0 and max to slightly higher than the max voltage you would expect (like 0.002).  This will increase the output resolution.  Maybe you have a bad connection, sometimes its there and sometimes it isn't.

If you are looking for just one boolean out of the array, you can use Index Array.  If you want to see if at least one of the booleans is True, use the OR Array Elements function found in the Boolean palette.  This will give a boolean output.

[rbrown83]

Hi tbob,

Thanks so much for all your help, we really appreciate it.  We tried setting the min and max values as you suggested, but the same problem still occurred.

We added some code to our program that removes all the zero's from the Y output, and writes all the non-zero data to an array.  We then selected a couple of random elements from the new non-zero array to feed into the comparison, and tried decreasing our threshold.  When written to a spreadsheet, the non-zero data array shows all non-zero values, as does the numeric indicator on the front panel.  However, our Boolean indicator (Greather Than...?) on the front panel still periodically flashes off and on, even though the numbers in the non-zero data array are all larger than our threshold value.  I have posted our code for you to see.  Do you know why this might be happening?

We originally thought that the Boolean indicator flashed off with each iteration of the while loop, but after adding an indicator to display the number of while loop iterations, we see that the while loop iterates much too fast for this to be the case.