Rolf Kalbermatter

Some people might be tempted to use Obtain Queue and Obtain Notifier with a name and assume that since the queue is named each Obtain function returns the same refnum. That is however not true. Each Obtain returns a unique refnum that references a memory structure of a few 10s of bytes that references the actual Queue or Notifier. So the underlaying Queue or Notifier is indeed only existing once per name, BUT each refnum still consumes some memory. And to make matters more tricky, there is only a limited amount of refnum IDs of any sort that can be created. This number lies somewhere between 2^20 and 2^24. Basically for EVERY Obtain you also have to call a Release. Otherwise you leak memory and unique refnum IDs.

And are you sure your Rust FFI configuration is correct? What is the LabVIEW API you call? Datatypes, multiple functions? Basically your Rust FFI is the equivalent to the Call Library Node configuration in LabVIEW. If it is anything like ctypes in Python, it can do a little more than the LabVIEW Call Library Node, but that only makes it more complex and easier to mess things up. And most people struggle with the LabVIEW Call Library Node already mightily.

Drat, and now my typos and errors are put in stone for eternity (well at least until LavaG is eventually shutdown when the last person on earth turns off the light) 😁

Unless I'm completely hallucinating, there used to be an Edit command in this pulldown menu. And it is now for this post, but not for the previous one.

I believe that I was able to edit in the past posts even if they were older. Just came across one of my posts with a typo and when I tried to edit it, the Edit command is not present anymore. Is that a recent change, or am I just hallucinating due to old age?

As far as I can see on the NI website, the WT5000 instrument driver is not using any DLL or similar external code component. As such it seems rather unlikely that this driver is the actual culprit for your problem. Exception 0xC0000005 is basically an Access Violation fault error. This means the executing code tried to cause the CPU to access an address that the current process has no right to access. While not entirely impossible for LabVIEW to generate such an error itself, it would be highly unlikely. The usual suspects are: - corrupted installation of components such as the NI-VISA driver but even LabVIEW is an option But if your application uses any form of DLL or other external code library that is not part of the standard LabVIEW installation, that is almost certainly (typically with 99% chance) the main suspect. Does your application use any Call Library Node anywhere? Where did you get the according VIs from? Who developed the according DLL that is called?

I believe to have read somewhere that he eventually conceded that it was basically an unsolvable problem for a generic, easy to use solution. But that may be my mental interpretation of something he said in the past and he may not agree with that.

The popular serializer/deserializer problem. The serializer is never really the hard part (it can be laborious if you have to handle many data types but it's doable) but the deserializer gets almost always tricky. Every serious programmer gets into this problem at some point, and many spend countless hours to write the perfect serializer/deserializer library, only to abandon their own creation after a few attempts to shoehorn it into other applications. 🙂

Well the fact that you have VI Server property nodes in your top level VI should not force the entire VI hierarchy into the UI thread. Typically the VI will start in one of the other execution systems and context switch to the UI thread whenever it encounters such a property node. But the VISA nodes should still be executed within the execution system that the top level VI is assigned too. Of course if that VI has not been set to a specific execution system things can get a bit more complex. It may depend on how you start them up in that case.

Synchronous is not about running in the UI thread. It is about something different. LabVIEW supports so called cooperative multitasking since long before it also supported preemptive multithreading using the underlaying platform threading support. Basically that means that some nodes can be executed in Asynchronous operation. For instance any build in function with a timeout is usually asynchronous. Your Wait for Multiple ms timing node for instance is not hanging up the loop frame waiting for the expiration for that time. Instead it goes into an asynchronous operation setting up a callback (in reality it is based on occurrences internally) that gets triggered as soon as the timeout is expiring. The diagram is then completely free to use the CPU for anything else that may need attention, without even having to more or less frequently poll the timer to check if it has expired. For interfacing to external drivers this can be done too, if that driver has an asynchronous interface (The Windows API calls that Overlapping operation). This asynchronous interface can be based on callbacks, or on events or occurrences (the LabVIEW low level minimalistic form of events). NI VISA provides an asynchronous interface too, and what happens when you set a VISA node to be asynchronous is basically that it switches to call the asynchronous VISA API. In theory this allows for more efficient use of CPU resources since the node is not just locking up the LabVIEW thread. In practice, the asynchronous VISA API seems to be using internal polling to drive the asynchronous operation and that can actually cause more CPU usage rather than less. It should not affect the lifetime of a VISA session and definitely not the lifetime of a different VISA session. But disconnecting an instrument doesn't automatically make a session invalid. It simply causes any operation that is supposed to use the connection for actual transfer of bytes to fail.

A VISA Session is simply a LabVIEW refnum too, just a different flavor (sepcifically TagRefnum) which has an attached user readable string. Same about DAQmx sessions and any other purple wire. As such the "Is Not A Number/Path/Refnum" works on it too. One difference is that unlike any other LabVIEW refnum, you can actually configure if the lifetime of the VISA refnums should be tied to the top level VI or just left lingering forever until explicitly closed. This is a global setting in the LabVIEW options.

The straight-jacket should take care about shooting in your own feet, or actually shooting at all. 😁

Well, except that LLBs only have one hierarchy level and no possibility to make VIs private for external users. I do feel strongly about packed libraries being a potentially good idea with many limitations that I think were not fully thought out. - Version resource to have some control what version a packed library is? Tacked on by wrapping the proprietary archive format into a PE file and storing it as a custom resource in the PE file. And of course only under Windows, sorry Linux and Linux RT users, we forgot about you. - And the project environment is terrible in supporting them, as LabVIEW does not isolate packed libraries into their own application context. A PPL loaded into one application context, contaminates the entire LabVIEW memory space with its symbols and trying to load the same PPL but compiled for a different architecture into a different application context (RT target for instance) just messes up your project and sometimes beyond repair. And this is even so insane that if you load two projects separately at the same time with the same PPL with different architecture, you just managed to mess up both projects equally! Why does (almost) everything properly observe application context isolation except PPLs?

I didn't say they are a poor mans class, just that they are similar in several ways. 😁 The entire low level mechanics underneath are very similar, the interface provided to the user is somewhat different. Classes can have private data, libraries not. Libraries are the pre-request to creating packed libraries, or as you found out to use the 3rd party Activation Toolkit. They both have their use cases that are distinct from each other.

Have you used LabVIEW classes? A LabVIEW Library is in many ways similar except that you do not have methods and properties but simply only functions (a sort of method) in them, and yes of course no private class data. You can set functions to be private, public or community. Obviously there is no protected type function.