Instrument Control (GPIB, Serial, VISA, IVI)
LabVIEW main loop slowdown with GPIB in asynchronous loop executing at 3-second rate
I've been programming LabVIEW, with GPIB, for over 15 years, and trying to debug this problem for the last 3 years. I've come to believe it is a deeply LabVIEW-caused issue, except that its manifestation is definitely GPIB-linked. I have a lot of information regarding this matter, but, for openers, I'll just lay out the problem scenario and hope for expert correction of my perspective.
The problem is observed while running a large subVI in a section of the larger application. There is a front panel chart display that shows the time in milliseconds for each iteration of the main loop. It should show about 50 ms (execution time + waitms of 25 ms), and it does, at first. But as it continues to run, blips start appearing on the chart at about 3-sec intervals (not coincidentally, I assume, this is also the GPIB communication interval). After a week of running, the blips rise to about 200 ms. After the third week running, the blips are likely to be in the 600-ms range, and performance is beginning to suffer.
The solution immediately available to the user is to briefly exit and then re-enter the subVI, which levels the chart display, and all is ready for another round of increasing execution time for the main loop. OK, something is being reset, I think to myself. Some memory is released, references are closed (so handles are being returned for reuse by Windows)...maybe I have a memory leak. But the profiler shows no such thing (at least that I can see). I found some NI documentation of a problem with tunnels at loop borders generating data copies with every iteration! Eeek! I changed all my big wire tunnels to the recommended shift registers--no difference. I tried may things...
A new observation changed my approach: no blips appear over more than a week when the GPIB communication does not take place! This option occurs naturally if, in an earlier setup section of the application, a particular one of the GPIB devices is tagged as "Not Present". Debugging is still very difficult, though. After a user-initiated modification is made to allow the activation and deactivation of GPIB to/from the device in question, I can "reset" the chart simply by unchecking the "talk" box and then rechecking it!!!
A little technical background may be in order at this point. Besides the big main loop, there are 4 additional while loops on the diagram--all running asynchronously. One loop checks for alarm I/O (daq or parallel port), another handles certain buttons' states, etc.--small jobs. One handles GPIB communications with an environmental chamber's controller--this one is my problem child GPIB device. There is only one other GPIB device on the buss per set of test hardware: an HP power supply. If all 4 test hardwares are being used, there would be 4 power supplies on the buss besides the chamber controller, which, itself, may be not used, depending on test requirements. Now in this chamber GPIB loop is a case structure operated by the front panel checkbox in which is located the GPIB communication subVI which queries the chamber controller for about a dozen parameters, one per query, every 3 seconds. Distilling my main points of confusion:
How does anything going on in one asynchronous loop affect the iteration time of another asynchronous loop when neither loop has to wait for anything from the other loop?
How does breifly stopping GPIB comm in one loop cause the other loop to speed up, and then not slow down again right away when the GPIB comm is re-started?
I'd appreciate any discussion of this matter. I've been all over the internet looking for clues. Recently, my company has let our SSPs lapse, so I don't have the tech support connection I've been used to, but I don't think it would do me any good anyway, since I don't have an easily/quickly reproducible problem that can be emailed to them. 
My best guess is I've wired myself into a corner made up of an unlikely confluence of subtle LabVIEW shortcomings. I hope instead that it's MY fault entirely, because then it can be fixed.
My best guess is I've wired myself into a corner made up of an unlikely confluence of subtle LabVIEW shortcomings. I hope instead that it's MY fault entirely, because then it can be fixed.
