same function gathers different number of points in different calls?

[-SK-]

I am running an automated test program, testing moving pistons. The test will extend the piston, and gather position data via some pots, and current data, while its moving. It will then retract the piston, and do the same data gathering. It then does some other tests.The data is written to some files, and is then retrieved for post-test processing later on.

I use the same function for extending and retracting, and I am noticing that the number of data points gathered during the extend is always much less than the number of points gathered during the retract.

This is the 3rd version of function I have used to gather data from the test apparatus, and this issue has stuck with all 3 versions . I have attached the function to this post. The top-level VI is large and contains many lower-level VIs, so I can't include the whole thing. I am using a USB 6008, LV8.5, Daqmx 8.5.

Any ideas why this would run differently each call? 

 Explanation of the function:

The gray box VI with 'NI' is a subvi that communicates with a controller for the tester. It sends the position to move the piston to. In the loop, the daq assistant grabs data from the 6008, and looks at pot values. If the values are close enough together, several times, it stops the loop and the data gathering (the piston has reached the end of its stroke). After the data gathering loop, the rest of the function is for writing data to a file.

NOTE that only the 'true' case inside the while loop matters here, as thats where the problem lies.

PS. sorry the front panel looks like crap, because this is a subvi so its front panel is never seen.

[-SK-]

I should also say that the code in the top VI where this function 'move_actuator' is called is identical for the extend and retract portions, they are just different states in a state machine.

[SMeserve]

Hi SK,

This does seem like a very strange issue.  Have you tried any troubleshooting steps?  You may want to try using breakpoints and Highlight Execution to watch what actually occurs in your code during each of those states.  Also, how many more/fewer points are being acquired?

[Wayne.C · Accepted solution]

-SK-

I would suspect that the culprit is the DAQ Assistant.   I suspect that the first time you call the DAQ Assistant ( this will always be during an extend ) it takes some amount of time to get the task configured and started.  Since the piston is already moving, you then have less time to take samples.   When you go to do the retract the task is already loaded in memory and can begin taking samples right away.  You should  get your daqmx task setup and started outside the while loop before you start moving the piston.

[-SK-]

I have been thinking along the lines of what Wayne said.

Can I initialise the Assistant by calling it outside the loop, but with a True constant on the 'stop' input, and then run the rest of the function as normal? Would I not get the error about 'resource is reserved ' or in use or whatever it is?

Stephen : I have tried troubleshooting by stepping through the execution, but I find it doesn't run accurately. Since the function stops recording when a succession of near-identical points are detected (when the piston stops), if I run it in 'highlight execution' mode it will get 5000 points each for retract and extend (assistant is set to 1k buffer size, 5 successive similar points stops the execution). 

I will fool around with setting up the function before the loop, until someone gives more suggestions.

[-SK-]

The problem is fixed! I put a case statement before the data gathering loop that executes on an 'extend' in which I call Daq assistant, and do a bogus sampling of data, then I start the piston moving and start the data gathering loop. I have run it several times and it has returned about 7k points each for extend and retract, which is about what I expect to see for the stroke length I am testing. I will have to see if it works the same for different stroke lengths; I have had issues in the past with random behavior due to different lengths for some reason.

Thanks for the help!

[Wayne.C]

-SK-

Glad to hear that seems to have helped.  This kind of problem is one of the reasons I tend to avoid using the DAQ assistant and instead let my vi programatically control the DAQmx task.  If you are interested in what that DAQ Assistant is really doing, make of copy of it and open up the front panel of the copy.

Starting to wake up now.  It may be necessary to add a trigger to the task to help sychronize the start of movement and start of data acquisition.

Message Edited by Wayne.C on 05-04-2009 08:24 AM