error -200010 during hardware timed single point analog input

[Peter_B]

Hi folks,

I am operating a control loop in LabVIEW using a timed loop that is H/W triggered with the the ai (analog input) sample clock on my NI PCI-6014 DAQ card.

The loop works OK unless I choose to case out the "DAQmx Read (Analog DBL 1Chan 1Samp).vi" for > 5 seconds.  If I do that I receive error -200010.  There are times when I don't need to read the analog input (and I'd rather not read ai if I don't have in order to improve loop efficiency).  This error shouldn't occur because as per the NI-DAQmx help file, "If you set sample mode to hardware timed single point, NI-DAQmx does not create a buffer. ".  I don't care if samples are discarded, when I decide to perform a read I only ever want to read the latest single point.

You can repeat the error for yourself by running the attached vi and holding down "Disable AI" for more than 5 seconds.

My loop rate =100Hz.

I have tried setting the following properties to no avail:

DAQmxRead.RelativeTo=MostRecentSample
DAQmxRead.OverwriteMode=OverwiteUnreadSamples

I have utilised the method and code documented/suggested by NI here :Application Case 6 - Hardware-Timed Simultaneously Updated I/O Using the Timed Loop

This method is also documented in the LV DAQmx help file under the topic "LabVIEW example for hardware-timed simultaneously updated I/O using the Timed Loop".

Find attached my vi (in LV v8.5)

regards
Peter

Message Edited by Peter_B on 04-23-2008 12:22 AM

[Peter_B]

I am updating the attached vis and including screen shots.  I have come across another problem that is much more of a show stopper. 

At random instances, the timed loop will begin to run late continuously and hang.  Can anyone tell me why?

thanks

[Brooks_C]

Hello Peter_B,

I've looked over your VI, and I'm not sure that hardware timed single point acquisition is best for your application.  The reason you see error -200010 is because you aren't reading the hardware timed point before the next point is acquired.  This is a helpful error for this type of acquisition because it lets you know if you're missing samples.  However, in your case you've said that you don't care if you miss points, so then I would suggest using either software timed single point acquisition or a buffered acquisition where you throw out all of the data you acquire except for the most recent point.  Either of these methods would have a similar software timing delay to what you're currently doing, but would avoid buffer overflow issues.  Another option would be to continually run the DAQmx Read and then use your button to control what you do with the data you receive--discard it or use it otherwise.  Then you would be able to avoid the error by continually reading and still ignore points in software.

If there is another reason you're trying to use hardware timed single point acquisition then it would be helpful to know more about your application (maybe you're using a real-time operating system).  However, from what you've mentioned thus far I would take one of the approaches I mentioned above.  My guess is that you may have chosen "Hardware timed single point" acquisition because hardware timed indicates that the data may be more accurate or consistent.  While it’s true that your samples will be consistently taken on each sample clock edge, since you’re deciding which samples to read by using a front panel button you inherently introduce software timing/delay into your system.  If this is an unintentional decision then it would be helpful if you can describe what you mean by "it doesn't matter if I miss samples" and more about the sampling needs of your system.

I hope this helps, and have a great day!

[Peter_B]

Hi Brooks,
thank you for checking out my question.

My application is a closed loop control system running at 100Hz.  The OS is not real time, however, in comparison to a S/W timed loop (which I have used up until now) I have noticed the folllowing benefits when using the Single Point H/W Timed acquisition method

1. The Jitter is much less.
2.  I can set the H/W sample clock to 100Hz (with dt=1 clk cycle), whereas the S/W sample clock has to be 1kHz (with dt=10 clk cycles).  This seems to reduce CPU load.  My theory as to why is that a H/W interrupt at 100Hz is less taxing than a S/W one at 1kHz where 90% of those S/W interrupts are not even acted upon.

What I will do is to continuously read the analog input (using Single Point H/W timing) to avoid getting error -200010.  As doing it that way far outweighs the disadvantages of using S/W timed in my case. Just as a point of note, you said "The reason you see error -200010 is because you aren't reading the hardware timed point before the next point is acquired."   If that was true then holding down the "Disable AI" button for even 10ms (=1/100Hz) (c.f. 5 seconds) should cause the error because there is supposedly no buffer in single point H/W timed.  Anyway that is academic now given my intention to continuously read the data.

As you may have noticed my prior post detailed another problem which is more of a show stopper, random in nature (but suitably frequent).  The timed loop will often begin to run late continuously and hang.  Are you or is anybody else able to repeat that problem ?  Be sure to download the latest vis I attached in that post (Hardware timed single point analog input v1.11.zip).  The FP is here Hardware timed single point analog input Front Panel1.png and BD here Hardware timed single point analog input BD panorama1.png

Thank you again .

Regards
Peter


Message Edited by Peter_B on 04-24-2008 06:31 PM

[Brooks_C]

Hello Peter,

I cannot run your code directly b/c I don't have hardware configured like you do.  I've made an example VI that just does the acquisition using a buffered acquisition at 100Hz that only continually reads, but only updates the graph with the points that you specify.  You can compare the points you're reading with all of the data by comparing the graph inside and outside of the case structure.  This should yield a nearly identical sampling timing and avoid the time out errors you're receiving.

If this VI doesn't do what you're looking for it would be helpful if you could post a simplified VI that includes the controls you want and only needs a single board to execute, that way I can try out your code to see how you want your update to work.

I hope this helps, and have a great weekend!

[Peter_B]

Hi Brooks,

Thank you again for your reply. 

As I wrote in my last reply I have chosen to stick with H/W timed single point acquisition for the reasons I outlined.  The final problem I am trying to solve doesn't occur when using S/W timed, but that is an insufficient reason for me to use S/W timed option for now.  The H/W timed option has advantages that I outlined.

I have updated my vi so that the DAQ device is specified on the FP.  You must specify it in FOUR controls at the bottom LHS of the FP.  I only use one DAQ device (dev2 on my PC), not multiple as you suspected.  All you need is a device with one AO, one AI plus an AI sample clock.  I am using a PCI-6014, but there are plenty of other cards you could use.

I look forard to you or someone else tryig out my VI and being able to repeat the problem whereby the Timed loop grinds to a halt.

BTW I am having a great weekend thanks.  The sunshine is out for the first time in over a week, the temperature is a lovely 24degC (75 degF).  I am now off to our local leash free park with my 2 y.o. son and our two Labrador dogs.  In the suburban parts of Sydney (where I live) you are only allowed dogs off their leash in certain areas.  At the leash free parks they do plenty of running and socialising with other dogs.

regards
Peter

[Brooks_C]

Hello Peter,

That sounds like a fantastic way to spend the weekend!  I'm a dog lover as well, and I've been considering getting a dog of my own.  I reall enjoy going to the off-leash dog parks around here with friends (and their dogs).

Down to business... I should have looked at your VI closer to begin with and realized it was just a single device.  I've since gotten it to successfully run on both my PCI-6251 and PCI-6220.  I've spent the last 30 minutes or so running your VI, and I haven't been able to reproduce either of the errors you've described--they work great!

That being said, my concern would be with the VI is stressing your computer's processor which could cause the loop to run late.  We can test this theory by reducing the timed loop rate--if it works for you with a slower loop rate then this is likely the problem.  If it still throwing these errors with very slow rates then I would look at the computers CPU usage with the Windows Process Manager (ctrl+alt+del and then choose task manager and look at the system performance tab).

I was able to make the VI exit because of the "loop has run late more than 200 times" condition by opening about a dozen web browsers during the VI's execution, but anything short of that and I couldn't get more than one or 2 late iterations in half an hour.  When I did cause the loop to run late by stressing the CPU I still didn't observe the error message you've seen.

Do you have another (possibly faster) machine you can test your VI on?  Also, if you have a lot of processor intensive programs running on your computer you should try chosing those and then running the VI.  If we find that the issue is that your computer can't handle these rates then I think that the buffered acquisition may provide an acceptable solution, however I understand your reasoning for wanting to use hardware timed single-point so we can cross that bridge if it comes to that.

Cheers,

[Peter_B]

Hi Brooks,

Thank you again for looking into my problem.   I think you have hit the nail on the head as they say.  When I reduce the loop rate below 60Hz I don't see the problem and when I increase the loop rate, the problem happens more frequently.  The PC I'm using is about 4 years old (Dell Optiplex GX240) and I am about to get a new PC at work, however thankfully as it turned out I came across another solution to the problem (rather than reducing the loop rate which would be too slow for my application).

All I have to do is to increase the loop rate from 100Hz to 200Hz and increase the loop period (dt) from 1 to 2.  Using that configuration it ran last night continuously for 9 hours before I manually stopped it !!  Why exactly that works I'm not sure, the main thing is that it does work in my case.  FWIW, when I was using the same setup in a S/W triggered timed loop, the rate was 1000Hz and dt=10 and that never exhibited the problem.

So now everything is working wonderfully and once again I'd like to thank you for your persistence in helping me solve my problems.

All the best with any dog(s) you decide to get in the future 🙂

regards
Peter

[Brooks_C]

Hello Peter,

I'm glad to hear that you're up and running!  As far as why it works for you with dt = 2 and the rate = 200Hz, but not for dt = 1 and rate = 100Hz is beyond me.  I would suspect that it has something to do with what else you're computer had going on during the two tests.  If you didn't explicitly have any other things running when the two tests were done then its possible that Windows had something running in the background.

If you can still consistantly get this program to run with one pair of settings and not the other I'm not sure what to say as both work on my machine.  There may be some underlying algorithm that allocates resources more efficiently when dt is > 1, but if you're happy with this explination and the VIs results I think its probably best to end this search here.

If you have any further questions or are still concerned with the VIs operation feel free to post back, otherwise I wish you the best of luck in future applications.

Cheers,

[Peter_B]

Hi folks,

I am reviving this thread because something I thought I could put up with is now proving to be a problem.

To save you re-reading this entire thread, I will summarise the situation. 

If I fail to perform a single point H/W Timed AI read often enough I receive error -200010 (hence the title of this thread).  Attached is the example so that you can repeat the error for yourself.

Despite the fact that the AI input is read in a timed loop running at 100Hz, every now and then when MS windows wants full control of the CPU for more than about 2.5 seconds during that period there seems to be NO way that I am able to read the AI to prevent this error happening (I basically didn't bank on this happening which is why I thought I could live with the problem).  Once the error happens I have to exit the timed loop then restart it just to stop and restart the AI task (thats just how things work with Timed Loops using a Sample Clock as the timing source).  That essentially terminates the test and is invalidates all test results up to that point.

This error shouldn't occur because as per the NI-DAQmx help file, "If you set sample mode to hardware timed single point, NI-DAQmx does not create a buffer. ".  I don't care if samples are discarded, when I decide to perform a read I only ever want to read the latest single point.

Is there some setting I have overlooked that will prevent error -200010 from ocurring in a single point H/W timed acquisition ?

regards