VISA locks up system with lots of timeouts?

[JÞB]

Jason,

Thanks for the clarification.  (the behaviours of these functions really should have better documentation in the help files;) )

back in the LV 6.1 days, I learned to my chagrin, that the VISA Sync and Async calls to multiple GPIB instruments on the same bus behave with vast differences when transfer times approach the TMO value.  "Bugs" seemed to creep from sync calls and appear as TMO errors on subsequent un-related calls to other instruments.   I have maintained my code development practices for that reason although LabVIEW and NI-VISA have both been extensively reworked since those days.

I still work in LV 6.1 for some of my clients and would like to keep common practices between versions of LV so I can easilly upgrade or down rev code without massive code behaviour changes.   

So, what behaviours changed and at what revisions of which NI products?

[JasonSmith]

---

sth wrote:

1. Inside LV, there is a VISA primitive "Set  Buffer Size" that allows setting the input, output or both buffer sizes.  The behavior is different on different platforms (drivers) for the serial port.  Where is this buffer which is getting resized?  In the VISA code, in the kernel/driver code or in LabVIEW.

---

This call gets passed down to the underlying serial driver. Different drivers and operating systems have different behavior here. For example, I believe that Windows will not allow you to resize the buffers smaller than 4096 bytes. I am not personally familiar with the exact behavior on Max OS X.

---

@sth wrote:

2. Given the description and the inefficiencies that you outline, what is the downside of allocating a bunch of threads to LV at least a lot more than any possible number of simultaneous I/O transfers and then do everything synchronous?  The NI utility tops out at 8 threads per execution system, but why not 100?  Even if each thread takes 100 Kbytes (which is a lot), this is still only 10 MB.  This can easily be set by messing with the preferences file which will accept any number.

At the moment I have topped out my system at 8 threads per execution system since that is easy and sort of sanctioned by the LV utility.  But I am more than willing to set it to 100 if that just has a memory tradeoff.   Or rather about 20 which should be more than any conceivable number of I/O calls that I am doing. 

---

Unfortunately I cannot accurately answer this question. My experience is more with the underlying NI-Serial and NI-488.2 driver, and not so much with NI-VISA, or in this case the LabVIEW primitives. I would guess that one problem would be that increasing the number of threads in the execution system would not only impact I/O, but also all other aspects of your application. Having many more threads than you have processing cores could lead to unneeded overhead as the threads would have to do a lot of context switching. Of course this would not be true if they were purely blocking on I/O, but in this case they would be available for any other use as well.

-Jason

[JasonSmith]

---

Jeff Bohrer wrote:

back in the LV 6.1 days, I learned to my chagrin, that the VISA Sync and Async calls to multiple GPIB instruments on the same bus behave with vast differences when transfer times approach the TMO value.  "Bugs" seemed to creep from sync calls and appear as TMO errors on subsequent un-related calls to other instruments.   I have maintained my code development practices for that reason although LabVIEW and NI-VISA have both been extensively reworked since those days.

I still work in LV 6.1 for some of my clients and would like to keep common practices between versions of LV so I can easilly upgrade or down rev code without massive code behaviour changes.   

So, what behaviours changed and at what revisions of which NI products?

---

I am not familiar with the bugs that you mentioned, but that would have also been before I became actively involved with these products. Certainly many improvements have been made to NI-VISA and NI-488.2 since then, but I am unable to list every one of them. I typically consider synchronous transfers to be less error prone because they have a more linear codepath and fewer places to lose track of the status, although both synchronous and asynchronous calls are thoroughly tested and should behave as documented.

I can use my knowledge of NI-488.2 to say that our current NI-488.2 driver is much more reliable than anything that was available in the LabVIEW 6 timeframe. If you continue to have issues with timeout error corruption with the latest versions of NI-488.2 and NI-VISA, I would love to hear about them so that they can be investigated.

-Jason S.

[JasonSmith]

---

sth wrote:

Jul  2 13:03:33 hybridcryomacb ReportCrash[9962]: Formulating crash report for process coreservicesd[9809]

Which tells me my system is seriously FooBar.  At that point the Finder menu bar is gone and the Dock starts to fail.  I still have non-gui access to the system.  Has NI by any chance tested VISA against lots (ie 10,000 or more) async VISA timeouts to check for cleanup?

VISA 4.4.0 & VISA 4.5.0

LabVIEW 8.5.1

Mac OS X 10.5.7 / PPC

---

We seem to have strayed quite a bit from your original question. While we do test timeout conditions, I doubt than it has been tested repeatedly for many hours as you have indicated in your post. A couple questions I would have about your failure:

1. Do you have a crash report that you could send us, so that your crash could be investigated?

2. You mentioned that you experience this problem with no instruments connected. Do you have a VI that you could send us that could reproduce the problem, since no instruments are needed?

Thanks,

Jason S.

[sth]

Jason,

Thanks for the info about the buffers being in the driver and just passed by VISA to them.  The Mac OS X serial driver had some limitations on buffer size as well.

I will see if I can test the performance impact of context  switching.  It will take some thinking to test this and figure out if I am really benchmarking what I think I am.

I am travelling at conferences for the next couple of weeks [not NIWeek ;-( ].  I will try to get back to this when I return, as I have investigated  the problem last week, I was still having problems with that system even when I hooked up actual hardware to it.  Of course the timeouts went away but some of the other error messages remain and I am still looking for underlying causes.

And BTW, the Mac OS X, 488.2 driver has never been horribly reliable.  I have provide many many crash dumps but I can't reproduce it reliably, I am hoping that the next VISA update will fix the nipalk kernel panics.