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:<img src="file:///C:/DOCUME%7E1/peterba/LOCALS%7E1/Temp/moz-screenshot-2.jpg" alt=""> DAQmxRead.RelativeTo=MostRecentSampleDAQmxRead.OverwriteMode=OverwiteUnreadSamplesI have utilised the method and code documented/suggested by NI <a href="http://zone.ni.com/devzone/cda/tut/p/id/3215#toc9" target="_blank">here</a> :<a href="http://zone.ni.com/devzone/cda/tut/p/id/3215#toc9" target="_blank">Application Case 6 -
Hardware-Timed Simultaneously Updated I/O Using the Timed Loop</a> This
method is also documented in the LV DAQmx help file under the topic <a href="C:%5CProgram%20Files%5CNational%20Instruments%5CNI-DAQ%5CDocs%5Cmxcncpts.chm::/hwtimedIOtimedLoop.html" target="_blank">"</a><a href="C:%5CProgram%20Files%5CNational%20Instruments%5CNI-DAQ%5CDocs%5Cmxcncpts.chm::/hwtimedIOtimedLoop.html" target="_blank">LabVIEW example for
hardware-timed simultaneously updated I/O using the Timed Loop</a><a href="C:%5CProgram%20Files%5CNational%20Instruments%5CNI-DAQ%5CDocs%5Cmxcncpts.chm::/hwtimedIOtimedLoop.html" target="_blank">".</a> Find
attached my vi (in LV v8.5)regardsPeterMessage Edited by Peter_B on 04-23-2008 12:22 AM


Hardware timed single point analog input.zip:
http://forums.ni.com/attachments/ni/170/318261/1/Hardware timed single point analog input.zip

[Peter_B]

I am updating the attached vis and including screen shots.&nbsp; I have come across another problem that is much more of a show stopper.&nbsp; At random instances, the timed loop will begin to run late continuously and hang.&nbsp; Can anyone tell me why?thanks


Hardware timed single point analog input v1.11.zip:
http://forums.ni.com/attachments/ni/170/318617/1/Hardware timed single point analog input v1.11.zip


Hardware timed single point analog input Front Panel1.png:
http://forums.ni.com/attachments/ni/170/318617/2/Hardware timed single point analog input Front Panel1.png


Hardware timed single point analog input BD panorama1.png:
http://forums.ni.com/attachments/ni/170/318617/3/Hardware timed single point analog input BD panorama1.png

[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.&nbsp; The reason you see error -200010 is because you aren't reading the hardware timed point before the next point is acquired.&nbsp; This is a helpful error for this type of acquisition because it lets you know if you're missing samples.&nbsp; 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.&nbsp; Either of these methods would have a similar software timing delay to what you're currently doing, but would avoid buffer overflow issues.&nbsp; 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.&nbsp; 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).&nbsp; However, from what you've mentioned thus far I would take one of the approaches I mentioned above.&nbsp; 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.&nbsp; 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.&nbsp; 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.&nbsp; 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 method1. The Jitter is much less.2.&nbsp; 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).&nbsp; This seems to reduce CPU load.&nbsp; 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.&nbsp; 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."&nbsp;&nbsp; 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.&nbsp; 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).&nbsp; The timed loop will often begin to run late continuously and hang.&nbsp; Are you or is anybody else able to repeat that problem ?&nbsp; Be sure to download the latest vis I attached in that post (<a href="../../attachments/ni/170/318617/1/Hardware%20timed%20single%20point%20analog%20input%20v1.11.zip" target="_blank"> Hardware timed single point analog input v1.11.zip</a> ).&nbsp; The FP is here <a href="../../attachments/ni/170/318617/2/Hardware%20timed%20single%20point%20analog%20input%20Front%20Panel1.png" target="_blank"> Hardware timed single point analog input Front Panel1.png</a> and BD here <a href="../../attachments/ni/170/318617/3/Hardware%20timed%20single%20point%20analog%20input%20BD%20panorama1.png" target="_blank"> Hardware timed single point analog input BD panorama1.png</a> Thank you again .RegardsPeterMessage Edited by Peter_B on 04-24-2008 06:31 PM

[Brooks_C]

Hello Peter,

&nbsp;

I cannot run your code directly b/c I don't have hardware configured like you do.&nbsp; 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.&nbsp; You can compare the points you're reading with all of the data by comparing the graph inside and outside of the case structure.&nbsp; This should yield a nearly identical sampling timing and avoid the time out errors you're receiving.

&nbsp;

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.

&nbsp;

I hope this helps, and have a great weekend!


Not Timed Loop.vi:
http://forums.ni.com/attachments/ni/170/319184/1/Not Timed Loop.vi

[Peter_B]

Hi Brooks, Thank you again for your reply.&nbsp; As I wrote in my last reply I have chosen to stick with H/W timed single point acquisition for the reasons I outlined.&nbsp; 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.&nbsp; 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.&nbsp; You must specify it in FOUR controls at the bottom LHS of the FP.&nbsp; I only use one DAQ device (dev2 on my PC), not multiple as you suspected.&nbsp; All you need is a device with one AO, one AI plus an AI sample clock.&nbsp; 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.&nbsp; The sunshine is out for the first time in over a week, the temperature is a lovely 24degC (75 degF).&nbsp; I am now off to our local leash free park with my 2 y.o. son and our two Labrador dogs.&nbsp; In the suburban parts of Sydney (where I live) you are only allowed dogs off their leash in certain areas.&nbsp; At the leash free parks they do plenty of running and socialising with other dogs.regardsPeter


Hardware timed single point analog input v1.2.zip:
http://forums.ni.com/attachments/ni/170/319198/1/Hardware timed single point analog input v1.2.zip

[Brooks_C]

Hello Peter,

&nbsp;

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

&nbsp;

Down to business... I should have looked at your VI closer to begin with and realized it was just a single device.&nbsp; I've since gotten it to successfully run on both my PCI-6251 and PCI-6220.&nbsp; 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!

&nbsp;

That being said, my concern would be with the VI is stressing your computer's processor which could&nbsp;cause the loop to run late.&nbsp; 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.&nbsp; 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).

&nbsp;

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.&nbsp; When I did cause the loop to run late by stressing the&nbsp;CPU I still didn't observe the error message you've seen.

&nbsp;

Do you have another (possibly faster) machine you can test your&nbsp;VI on?&nbsp; Also, if you have a lot of processor intensive programs running on your computer you&nbsp;should try chosing those and then running the&nbsp;VI.&nbsp; 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.

&nbsp;

Cheers,

[Peter_B]

Hi Brooks, Thank you again for looking into my problem.&nbsp;&nbsp; I think you have hit the nail on the head as they say.&nbsp; 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.&nbsp; 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.&nbsp; Using that configuration it ran last night continuously for 9 hours before I manually stopped it !!&nbsp; Why exactly that works I'm not sure, the main thing is that it does work in my case.&nbsp; 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 :)regardsPeter

[Brooks_C]

Hello Peter,
&nbsp;
I'm glad to hear that you're up and running!&nbsp; 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.&nbsp; I would suspect that it has something to do with what else you're computer had going on during the two tests.&nbsp; 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.
&nbsp;
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.&nbsp; There may be some underlying algorithm that allocates resources more efficiently when dt is &gt; 1, but if you're happy with this explination and the VIs results I think its probably best to end this search here.
&nbsp;
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.
&nbsp;
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.&nbsp; 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).&nbsp; 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).&nbsp; 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).&nbsp; 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. ".&nbsp; 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


Timed Loop Investigations1.zip:
http://forums.ni.com/attachments/ni/170/346947/1/Timed Loop Investigations1.zip

[Brooks_C]

Hello Peter,

&nbsp;

I've played with your VI more and I'm still not able to reproduce this error.&nbsp; I've done some looking around and I haven't see this as a reported issue with earlier versions of DAQmx, however, I am using the current version and it may be worth upgrading your system to <a href="http://joule.ni.com/nidu/cds/view/p/id/965/lang/en" target="_blank"> NI-DAQmx 8.7.1</a>&nbsp;if you aren't already using it.

&nbsp;

Another possible solution (more of a work around) would be to modify the case structure that control's the "disable AI" feature in your program.&nbsp; You could move this case structure to be just around your "Analog Input" indicator--then the DAQmx Read would run every loop iteration and the indicator would only update points in the same manner.&nbsp; Essentially you'd observe the same behavior, but it may help avoid this error.

&nbsp;

I'll do some more looking around to see if this was a bug that's been fixed, because as far as I can tell, the overflow error is not being thrown on my computer for hardware timed single point acquisitions.

&nbsp;

On an unrelated note, I did end up getting a puppy shortly after my last post--we've frequented the off leash park ever since.&nbsp; Her name is Abby and she is awesome!

&nbsp;

<img src="Loading Image...">

&nbsp;

Cheers!Message Edited by Brooks_C on 08-07-2008 03:59 PM


Abby.GIF:
http://forums.ni.com/attachments/ni/170/347683/1/Abby.GIF

[Peter_B]

My local NI App'n Eng. tried out the vis on two separate systems, but couldn't repeat the problem either !!I am now wondering if it could either bei) some setting in MAX that is different on my setup. ORii) something different about the architecture of the PCI-6014 and PCI-6036 DAQ cards compared to the type you and my local App'n Eng. are using (what are you using ?) ORiii) some persistent parameter in both of my PCI DAQ card's EEPROMs which I am not configuring with the vis but is different between my cards (6014 and 6036) and other cards you and and my local App'n Eng. are usingregards

[Brooks_C]

Hello Peter,
I believe that Abby is a Vizsla mix--though I can't figure out what she's mixed with.&nbsp; She?s about 40 lbs. at 8 months, and she'll probably top out around 50...
I had been using a PCI-6251, but this morning I checked out a PCI-6014 and still haven't been able to reproduce this issue.&nbsp; Let?s compare the rest of our setup.
1.&nbsp; Operating system:&nbsp; Windows XP Service Pack 2.2.&nbsp; LabVIEW Version:&nbsp; 8.5.13.&nbsp; DAQmx Version:&nbsp; 8.7.14.&nbsp; Hardware:&nbsp; Successfully tested PCI-6251 and&nbsp;PCI-6014
My computer is a dual core Dell desktop, but from your testing (single and quad core) it would be surprising if that had anything to do with it.
If you'd like to generate a technical report in the Measurement and Automation Explorer (MAX) that would allow for a more complete comparison of the systems.&nbsp; You can do this by opening MAX and selecting File» Create Report.&nbsp; Select "Technical Report" and follow the steps in the wizard.&nbsp; This will generate a zip file with detailed information about the driver versions and hardware you're using.
A possible, though unlikely, explanation is a corrupted DAQmx driver (especially unlikely since you've confirmed it on two computers--unless you used the same installation file).&nbsp; It may be worth running a repair on the DAQmx Driver and/or LabVIEW, or you can install <a href="http://joule.ni.com/nidu/cds/view/p/id/1087/lang/en" target="_blank"> DAQmx 8.7.2</a> which was released in the past day or two.&nbsp; If you did use the same installation source that would make this a more likely fix.
If you're uncomfortable posting this zip file on the forums, with your permission, I can look up your email address and send you an email that&nbsp;you can reply to with the file.
Let me know what you'd like to do.
Cheers,

[Peter_B]

Hi Brooks, I certainly appreciate your thorough approach in helping me out with this problem.I am attaching the zip file.&nbsp; There wasn't any proprietry info in it.&nbsp; The PCI-6014 was resident, I had just taken the PCI-6036 out but some of its details still show in the ni_max_report.html file within ni_support.zipThe installed S/W on my my quad core PC is nearly identical to yours. (I have an f2 after my DAQmx version)1.&nbsp; Operating system:&nbsp; Windows XP Service Pack 2.2.&nbsp; LabVIEW Version:&nbsp; 8.5.13.&nbsp; DAQmx Version:&nbsp; 8.7.1f24.&nbsp; Hardware:&nbsp; Unsuccessfully tested both a PCI-6035 and a PCI-60145. 3.25 GB RAMThe installed S/W on my my single core PC is as follows1.&nbsp; Operating system:&nbsp; Windows 2000 5.00.2195 Service Pack 4.
2.&nbsp; LabVIEW Version:&nbsp; 8.5.1
3.&nbsp; DAQmx Version:&nbsp; 8.5.0f3
4.&nbsp; Hardware:&nbsp; Unsuccessfully tested PCI-60145. 3.25 GB RAMI'll wait to hear back from you befor I install and try out NiDAQmx 8.7.2 as I am nearing a delivery stage of a major project and I'd rather not make too many changes to the system unless warranted (I'll upgrade if you think it stands a reasonable chance).&nbsp; It's worth pointing out that my single core PC only has DAQmx Version:&nbsp; 8.5.0f3 so that would have come from a different installation to to that on my newer PC.<img src="file:///C:/Documents%20and%20Settings/peterba/My%20Documents/Downloads/IMG_2764_Simba_and_Nessa.jpg" alt=""> I tried uploading a photo of my dogs but my server wouldn't let me, I'll try again later.regards&nbsp;


ni_support_PBs_quad_core_PC.zip:
http://forums.ni.com/attachments/ni/170/348021/1/ni_support_PBs_quad_core_PC.zip


ni_support_PBs_single_core_PC.zip:
http://forums.ni.com/attachments/ni/170/348021/2/ni_support_PBs_single_core_PC.zip

[Peter_B]

Hi Brooks,My server got its act together. Meet Simba and Nessa. Our two 3.5 year old Golden Labradors<img src="Loading Image..."> Simba has <a target="_blank" href="http://en.wikipedia.org/wiki/Canine_discoid_lupus_erythematosus">Canine DLE </a>on his nose which has proven difficult to get into remission, apart from that they are pretty healthy and active.&nbsp; They are always inside when anyone is home. re. the problem at hand, I had another idea to try out.&nbsp; I have a DAQ card which has never been calibrated by our local calibration agency (NI approved).&nbsp; Just in case they are putting our DAQ cards into a certain state that causes this error I will give this other DAQ card a try.&nbsp; I do know that once in the past they calibrated a DAQ card for us and it came back and its behaviour changed in some way (I can't recall the details) but they had written something to the DAQ's EEPROM to give it a different/bad response.&nbsp; So I had to send it back and they fixed it up (IIRC it was a case of them not understanding exactly how to use the NI S/W and H/W setup program to calibrate the card).If I'm keen I'll do that tomorrow, else I'll do it on Monday.&nbsp; Either way if you only work Mon-Fri I should have an answer for you before you reply again.regards

[Peter_B]

:smileyhappy::smileyhappy:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; EUREKA !!!!&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; :smileyhappy::smileyhappy:I just tried a PCI-6251 we have at work which has never been sent out for calibration and I DON'T get error -200010 !!!!So what settings in the other DAQ cards EEPROMS are being mushed up when they are being sent out for cal ???&nbsp; (This confirmed behaviour is exhibited on THREE of our DAQ cards, two PCI-6014s and a PCI-6036 - all of which have been calibrated locally ). As I wrote above I have seen something like this in the past, I'll have to dig up the info as to exactly how they fixed it.This is a problem that now needs to be worked out between our local NI office and the local Calibration Agency we use.&nbsp; Brooks, can you possibly suggest where they start looking ?&nbsp; Cna I download the EEPROM config data on my error prone PCI-DAQ cards to compare it with the contents of a known good DAQ card ?regards

[Peter_B]

BTW if I disable AI for
&gt;40seconds (at the default CLK rate of 200Hz) I do however get another error (-200714) , whereas error -200010
would always come after 2.5 seconds at the CLK rate I am using.&nbsp; This
new error is understandable and it is not a problem at all for me because it takes so long to happen.&nbsp;
FWIW both errors (-200010 and -200714) happen sooner if I up the clk
rate. But I don't need to up the CLK rate &gt;200Hz for my application.regards

[Peter_B]

Some more thought I had on this.&nbsp; The PCI-601 and PCI-6036 both only have a FIFO input buffer of 512 bytes. which if being filled up would do so in about 2.5 ***@200Hz [1]The PCI-6251 has a 4096 byte FIFO input buffer which should fill up in about 20 seconds at 200Hz, instead it appears not to fill up until about 40seconds.&nbsp; Once again these numbers would really only make sense if I wasn't doing single point H/W timed AI DAQ as the FIFO buffer should never fill up.So in summary, the task now at hand is to elucidate the difference between (my PCI-6014s and PCI-6036) and (your PCI-6014/6251 and my PCI-6251)[1] Just a slight clarification, I have been saying my CLK rate is 200Hz,
which is true but my timed loop rate is actually only 100Hz because I have set dt=2 (see prior entries in
this thread to understand why).regards

[Brooks_C]

Accidentally duplicated my post... please disregard this one.Message Edited by Brooks_C on 08-08-2008 01:02 PM

[Peter_B]

Hi Brooks,
Great shot of your new dog. What breed is she?&nbsp; Its good you're taking
her to leash free parks at a young age. Doggy social skills are best
learnt young.I already had the latest version of NI-DAQmx installed (8.7.1f2).My reason for casing out the DAQmx AI read is to simulate the real situation where the timed loop is halted for a couple of seconds when windows decides to hog the CPU for whatever reason.&nbsp; I wouldn't be simulating the problem if I just cased out the indicator.I was hoping you could reproduce the error as I am able to every time.&nbsp; Because the error happens for me on two different PCs , the remaining thing in common is the DAQ card or the dev environment (LV 8.5.1) &amp; NI-DAQmx drivers. I am using a PCI-6014.&nbsp; I'll try to get my hands on another PCI card to see if the problem is still there&nbsp;&nbsp;&nbsp; I tried using a simulated DAQ card, but the timed loop didn't automatically start the task as its supposed to (probably a bug).I'll see if my local NI App Engineer can reproduce the problem.regards

[Peter_B]

Hi Brooks, I have just tried with a PCI-6036 and I still get the same error -200010 when I hold down the Disable AI button for &gt;2.5 seconds.&nbsp; This is now two PCs (one 4 years old, the other a brand new quad core) and two different DAQ cards that it happens for me.regards

[Peter_B]

Hi Brooks, The plot now thickens...Dmitry (an NI Apps Engineer in OZ) has been using a PCI-6221 and he gets the same behaviour as me with my PCI-6251 whereby after 40seconds error -200714 occurs.&nbsp; OK so that observation doesn't&nbsp; explain too much (in relation to error -200010) because of the larger FIFO buffer.&nbsp; Dmitry then got his colleagues in Sydney to repeat the test using a PCI-6014 and a PCI-6036 which proceeded to give error -200010 after just 2.5 seconds.&nbsp; Neither of their cards had been calibrated.&nbsp; THIS MEANS they can repeat my problem !!Now I wonder if you could double check the fact that you "checked out a PCI-6014 and still haven't been able to reproduce this issue" .&nbsp; If that really is the case then it means there is a difference between your setup and our setups in OZ.&nbsp; At least Dmitri can continue trying to find the source of the error in a parallel investigation.Dmitri and I notice that upon first running the&nbsp; vi, it will sometimes hang LabVIEW in the first sub-vi (Initialise DAQmx_distilled_v0.7.3.vi).&nbsp; We circumvent the problem by turning on Highlight Execution for that sub-vi. Once it runs once we can turn off Highlight Execution and it runs fine after that until we close/re-open the vi or (cold?) start the PC.&nbsp; Perhpas that hanging is another symptom of the problem, perhaps it is urelated.&nbsp; I just wanted to mention it to you in case you experienced something similar.Perhaps I am barking up the wrong tree when I suspect EEPROM differences.&nbsp; The best way to progress now would be if I could swap my PCI-6014 card with&nbsp; yours and see what happens !!&nbsp; What do you think we should try now ?I hope it doesn't take you too long to get up to speed with our progress over the weekend.regards

[Brooks_C]

Hello Peter,I had noticed the hang the first time you run the program--since it was corrected as soon as I started troubleshooting with execution highlighting and you hadn't mentioned it I hadn't looked into it.&nbsp; However,&nbsp; I think the issue is that the DAQmx Create Timing Source (Control Loop From Task).vi needs to be called before the timing for the analog output is configured--I've attached a version of the Initialize VI that should work every time since the race condition has been eliminated.&nbsp; I took the brute force approach of configuring all of the AO after the AI task, but I believe you technically only need to call the Start Task on the AO after the Create Timing Source for the AI.I have been able to reproduce this error now, and I believe you've identified the cause of the error (onboard FIFO overflow).&nbsp; I'm not sure how I missed the error in my earlier attempts to reproduce this--I'd tried it several dozen times.&nbsp; I think the problem is that after I disabled the AI for a period of time I never enabled the read again.&nbsp; Without calling a DAQmx Read that error can't be thrown.&nbsp; With that being said, I will be escalating this issue appropriately.&nbsp; I'm not really sure if this is expected behavior or not.&nbsp; The easiest solution would be to make sure you call at least one read before the FIFO fills up, however, in your case, if Windows is really preventing the loop from running for 2 seconds or more the solution may not be as quick.If your system requires you to account for 2 second hangs in the software then you may need to consider using a task timing other than hardware timed single point.&nbsp; From my experimenting it looks like the driver doesn't use DMA (direct memory access) transfers to automatically empty the FIFO with this timing scheme.&nbsp; I will be checking if this is the case, but I'm fairly certain that it is.&nbsp; If you were to use a continuous acquisition then DMA transfers would automatically transfer the data from the DAQ card's onboard FIFO to the computers RAM.&nbsp; You can control the size of the RAM buffer and with a sample rate of 100 Hz you could easily make this FIFO large enough to sustain a 10+ second hang (this buffer can be quite large, you could probably make it 100+ seconds).On the other hand, while Windows is not deterministic and may have occasional blips in loop rate, a 2 second hang is quite substantial compared to anything I've experienced before.&nbsp; It may be worth looking for any applications/software you have installed that may be causing this in the background while your program runs.&nbsp; Your computer's specifications seem more than adequate so there has to be something using all that CPU time.Thank you for your solid troubleshooting efforts.&nbsp; I think we've identified the issue, and I will give you an update when I have more information.Cute dogs!


Initialise DAQmx_distilled_v0.7.3.vi:
http://forums.ni.com/attachments/ni/170/348329/1/Initialise DAQmx_distilled_v0.7.3.vi

[Peter_B]

Hi Brooks,
Thanks again for the progress you made.&nbsp; I tried using DMA as the AI transfer mechanism but error -200734 ensued

" Measurements: Device does not support DMA for the Data
Transfer Mechanism when performing non-buffered acquisitions.Set Data
Transfer Mechanism toProgrammed I/O. "


(refer to updated atttached project).

<a href="mk:@MSITStore:C:%5CProgram%20Files%5CNational%20Instruments%5CNI-DAQ%5Cdocs%5Cmxcncpts.chm::/DataTrans.html" target="_blank">The local DAQmx help file</a>
says that Programmed I/O transfer mechanism is typically used with
Software Timed operations.&nbsp; I guess atypically Programmed I/O is also
used in single point H/W timed acquisition.
" Programmed I/O is a data transfer mechanism in which a buffer is not used and
instead the computer reads and writes directly to the device. Software-timed
(on-demand) operations typically use programmed I/O."

If I try using interrupts error -200845 is thrown asking me to use DMA !!

Clearly in order to use DMA I need to use finite or continuous acquisition mode so that NI-DAQmx creates a buffer in RAM.&nbsp; Would that work OK with my current architeecture ?

Re. windows taking control of the CPU for &gt;2 seconds.&nbsp; It happens
very ocassionally and as you say it is rare. However if it ever happens
I need to deal with it. &nbsp; Here are some times when it happens:
- If the screen saver comes on (which locks the PC) then I have to unlock it
- One tab pane in my application has 6 charts with 15 plots
distributed in those charts and the chart history buffer length is
1440001 points. Switching to that tab after a time of not viewing it
can cause a lengthy redraw (I can probably work around that problem if
necessary by using X-scroll bars on the charts).
- Other times are random and I haven't worked out why, perhaps it
is the resident corporate antivirus S/W or some other service running
in the background



If it turns out that DMA transfer does work for me using finite or
continuous acquisition then that is good, otherwise I might have to
consider purchasing a DAQ card with 4096 FIFO buffer size.

regards


Timed Loop Investigations v0.82.zip:
http://forums.ni.com/attachments/ni/170/348475/1/Timed Loop Investigations v0.82.zip

[Brooks_C]

Hi Peter,&nbsp;Sorry for the delay.&nbsp; I typed up a response yesterday, but apparently I forgot to submit it.&nbsp;&nbsp;From what I've found, this is expected behavior, or at the very least not the intended use for hardware timed single point acquisition.&nbsp; With hardware timed single point acquisition, it is assumed that the user will be reading every single point--the purpose of this acquisition mode is for control loops where you need to read in every single point as soon as you acquire it.&nbsp; In that case you wouldn't run into this issue because you would be continually reading.&nbsp;&nbsp;There are two ways we can approach this issue; select another acquisition mode (probably continuous sampling) or figure out how to reduce your computers load so that it can sustain operation without experiencing 2 second hangs.&nbsp; I will discuss both options, but as I would probably switch to continuous sampling.&nbsp;Continuous Sampling:&nbsp;By changing the acquisition mode to continuous sampling, automatic DMA transfers will transfer data from the DAQ card's FIFO into a FIFO on RAM.&nbsp; Since you can choose the size of this buffer you can make sure that you are able to continually sample without erroring out.&nbsp; This offers a slight benefit over 1 sample (on demand) sampling because continuous sampling will always acquire samples using a hardware clock.&nbsp; Essentially if you run your loop fast enough to read 1 point each loop iteration with continuous sampling it has the same behavior as hardware timed single point.&nbsp; In the cases where your loop runs late the DAQmx read will return more than one sample, but you can index out that array and just get a single point from it (or you could decide to keep them all).&nbsp; The reason buffered acquisition is implemented is so that you can run a hardware timed acquisition reliably on a non-deterministic operating system.&nbsp; By acquiring samples with a hardware clock and buffering the results you can have reliable data even when your system isn't 100% consistent.&nbsp;&nbsp;CPU Load:&nbsp;To avoid the excessive CPU hangs you may be able to remove the strenuous portions of your code.&nbsp; Instead of displaying 15 charts with a history of 1440001 points, you may want to consider reducing the history length and writing your data to a file instead.&nbsp; TDMS files (see example programs) use binary reads and writes so they are quite quick.&nbsp; Another option would be to use the <a href="http://zone.ni.com/reference/en-XX/help/371361E-01/lvprop/pnl_defer_pnl_updts/" target="_blank"> Defer Front Panel Updates Property</a> to reduce the number of redraws.&nbsp; Also, I would recommend changing your computers power save settings to avoid screen saver mode.&nbsp; If your computer goes into power save/screen saver mode while you're acquiring data it isn't all that surprising it had undesirable results.&nbsp;&nbsp;While getting another DAQ card with a 4096 buffer may get you around the issue, I think there are other solutions that don't require new hardware.&nbsp; By utilizing the available functionality of your current hardware and the DAQmx driver you should be able to do what you want.&nbsp;
&nbsp;
Cheers,Message Edited by Brooks_C on 08-13-2008 10:30 AM

[Peter_B]

Hi Brooks,Thanks for the summary of your investigations.&nbsp;My plan is to switch to continuous sampling.&nbsp; I may not have time to do that straight away as there is a need to validate the S/W in its current state, albeit with a list of known deficiencies.&nbsp; After that I'll implement continuous sampling.
&nbsp;I know how to deal with the charts slowing things down.&nbsp; I have actually been pushing the envelope of what I can get away with using my new PC.&nbsp; There is a benefit to having lots of points on the chart (the user can scroll back through many hours of data for the current test without me having to implement a playback (from HDD) function for now), but certainly not worth the hassle of having long redraw times so I am going to experiment with a trade off of length versus redraw times.&nbsp; I already stream the data to disk to post processing. Anyway with continuous sampling the redraw delays shouldn't be a problem.&nbsp; The screensaver is a corporate one that can't be disabled on some PCs (a security feature that locks them after a time of non-use).&nbsp; If that becomes an issue I can deal with that too by taking the PC off the corporate network and having the screen saver disabled.&nbsp;<img src="Loading Image..." border="0" alt="Simba and Nessa havina a bath" title="Simba and Nessa havina a bath" width="500" height="375" align="middle">&nbsp; &nbsp;regardsPeter&nbsp;

[Brooks_C]

Hello Peter,&nbsp;That sounds good.&nbsp; Let me know if there's anything I can help with!&nbsp;Cheers,