Incorrect waveform signal display

[tbob]

I don't have a DAQ so I can't run your exact code here.  But I removed all the DAQ stuff and replaced it with a random number generator and For Loops to generate a 2D array.  Usually the random numbers are never exactly 0.  I ran the code and the LED was always on.  Random values were always greater than 0.001.  So the logic is working.  I think you have a DAQ problem.  You should use probes to see your DAQ data, especially the third row data, which is what you are sending to the compare function.  Also you can use the highlite execution (the light bulb) to slow down the code to see what is happening.

In your upper right loop, you are testing for equal to zero.  With floating point numbers, you will never get a true case because a 0 might be represented by 0.0000000001, which is not really 0.  The computer cannot accurately represent a floating point number to the nth digit, so there are always some errors.  Insted of using equal to 0, use the Range and Coerce function and set the upper limit to 0.0001 and the lower limit to -0.0001.  This should remove the zeros out.

Tracing the code execution and using probes is you best bet for finding out what is going on.  Sorry I can't help more than this.

[rbrown83]

Thanks for all of your help tbob.  We realized that whenever the numeric indicator showed a zero, it was creating an empty array; we're not sure why the program is creating an empty array.  Have you heard of situations like this before and if so, do you have any suggestions as to why this might be occuring, or how we could eliminate the empty arrays?

Thanks again. 

[tbob]

I don't see how you are getting an empty array.  When I ran your code minus the DAQ stuff, I got a good array of numbers.  Two ways you can get an empty array:  The waveform Y array is empty. or each value of the Y array is exactly 0.  The latter is most unlikley, even a 0 is stored as 0.00000001 or something like that, making the comparison False.  So the array cannot be empty unless the Y value array is empty.  Put a probe on it and look at the array.

You are indexing the 35th element out of the array to display, what happens if you change the index to 0 or 1?  You will have to use probes and execution trace to see what is going on.  When you get some data using those tools, post your findings here.  Also, you can run your vi to capture a waveform.  Then right click on the waveform chart and select Data Operations - Make this value default.  Then save the vi and post it here.  That way I can see the waveform.  Do the same (make this value default) for all indicators so I can see your data.

[rbrown83]

We have attached 3 screenshots of our front panel; pulses.jpg shows the square wave output from our BnC port, low signal.jpg shows the low level signal, and high signal.jpg shows the high signal. 

We found that changing the index from 35 to 0 or 1, or any other random number, had no effect on the performance of the program.  The Boolean indicator still kept periodically flashing on and off. 

We think the main problem is that the screen refresh rate (200 Hz) of square wave signal from our BnC port (the signal coming into the 3rd channel of the 9237)  doesn't match the sampling rate we have set in our program.  We tried to decrease the sampling rate from 20000 Hz to 200 Hz to match the refresh rate, but it didn't have a significant effect on our program.  We also think that the screen refresh rate might not match the internal clock on our DAQ, and that the difference in rates might be causing the empty arrays to form.  From what we've read on other threads in the discussion forum, it looks like LabVIEW might set the empty arrays to values of zero. We set a counter on our program to count the number of zero's that arise while the program is running, but we weren't able to see a steady relationship between the number of producer loop iterations and the number of zero's. 

The problem is that sometimes, our pulse signal will freeze on the low signal, which has a value of zero.  It is important that we keep these values of zero for our data analysis, but that we remove the zero values formed as a result of the empty arrays. 

Another thing we have noticed - when we place the probe on the waveform data coming into the Y input of the Get Waveform Component function, and select the "Table" tab on the Probe window, the program works pretty well perfectly (as odd as this sounds).  Do you know why this might be occuring? 

Thanks!

[rbrown83]

And the last .jpg image

[tbob]

Screen refresh rate will not be the problem.  The program runs and gathers data, and that is completely independent of the screen refresh rate.  If you have a 2D array of waveforms (or even a 2D array of anything), and one array size is shorter than the others, Labview will fill the shorter array with the default value (zero in the case of waveform data or numerics) so that all arrays are of the same length.  You can't have a 2D array where one row has 5 columns and the next row has 3 columns, so Labview fills in columns 4 and 5 of the 2nd row to make it the same length as the first.  If you are using DAQ to capture samples from different sources, you should be getting the same number of samples from each source.  Labview should not have to fill in any data.  Maybe you have a problem with your DAQ and the way it is collecting data.

From your picture, it doesn't look like any data in the third waveform (I am assuming the 3rd waveform is the high signal) is zero.  I don't understand where the zeros are coming from.  There are no zeros in that waveform.

If you are placing a probe and the program starts working, then you have a timing issue.  The first thing I would do is to place a delay in each loop.  Even 0mS delay will do.  Without a delay, the loops will try to run as fast as possible and chew up 100% of the CPU time.  This could cause other functions to not execute properly.  Try a 10mS delay, then try a 1mS delay.  Be sure to put the delays in both while loops.  Always put a delay in a loop to avoid CPU hogging.

[rbrown83]

Hi tbob -

Thanks again for all your suggestions.  We added in a time delay and the program is working pretty well for the time being.  We are now just trying to determine a good trade-off between the sampling rate and the number of samples we acquire per channel.