Error -1073807342 - (Hex 0xBFFF0012) Invalid resource reference specified. Parsing error

[PabloMG]

Hi!

I have developed a LabView program which goes through a few nested loops in order to perform the characterization of one device. The program randomly generates an error -1073807342 after reading the state of the alarms (the ER, EC and CC registers) of a BERT (Anritsu MP2101A) by means of the attached VI.

All my instruments are connected to my computer through a GPIB-to-USB adapter (NI GPIB-USB-HS+).

Any help would be highly appreciated.

Thanks!

[Bob_Schor]

You have a VISA Error:  VISA:  (Hex 0xBFFF0012) Invalid resource reference specified. Parsing error.

Thank you for attaching the VI (possibly) causing this Error.  However, if the Error message is correct, it suggests that the Resource Reference (carried on the wire whose input is "VISA Resource Name") is not valid, which points to VIs that call this VI.

If you need further help on this problem, please do the following:

• Identify (or create) the single folder that contains all of the VIs that you have created in support of this Project.  If it includes a LabVIEW Project File, so much the better.
• Compress this folder, creating a .zip file.
• Attach the .zip file.

Your code has a few peculiarities that I recommend you change.  You should verify some of the assumptions I'm going to make against the Manual from the Instrument Manufacturer.

• Since all of your functions (correctly) use the Error Line, you do not need (and should not use) a Sequence Structure.  Removing it (and getting rid of the unnecessary 50 ms "Wait" functions between VISA operations, assuming you have set VISA up correctly) will make your code cleaner without impairing its functioning.
  • I assume you set VISA up to use Termination Characters.  How many characters do you expect in response to the :SENSe:MEASure:EALarm:STATe? command?  (I recommend you write out the command as a single string to make it easier for Humans to read it.)
  • I don't have the manual for this device.  What can you tell me about the expected Response to this particular command?  Specifically, does the device "echo" the command, then add on additional characters reflecting the requested Response?  Might the size of the total message exceed 200 bytes?
  • When I use VISA to talk to devices that return data (usually at most 30-40 characters), I always request an "excess" of characters.  Since I like Binary, I ask for 1024 characters -- many other knowledgable VISA users ask for 1000 (binary "round numbers" vs decimal round numbers).
• If you feel that you must use an in-line "Wait" (which, again, I'm 99.44% sure you don't need), since you are using LabVIEW 2018, you should be able to use the "stall" VIM to attach to the Error Line and give yourself a "Wait" between functions.

I look forward to seeing the entire Project.

Bob Schor

[PabloMG]

Hi, Bob.

Thanks for your detailed reply.

I would like to remark that the whole program runs fine for certain time (which can vary from minutes to hours) until this error suddenly happens. The program is based on a state machine and it is used to check all the working conditions of one device that I am characterizing. There are a few loops which have been created by linking the different states of the state machine. The program works correctly for a random time, going through all the states until the error -1073807342 occurs. The state in which the VI attached to my first message is located has been already correctly executed tens or even hundreds of times before the failure happens.

Please let me add my notes on your comments:

• Since all of your functions (correctly) use the Error Line, you do not need (and should not use) a Sequence Structure.  Removing it (and getting rid of the unnecessary 50 ms "Wait" functions between VISA operations, assuming you have set VISA up correctly) will make your code cleaner without impairing its functioning.I am used to do things with sequences. It is true that is does not make sense because the error line it is also a sequencer, but sometimes I put a few things within the same frame of the sequence so that they are executed in parallel. In this particular case, I am not doing that, so I will remove the sequence.
• I assume you set VISA up to use Termination Characters.  How many characters do you expect in response to the :SENSe:MEASure:EALarm:STATe? command?  (I recommend you write out the command as a single string to make it easier for Humans to read it.The command :SENSe:MEASure:EALarm:STATe? returns 1 byte (0: measurement finished; 1: during measurement). I have put two times this VI in a sequence, one to read the channel 1 of the BERT and the other to read the channel 2. There is a delay of 30ms between both readings. Once both have returned  0, then I use a different VI to read the content of the ER (error rate), EC (error count) and CC (transmitted bits) of the BERT for each channel.I have used a "string concat" to build the command because if I need a VI with a similar command, then I just change the part of the string that needs to be changed. I could do the same of course if I had used a single string, but it looks cleaner to me in this way. I can change it, no problem.
• I don't have the manual for this device.  What can you tell me about the expected Response to this particular command?  Specifically, does the device "echo" the command, then add on additional characters reflecting the requested Response?  Might the size of the total message exceed 200 bytes?I am not at the office right now, so I cannot check whether the device echos the command. I do not think so. Also, I do not think the response is longer than 200 bytes
• If you feel that you must use an in-line "Wait" (which, again, I'm 99.44% sure you don't need), since you are using LabVIEW 2018, you should be able to use the "stall" VIM to attach to the Error Line and give yourself a "Wait" between functions.I will check this once I am back in the office.
• I look forward to seeing the entire Project.The policies of the company I work for do not allow me to share the full project in a public forum. Is there any way to do this privately?

Once again, I would like to thank you for your detailed response.

Pablo

[Bob_Schor]

Ah, thank you for the detailed responses.  After hearing your comments, I'm beginning to wonder if you are running into hardware problems.  [We "software guys" tend to blame the hardware, and the "hardware guys" blame the software -- in my experience, 95% percent of the problems turn out to be software (even including the code that I write, I'm sorry to say ...].

I have seen situations when VISA devices appear to "go off line" or otherwise stop communicating, often for hard-to-understand reasons.  Sometimes it seems to involve the communication path (are there network switches involved, such as taking RS-232 signals through a concentrator that sends them via TCP/IP to your PC, where you use VISA to connect to the TCP port), other times it might be a "loose wire" or "bad connector" somewhere.

Are you using the Error Line everywhere you can, and trapping errors and reporting them through an Error Handler?  Do you know where in your code the error occurs?  Is there a VISA Read associated with it?  Can you try to add Error-correcting code (such as trying to clear the VISA port, reissue the command, and see what happens)?

Is your code fully documented?  Does every VI you wrote have, at a minimum, a Description that lists every Front Panel Input and Output, describing the name, type, and brief purpose of the connection?  A 2-3 sentence header saying what the VI is designed to do is also helpful, particularly if some else needs to look at your code.

Bob Schor

[PabloMG]

Hi, Bob.

I have exchanged my BERT and executed the program. It has been running for like 3h now without any issue.

You can see below a screenshot of the state where the VIs which generate the error message are located (sequence on the bottom):

I have placed 6 probes and set the stop condition to "error" to capture the error as soon as it happens (the VIs attached to my first message are the ones placed before the probes 3 and 4).

Regarding the VIs of the program, they are not really documented. I only put comments where I do things that are no "easy to understand", otherwise I do not put comments (maybe it is a bad habit, I agree...).

I have to clean the delays, as you suggested, and delete the sequences where they are not really needed.

I will let you know whether the program fails again.

Thanks for your time!

Pablo

[Bob_Schor]

Working from home on my (not huge) laptop, I can't see any detail in your picture, so I can't make any further suggestions without seeing the actual VIs.

Bob Schor

[PabloMG]

Hi, Bob.

Yesterday I exchanged the BERT and everything is running smoothly since then. It seems like the issue was caused by an error in the communication with the device.

Thanks a lot for your time and your support

Pablo