LabVIEW Idea Exchange

I really like the idea of being able to define error codes and descriptions in an error.txt file.  It's very convenient to be able to see all the errors in a single place.  However, the location the error.txt file must be stored, to be blunt, stinks.  Instead of storing them in user.lib\errors (which creates a useless palette item) how about putting them in user.lib\_errors?  It would also be nice if the Error Cluster from Error Code VI had an optional filename input to define which error.txt file to use when looking up the error.

Currently the synchronous and asynchronous modes of writing data have little to no effect when communication over TCP. The write will return immediately after buffering the data to be written. However, the data it self may take considerable time to actually be written to the network. Absent some type of hand shaking at the application level there is no way for an application to wait until all the data has actually been written. The native LabVIEW TCP Write behaves in the same manner as the VISA write. Given this behavior it is impossible to implement a well behaved write queue for queuing up and transmitting data to a device. For example a normal print queue will open a connection and send the data to the printer. It will not attempt to open a second connection for the next print job until the first one has consumed all of the data. If a large amount of data is being written it can take time for all of it to be transmitted. The way the VISA or TCP write VIs behave the print queue would open a connection and write the data. However the call to the write would return immediately because the lower level network stack has accepted the data and buffered it. The print queue then believes the first job is complete and begins processing the second job. This will mean that a second connection will be opened. Some devices will allow multiple connections and some do not. However without the ability to actually wait for the data to be completely written the queue would have to continually try to open connections. This would be unnecessary network traffic and and unnecessary communication with the printer.

 

I would like to see an open on the write VIs to allow for a true blocking write. The write will not return until the data has truly been transmitted. The current behavior is also valid and can be retained.

 

Note: I have not tested the behavior on other types of interfaces so I am not sure if this is a TCP only issue.

We have an application that extensively uses queues, both named and unnamed.  We suspect that one or more of these queues -- probably an unnamed one -- is not being properly drained, and over time is leading to a memory leak.  I would like a means to programmatically examine all the queues in use to determine whether any are growing without bound.  I looked for a way to do this and found this link.

 

The answer here is pretty unsatisfactory.  Our queues have a multitude of types, and replacing every get/release queue with a registration VI specific to that type would be very tiresome.  What we would like is a way to obtain a generic queue reference to each queue -- named or unnamed, suitable for use in Get Queue Status (providing the Elements Out output is not used, as that would require knowledge of type).

 

It would be fine if the refnums were "read only", that is, they could not be used to modify the queue in any way.  Come to think of it, read only refnums might be useful in themselves, but that's another post.

 

If anyone can think of a way to do this with the existing features of 8.6.1 or LV 2000, I'd like to know about it, but there seems to be no existing method for doing this.