01-15-2014 09:58 AM
Hello,
I'm developing a subVI in LabVIEW 2012 SP1 32-bit which takes advantage of VISA USB RAW. I currently have VISA 5.4 installed and I'm running Windows 7 64-bit. Essentially, I'm reading interrupt transfers from a USB HID device. Below is a screenshot of my subVI:
Most of the time it works without a hitch, but once in a while I will get the following error:
Error -1073807315 VISA: (Hex 0xBFFF002D) The event queue for the specified type has overflowed. This is usually due to previous events not having been closed.
It always occurs at "VISA Wait on Event". While debugging, I have the front panel of this subVI open so I can see that "error in" is not passing in a previous error. As you can see in the screenshot of my block diagram, there isn't much there and I am in fact closing the event reference when I'm done with them. The only thing I can think of is that the previous Event Queues are not being closed fast enough. It may sound like to workaround it I may need to first check for any open Event Queues.
Does anyone have any other suggestions as to why I am recieveing this error and what I can do to prevent it?
Thanks!
01-16-2014 05:45 PM
How fast are you running your code? It may be that you are executing too fast. In addition it could be that a large number of these events are being generated and so are queuing up faster then you can process them. You could use the VISA Discard Events to clear the buffer after processing each one so that you do not have a backlog of USB Interrupt events. It is very possible that the initial interrupt event continues to generate interrupt events even as you handle the first and that is why the buffer is overflowing. It's just a guess but it is a possibility. See if using the VISA Discard Events vi stops the problem and then see if you can accomplish what you want without recording those interrupts.
01-20-2014 02:18 PM
Thank you for your reply!
Yes, this code can execute many times in succession in some instances of the application it is being used in. Since this subVI is used for generic data retrieval from the HID device, this subVI gets used in a lot of places, sometimes in loops. This subVI is not re-entrant so when it is called many it executes one-at-a-time.
When I initialize the USB RAW VISA session, I set "Maximum Queue Length" to 1 (why I do this is kind of a long story, but I'll explain if it deems necessary). According to the LabVIEW documentation, VISA should automatically discard any new events once the Event Queue has been filled. I have never had a problem with events being automatically discarded due to a full event queue. Also, I used to get this error after this subVI executes many, many times. So in this case, I didn't think using "VISA Discard Events" would really accomplish anything as the queue get filled immediately and VISA should be discarding everything else until I consume the single event in the buffer (more on that later). I did some testing and confirmed that this error occurs when I try to use "VISA Wait on Event" without closing the event references more times than "Maximum Queue Length". So, I edited my sub VI to the following:
What the code in the For Loop is supposed to accomplish is attempt to close the event reference, then check to see if any event references associated with this particular VISA session are still open. If not, it will set the For Loop conditional to TRUE to stop the loop. Otherwise, it will continue to another iteration of the loop where it re-tries to close the event reference up to "GENERIC MAX RETRY" times (set to 3 in this case). This edit to the subVI dramatically helps, but I still run into some cases of getting this error even though there are no open event references.
I did some other testing where I take my subVI and put it into a For Loop and set N to 500. I notice the same problems where at least one time in the 500 loops, I get the same error even though no open event references exits. So it looks like it is related to executing the subVI too quickly. Therefore, I tried your advice and placed "VISA Discard Events" immediately afterwards and the problem no longer exists! Even when I loop 1000 times in a row!
I think this leads to more confusion than clarity. How can the event buffer overflow if the "Max Queue Length" is set to 1, I am closing my event references, AND I am confirming it is closed before progressing? What is exactly overflowing if my "Max Queue Length" is 1 and LabVIEW is supposed to be already discarding all new events?
If your curious about how exactly I confirm event references exist, below is the block diagram of the subVI which you in the second frame of the Flat Frame Structure:
The subVI with the icon: is "Open Sessions.vi" taken from "visa.llb" that is included with LabVIEW. It lists all open VISA sessions.
Thanks!!
01-21-2014 10:26 AM
I was able to look into the problem a bit more and found that its actually supposed to throw that error whenever the Buffer Fills up. It says that it discards the errors (which it does) but it will still throw an error to alert you to the fact that it is overflowing. The optimal situation is one where the overflow never occurs. You can stay with the current solution or check the errors leaving the specific vi, compare to the Overflow Error, and then selectively clear it without propagating the error through the program. This would allow you to still know that an overflow is occurring but be able to disregard it. I do not recommend it but that is a possible option.
01-21-2014 12:35 PM
Thanks again for your response.
When the buffer does fill up, "VISA Wait on Event" throws a warning code 1073676300:
VISA: (Hex 0x3FFF000C) VISA received more event information of the specified type than the configured queue size could hold.
I assume this means that VISA has already discarded some events because the queue is full. This is fine as it alerts me that the buffer is full AND allows me to retrieve data from my HID device. The problem with this sporadic buffer overflow error message from "VISA Wait on Event" is that it returns a NULL event reference which returns empty data when wired to "VISA Get USB Interrupt Data".
I also played around with "VISA Discard Events" a bit more to see if I could simply my code and depend on discard events instead of checking for open events. Unfortunately I was met with the same issues.
I agree that the ideal situation is to avoid the overflow altogether. Unfortunately, this is a limitation of the HID device where it constantly sends USB Interrupts when polled even when the data is not needed or superfluous. So no matter what I set "Max Queue Length" it would fill up or overflow very quickly while USB Interrupts are enabled.
I tried editing my subVI again where it would only enable USB interrupt events right before "VISA Wait on Event". Then, right after I extract my info with "VISA Get USB Interrupt Data" and close the event reference, I disable and discard events. This is my attempt to control when the host is actually listening for USB interrupt data. Unfortunately, this implementation appears to be completely unstable. After a few runs, it appears the subVI has been stuck somewhere, then a few seconds later all of the LabVIEW windows begin to "whitewash" when I click on them indicating to me by Windows that LabVIEW is non-responsive (as it also states in the titlebar of each window).
So it looks like the only way for me to achieve dependable, consistent results is to loop on "VISA Wait on Event" until the error out does not equal the error code related to the buffer overflowing (up to a max number of iterations).
There are a few things that I'm still confused about relating to using VISA to retrieve USB Interrupt Events. Are you saying that "VISA Wait on Event" is supposed to throw the buffer overflow error each time the buffer is full instead of throwing the warning I mentioned above? If that's the case, is it expected to be unable to use the event reference to extract USB Interrupt data? The way I understood the documention on using VISA Events in LabVIEW 2012 was that events would be discarded but you could still extract data from the buffered event. Also, what constitues the buffer filling vs overflowing? It seems like the buffer is full when the host recieves more USB interrupt events than "Max Queue Length" but overflows when you use "VISA Wait on Event" too many times without closing event references?
Thanks again for your time!
01-22-2014 09:15 AM - edited 01-22-2014 09:16 AM
Use the Clear Errors vi in a case structure controlled by comparing the Error Code coming out of the VISA Wait on Event to -1073807315. Because you don't care that the error occurs and everything should keep on operating normally clearing the error will just stop it alerting you directly.