VISA Read hangs. Get Resetting VI dialog on abort.

[nyc_(is_out_of_here)]

---

@elifino wrote:

Not all of us have the luxury of being able to specify every detail of the environment or the hardware we're using.

---

Yes, but you can mitigate it to the best of your abilities, if you know this is an issue.

And if you don't like NI's VISA, you are certainly welcome to try Agilent's.

[elifino]

According to my tests, Agilent's VISA is even worse for this problem, unfortunately.

But I'd just like to submit that "the competition is even worse" is not a very good defense. Neither is the idea that a trivial software bug can be mitigated with hundreds or soemtimes thousands of dollars worth of hardware, on a client's system that I don't even control. And, as many people pointed out, even really solid hardware can hit this bug occasionally, and when it does, it locks up the entire system.

[nyc_(is_out_of_here)]

---

@elifino wrote:

According to my tests, Agilent's VISA is even worse for this problem, unfortunately.

But I'd just like to submit that "the competition is even worse" is not a very good defense. Neither is the idea that a trivial software bug can be mitigated with hundreds or soemtimes thousands of dollars worth of hardware, on a client's system that I don't even control. And, as many people pointed out, even really solid hardware can hit this bug occasionally, and when it does, it locks up the entire system.

---

You have people using USB to GPIB converters; GPIB extenders; etc.

People with poorly written code.

Frankly I don't know who to believe.

I have never encountered this problem myself.

[George_G]

Once we had identified the EMI as the cause of our troubles, we were eventually able to isolate down to a very simple VI that open, write "*IDN?", read reply, and close.  We were then able to make this VI lock up with our RF source on.  So I submit good, simple code and NI's own hardware (PXI-GPIB) experience the issue.  For a long time the issue was extremely sporatic for us.  Only recently did we uncover the EMI correlation.  I'm not surprised many people never see the bug... it only shows up when the bus is misbehaving and then I bet the misbehavior has to hit at just the right moment.  It is the worst kind of bug to track down.

I also agree that however poorly written the code and however flaky the hardware used, the fatal "resetting VI..." dialog should not appear.  The VISA driver should never get lost in it's own DLL such that user code cannot intervene.

[JÞB]

OK let us set a few things straight.

VISA is not the issue

SPECIFIC IMPLEMENTATION if VISA that comply with the standard are not the issues.

GPIB is not the issue

SPECIFIC impementations that comply with the standard are not the issue.

SO, What is the issue?  PISS-POOR lab design.  That one is on you!  The hardware works to standard and is tested for complance to at least a certain degree of EMI tollerance.  If your lab is finding problems your lab emmisions are higher than the specified tolerance of the standard-  Or, your equipment is busted and needs repair.

Saying that softwware should tolerate operation for out-of-spec environments is just silly.  Next you'll want it to work in a liquid He chamber.  Electrons don't flow at that temp  / enviornment- choose another means to communicate.

[nyc_(is_out_of_here)]

---

@George_G wrote:

Once we had identified the EMI as the cause of our troubles, we were eventually able to isolate down to a very simple VI that open, write "*IDN?", read reply, and close.  We were then able to make this VI lock up with our RF source on.  So I submit good, simple code and NI's own hardware (PXI-GPIB) experience the issue.  For a long time the issue was extremely sporatic for us.  Only recently did we uncover the EMI correlation.  I'm not surprised many people never see the bug... it only shows up when the bus is misbehaving and then I bet the misbehavior has to hit at just the right moment.  It is the worst kind of bug to track down.

I also agree that however poorly written the code and however flaky the hardware used, the fatal "resetting VI..." dialog should not appear.  The VISA driver should never get lost in it's own DLL such that user code cannot intervene.

---

RF source *on*.

EMI correlation and you don't think it is YOUR problem????

Sheesh.

[George_G]

Your replies make you sound like NI groupies.  We've worked around our problems and moved on.  That being said, I do expect low level software to be robust under adverse conditions.  I can think of no excuse for a driver failing to timeout because EMI upset the bus, except priority of resources.  NI must prioritize and I can accept this as low-priority.  But I reject calling it correct behavior of the driver.

[JÞB]

What you observed cannot be called incorrect behavior - Outside the specified operating eviornment there is no defined correct behavior.  I'm not designed to be robust enough to operate on the Moon.  If I function at all in that enviorment it may be as a cloud of evaporated ice.  I Could, however develop suitable technologies that could preserve some core functionality (derated for low G).

 What you propose as "the software should be more robust" would in fact unilaterally extend the specified operating eviornment defining "Requirements for operation in harsh enviornments" by your fiat! That is what I meant be stating your opinion is silly!  You can bring it to the correct body, IEEE 488, and propose a new specification modification but, you can't just define correct behavior based on convieniance to you.

And no, I'm not an NI groupie. I DO appreciate their customer support but, I ride their "issue trackers" just as hard.  In this instance you have a non-issue with VISA. 

[nyc_(is_out_of_here)]

---

@George_G wrote:

Your replies make you sound like NI groupies.  We've worked around our problems and moved on.  That being said, I do expect low level software to be robust under adverse conditions.  I can think of no excuse for a driver failing to timeout because EMI upset the bus, except priority of resources.  NI must prioritize and I can accept this as low-priority.  But I reject calling it correct behavior of the driver.

---

Not groupies.

But your assertion about expecting low level software to be robust under adverse conditions is plain misguided.

The personal computer itself is classified as a class B device by the FCC. There are specific requirements for it and all devices

covered here http://transition.fcc.gov/Bureaus/Engineering_Technology/Documents/bulletins/oet62/oet62rev.pdf

The GPIB card would be classified as peripherals to a Digital Device.

Here is some discussion on USB devices EMI testing put out by Intel. http://www.ti.com/sc/docs/apps/msp/intrface/usb/emitest.pdf

As you can see the conditions for test are NOT "adverse".

[elifino]

You're making it much more complicated than it is.

If you send a query with a 5 second timeout and there's a glitch on the communications line so the response never comes, then the defined correct behavior is for the driver to return control to you after 5 seconds with an error message. But the driver doesn't do that. So there's a bug in the driver. It doesn't work according to its own defined correct behavior.

Standards or not, any real hardware has a nonzero probability of a glitch. You may be able to go 30 years and never see it, or you may be able to reproduce it on demand, depending on what hardware you're forced to work with. But when it happens, the low-level software shouldn't hang. It should error out. Just like the documentation for it says it will.

Nobody's saying the hardware should be able to communicate in absolutely any environment. Nobody's saying the software should be able to survive an arbitrary glitch inside the computer itself. Congratulations, you've beaten the straw man to death. Now can we just have a VISA driver where timeout means timeout?