Error -1074118635 occurred at niDMM Fetch Multi Point.vi

[AIC]

Hi,

I'm getting the above error message when performing a continuous reading (DC volts) using an NI-4065 board. The rest of the error message reads as:

Possible reason(s):

Buffer overwrite error!

There was no more space in the buffer when new data from the device was written.

Try increasing the buffer size or slowing down the acquisition rate.

I'm new to LV programming and I'm having trouble resolving this error. My program consists of a 'while' loop around the 'niDMM Fetch Multi Point.vi' with a delay timer to regulate the rate at which data points are acquired. When I set a short delay time, say 0.6s, the error does not occur with the program running for nearly two hours (>10000 data points). However, when I set a long delay time, say 60.0s, the program crashes with above error after 80mins (80 data points).

What buffer is this error referring to? Why is it filled with fewer data points when I select a long delay time?

NI Spy returned the following information when the 'niDMM_FetchMultiPoint' function failed:

Function returned: 0xBFFA4015

Buffer over-write error!

There wowing down the acquisition rate.

It might be me but that last sentence doesn't seem to make sense.

Any help would be appreciated.

Thanks.

AIC.

[JonBowers]

Hi AIC,

I agree that the NI Spy message doen't make any sense!

The actual error that was reported is generaly found when you are not reading data back fast enough. Samples from the 4065 are continously transfered to an area of PC memory of fixed size. When you call the read function the dirver takes values from this area in memory and passes them back to LabVIEW. What seems to be happening is that the card is filling up this area of memory before any samples are returned to LabVIEW. Because this memory is fixed size it generates an error when there is not more space to put samples in. You need to either increase the size of the buffer, read more samples each time or read more frequently.

if you post you code the I can have a look at it and see which is the best option.

Regards

Jon B
Applciations Engineer
NI UK & Ireland

[AIC]

Hi Jon,

Thanks for replying. In fact I had already managed to figure this out for myself (after posting the request for help) - niDMM Fetch Multi Point.vi calls a DLL which presumably contains the buffer that is being filled - there is no obvious way of increasing its size.

This does imply that if you are reading one data point every minute that you are in fact reading old data (i.e. > 1 min old) - I'm not sure I understand why NI would set things up that way.

Anyway, I've now modified my code so that it reads data from the card as fast as possible (~0.2s at 6 1/2 digits) then simply throws away the data points in between those that I want to keep.

Thanks.

AIC

[J_Bray]

AIC,

The DMM is setup to acquire data--up to the total number of points--at a constant rate based on the internal clock speed.  At 6.5 digits, each sample will take 200ms so a new point will be available in the software buffer on that interval.  If you want to read data on a slower interval you have a couple of options in addition to throwing the excess data away:

1) Replace Initiate-Fetch with NI-DMM Read Multi Point.  When using the Initiate-Fetch model, the data acquisition starts when Initiate is called and continues until all points are fetched or in the continuous case, until the user calls Abort, re-initiates, or closes the session.  Since the data is acquired every 200 ms, the software buffer can fill up quickly.  To eleviate this, do not call Initiate and instead replace the software-timed Fetch call with NI-DMM Read.  Read calls Initiate-Fetch under the hood but this will guarantee that only n points are available for each read--where n is the Total Number of Samples from NI-DMM Configure Multi-Point.  These points will be current--ie acquired when Read is called--again 1 point per 200 ms.  The software buffer will no longer be filled with invalid samples.

2) Change the aperture time to match the interval on which you wish to acquire samples.  6.5 digits implies a constant hardware-timed acquisition of 1 point per 200 ms--5 samples/second.  To stretch this time out, you can set the aperture time attribute using a property node to match whatever interval you are interested in.  For example, to acquire a sample every 3 seconds, set the Aperture Time to 3.0.  Now when you call Fetch only 1 point will be available every 3 seconds so it will be "new" or current data.  There is an upper bound on the Aperture Time attribute so depending on how slowly you wish to fetch this may not solve your problem.  Also, you cannot wait 3 seconds, acquire 10 points at a rate of 1 point / 200 ms, and then wait 3 seconds, etc.  This solution will space each point acquired out by the Aperture Time value.

Also, the buffer size can be expanded up to 16 MB-- ~4e6 samples on the 4065 -- by setting the Buffer Size attribute (DMM-->MultiPoint Acquisition-->Advanced-->Buffer Size). 

Hope this helps to clear up some of the issues you are experiencing and from what I understand, I think option 1 will work best for you.  Please let me know if you have any further questions or if any of the above is unclear.

Thanks.

[Giulio Prod3]

Hi. I've the sam problem but using ni DMM Read Multipoint just.

This buffer over write error appear after 30 mins, or 6 hours or 2 days, so I can't know if the problem is over, for evrery change I do.

Also I try to  set buffer size, until 16Mb (maximum buffer size for NI PXI-4065 DMM slot).

How can I resolve this issue? What can I try too?

For others informations I have to read continous voltage DC values from a photovoltaic complex system, about 30 channels, and only one AC channel.

12 of these work with a DC voltage range 0-50mV, the others DC channels with a voltage range of 20-200V.

The AC channel have to read a 5-20 mV voltage.

Thanks.

[Giulio Prod3]

p.s.: I put a 10 seconds time constant to temporize my while loop

[Brandon_G.]

Hi Giulio,

Can you post your code?  Also, can you try running Cont Acq & Chart Multiple Samples.vi in the Example Finder and see if the error occurs then?

Thanks!

Brandon G

[Giulio Prod3]

Hi, thank you for your answer.

In the attachment there is the code "ikube 2.1.vi". In this moment our PXI is  in national Instruments customer care for testing, So now I can't try your help vi.

[Brandon_G.]

Hey Giulio,

I am going to try to reproduce the issue on our end here.  I had a few questions that should help us get us going...

1. What switch card are you using?

2. What version of DMM are you running?

3. I noticed that your code looks very similar to our example, to niSwitch DMM Switch Handshaking.vi.  In your code however you are using niDMM Read Multipoint instead of niDMM Fetch Multipoint.  Was there a reason you used Read instead of Fetch?

I hope to have feedback for you later this week and will let you know what I find then.

Thanks!

Brandon G

[Brandon_G.]

Hey Giulio,

I ran a test over 2.5 days and was not able to reproduce the error on my system.  I assumed you were running a 2527 Switch as this was the default topology in your pull down menu on your front panel.  Although it does not appear to have made a difference in my testing, I would suggest calling the niDMM Read Multipoint before calling niSwitch Initiate Scan. This way we can ensure that when the Switch sends out the first trigger at niSwitch Initiate Scan, it will be received by the DMM because the DMM has been set up beforehand.  If you look at the NI Switch DMM Switch Handshaking.vi in the Example Finder, you will notice that the DMM is initiated first before the Switch.

You may also consider updating your driver if you haven't already to 3.0.5 in case there have been any improvements relating to this issue.  3.0.5 is the version I ran for the test on my end.  Please let me know if you run into any problems after upgrading and swapping the positions of the two VIs.

Thanks Giulio!

Brandon G