How to debug DAQ VIs (problem with data)

[davey31415]

I am trying to debug (and understand) the attached VI.  I’m not asking anyone to analyze/debug it, since it is far more than an example; I am new to these forums and feel like asking such a thing would be inappropriate.

I would like advice on how to debug it.  I am also going to describe my problem to see if the cause may be obvious to someone.

The outputs of the "Angle Calc" sub-vi are fed into a state machine.  The state machine actuates outputs to move a motor and measures changing angles.  It first moves up/down, then left/right.  The attached VI is called by a top-level VI and the front panel is not usually open.  For some reason, when the front panel is opened, it behaves differently when it is called.  The behavior only changes for the right/left movements.

Here's where I'm hoping someone can point out some better debugging methods for me.

I have been using the Express Write to LVM File VI and the Convert to Dynamic Data function to write acquired data to text files for analysis after the acquisition has completed.  Are there better methods recommended for doing this?  I wish I could run through the code while recording the execution and then step through a playback of it!

 As for the specific problem I am having...

In the "Right Find Stall" case, the signal wired from the "Angle Calc" VI (array size 100) is connected to a Max/Min Array function.  When I log the data coming from the Min/Max function, I see an alternation between valid data and 0 (i.e. 12.2, 0, 13.3, 0, 14.0, 0, 14.5, 0...).  When I log the data being fed into the Min/Max function I do not see 0s. 

A guess of mine is that the array is empty and therefore no data is logged but Min/Max returns a 0 (not sure why this would happen).  I also have no idea why this would ALWAYS happen with the front panel opened.  I have seen the effect with the front panel closed, but never to the same degree; usually just a seemingly random zero or two but not a pattern of every other point...

Thanks all,

Dave

[davey31415]

I'm still looking for better ways to debug a DAQ application but I do have a bit of progress in this case...

It seems if I decrease my sampling rate that I do not get the scans of zeros.  I thought if I was not sampling data from the card fast enough that I would receive an error- can anyone shed some light onto this?

[kehander]

Well, the fact that you more frequently see the problem when the front panel is open might imply that there is a race condition somewhere. The necessity of having to update the front panel would slow down the VI's execution just enough to make the error recurr more frequently. Decreasing the sampling rate of the card would probably speed up the VI's execution and cause the problem's incidence to decrease.

I imagine it might depend on how the output matrix of Angle_Calc is being created. Are you using local variables somewhere in there?

As for the matter of writing output files, if you only need to write the data after acquisition is complete, why not just use Write to Spreadsheet File? (I'm not a big fan of the Express VIs; when their flexibility is not needed, they seem to be needlessly large and complex.)

By the way, are you familiar with the "Highlight Execution" function? It is not terribly helpful for race conditions (since Highlight Execution also greatly slows down the execution speed), but it might point you in the right direction.

Message Edited by kehander on 10-12-2006 12:44 PM

Message Edited by kehander on 10-12-2006 12:47 PM

[davey31415]

Angle_calc receives array controls in and passes array indicators out.  It performs a trig function and a bit of multiplication. 

I'll check out the Write to Spreadsheet File VI, haven't used it in the past.  If it will allow me to write text out that'll be enough reason for me to stop using the Express VI.

I've used Execution Highlighting and stepping before but with the data acquisition by the time the application makes it around to the next read the DAQ card has sampled a ton of data and the data coming in is no longer useful (a different state should be active by then).

I do think the problem is related to the computer slowing down with the front panel open.  I've logged the 'backlog' number of the Read function and found that the number in there is greater than 0 much more often when the VI's front panel is open and that I've seen relations between the 0s that I discussed earlier and the backlog going above 0 (usually the scan after a non-0 backlog seems to be a problem).

I need to familiarize myself with the DAQ basics, the buffer, backlog, and relation to sampling rate, etc.

In a simple VI I just wrote, I noticed that if I increased the sampling rate high enough, data being acquired into a chart cuts-out on a regular basis; instead of a smooth line, I see small dashes or dots of data (spaces in between).  I don't understand this- I would expect data to be lost but not "no data" to be read in.  I think understanding what is happening here would be helpful.

[Abhinav T]

Dave,

Here is a Knowledge Base article about buffers and how you can control them in DAQmx;

Buffer Allocation for NI-DAQmx

This article gives you an overview of what you want to know, the specific device you are using has more information in its manual. The issue you are noticing where you are trying increase the sampling rate and losing data might be due to the sampling rate limit of the DAQ device. I would like to know little more about your application:

- What DAQ card are you using?
- What are you using to perform the acquisition? (DAQ Assistant / Test Panels / DAQmx bare bones code)
- Do you have any error handilng in the code?

As a strating point to solve your problem with the DAQ vis I would try to use one of the example VIs under Help >> Find Examples and build off of them.

Thanks,

Abhinav T
Applications Engineer
National Instruments

[davey31415]

Thanks abhinav,

The details you asked for are provided in my second post, https://forums.ni.com/t5/LabVIEW/Problems-with-buffered-reads-buffers/m-p/427513#M210195.  I believe I went a bit overboard since noone replied to it (had a few other topics in there too).

I believe not having the error handling in the acquisition loop is what causes me to get 'no data' from the AI Read function.  From what I can tell, if AI Read returns an error that is not handled and is called again, it seems to return no data on the call following the error.  Additional calls works as expected.  When I try to read the KB article I see "Error, you are not authorized to view this document."

Thanks,

Dave

Message Edited by davey31415 on 10-16-2006 02:10 PM