BFFA2003

[Stewpot]

I have a problem with Error BFFA2003 occuring in DMM Read Multi Point.vi which seems to be associated with a 'time out' on the measurement.  I see that the Maximum Time parameter is set to Auto TL by passing a value of -1.

Can anyone tell me how this 'Auto TL' works as distinct from setting an actual value in ms?

This problem has only just appeared in software that has been working under various issues of LabVIEW (currently 8.5) for mamy years.  Could the problem be a hardware issue?

Stuart Thomas

Pinecone Associates

[ThomasC]

Hi Stuart,

I see you have been talking about this issue with Marcos Kirsch at the following link -

http://forums.ni.com/ni/board/message?board.id=80&message.id=157&requireLogin=False

It's great that you have started a new thread to tackle this issue but are you able to provide answers to the questions he asked?  Just to reitterate these are -

• Are you using triggers?
• Can you use the device from the SFP normally?
• Can you swap the card with another one (if you have it) and see if that works?

It may also be wise to take this oppertunity to make sure you are running the latest version of the driver software, this can be found at the link below.

http://digital.ni.com/softlib.nsf/MainPage?ReadForm&node=132010_US

Regards,

Tom Clark

[Stewpot]

Sorry about using a new thread but I thought I could possibly explain my problem more clearly this way.

We are not using triggers.  The measurement is simply to connect the DMM to a test point on a PCA via an NI switch matrix.  After allowing time for the relay switching to settle, the measurement (resistance) is made using a DMM Control.vi which selects an NIDMM chain comprising niDMM Initialise.vi, niDMM Simple Acqusition.vi, niDMM Close.vi and niDMM Error Message.vi.

The niDMM Simple Acqusition.vi  in the above chain calls another set of niDMM vi's that is completed by an niDMM Read Multi Point.vi, which is the vi that has a parameter identified as 'Maximum Time'.  In this instance the parameter is set as -1 from a constant titled 'Auto TL'.  According to the LabVIEW help text, the niDMM Read Multi Point.vi 'initiates the measurement and waits for the DMM to return a value'.  I assume that the BFFA2003 error message is indicating that the measurement has timed out!  But I am not clear what the Auto TL (-1) parameter value plays in this time out.

Unfortunately the test equipment os on a remote site and so I cannot readily make the swop to a new DMM card.  I will be visiting the siteon Thursday of this week in order to persue the investigation.

My aim before the visit is to get as much understanding of the function of the DMM VIs as I can.

I hope the above is not too rambling and can be understood.

Regards

Stuart Thomas

[Stewpot]

Sorry about using a new thread but I thought I could possibly explain my problem more clearly this way.

We are not using triggers.  The measurement is simply to connect the DMM to a test point on a PCA via an NI switch matrix.  After allowing time for the relay switching to settle, the measurement (resistance) is made using a DMM Control.vi which selects an NIDMM chain comprising niDMM Initialise.vi, niDMM Simple Acqusition.vi, niDMM Close.vi and niDMM Error Message.vi.

The niDMM Simple Acqusition.vi  in the above chain calls another set of niDMM vi's that is completed by an niDMM Read Multi Point.vi, which is the vi that has a parameter identified as 'Maximum Time'.  In this instance the parameter is set as -1 from a constant titled 'Auto TL'.  According to the LabVIEW help text, the niDMM Read Multi Point.vi 'initiates the measurement and waits for the DMM to return a value'.  I assume that the BFFA2003 error message is indicating that the measurement has timed out!  But I am not clear what the Auto TL (-1) parameter value plays in this time out.

Unfortunately the test equipment os on a remote site and so I cannot readily make the swop to a new DMM card.  I will be visiting the siteon Thursday of this week in order to persue the investigation.

My aim before the visit is to get as much understanding of the function of the DMM VIs as I can.

I hope the above is not too rambling and can be understood.

Regards

Stuart Thomas

[Stewpot]

Sorry about the duplicated posting.  I got into some kind of time-out problem

Stuart Thomas

[ThomasC]

Hi,

At the moment I am still unsure as to why you are seeing this error message, usually I would expect to see it when you are missing trigger pulses when attempting to synchronise two devices.  It may help if you include NI-Switch error handling in your VI as detailed in the following link -

http://digital.ni.com/public.nsf/allkb/346FE8423E7911498625684F0055F9AE?OpenDocument

The option TL Auto stands for Time Limit Automatic.   This is where the DMM defines the maximum timeout for the system.  Have you tried setting your own timeout?

Regards,

Tom

[Stewpot]

Tom

 Thanks for the reply

As is often the case in equipment faults, when we arrived at the site the reported DMM fault condition had 'gone away'.  As the visit was also tasked with replacing modules, including the DMM, with re-calibrated units we had to remove the suspect DMM from the rig and replace it with the re-calibrated spare.  We can only know wait for a recurrence if the problem was not simply a faulty unit.  The removed DMM will need to be sent for calibration before we can investigate further.  No doubt we will see more of this problem in the future.

As I said in the above posts, the measurement that was reported as failing was a simple resistance measurement and the 'timeout' function suggested in the BFFA2003 error message pointed to a subVI chain including an NI library VI named ‘niDMM Read Multi Point.vi’ which I understand initiates the measurement and waits for the DMM to return a value.

Regards

Stuart Thomas

[ThomasC]

Hi,

I'm glad to hear your system is working again although obviously the circumstances aren't ideal.  If you reproduce the error again it would be great if you could get in touch with us so that we can take another look into the problem.

Regards,

Thomas Clark

[Hull-1]

I am having a very similar problem.  We're using a PXI-4070 DMM in a RT o/s.  I have created drivers to communicate to the DMM and those appear to be working (including a single read driver that reads 1 sample); however, when I went to create a routine that uses the multi fetch, I repeatedly get this error (-1074126845 "Max time exceeded before operation completed.").

All I want to do is create a dynamic utility to read the DMM multiple times.  I initially tried the multi fetch vi using the default "Maximum Time" (which is -1 I believe, and that is the DMM decides automatically how much time to wait).  This works with 1 sample (even using the multi fetch vi and passing it a value of 1 for the Number to Fetch), but it does not work for 2 or more samples.

I even added detection in my code to look for this error (), and if I see it, then clear it and retry the multi fetch with a manually calculated "Maximum Time" based upon the # of samples to read times 10 (I tried x10, x100, and x1000).  None of these worked and I repeatedly continue to get this error using multi fetch.

Tim