All Activity

You are correct...I worded my thought incorrectly. My thought was that since the Keysight code was using Synchronous VISA calls and both the Keysight / Pendulum were most likely running in the UI thread bc their callers were in the UI thread and the execution system was set to same as caller initially, the VISA Write / Read calls to the powered off instrument were probably blocking the other instrument with a valid connection (since by my understanding there is typically only one UI thread).

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.

Thanks for the detailed explanation. I think the "Is Not a Number/Path/Refnum" is what I'm looking for based on what you mentioned and what the probe has under the hood. I've never really had a need for using it before with VISA until now and I'm learning things even after many years of coding LabVIEW. What brought up the question was a situation where two separate "instrument drivers", one an Keysight 973 multiplexer and the other a Pendulum CNT-91 Frequency counter were being called in separate loops. The loop for the Keysight 973 was setup to periodically (every 10secs) sample its channel list, the loop for the Pendulum was setup in a similar fashion to sample every 500ms. At some point the end user disconnected the Keysight 973, but wanted to continue measuring with the Pendulum CNT-91. But with the Keysight disconnected, the VISA calls in its loop were locking up or reserving the USB bus and interfering with the measurements in Pendulum loop. Diving into the weeds of the code, I noticed: the Keysight 973 driver (actually an older version using Agilent 34970 code) had Synchronous VISA Write and Read calls. So I thought those must be running in the UI thread and blocking the execution of the Pendulum loop when the instrument was connected. After switching them to Asynchronous VISA calls the problem persisted. Both VIs that sampled the data were had VI properties for Execution set to "same as caller" and since they were both called from top level VIs that had property nodes, event structures etc they were probably both running in the UI thread. I switched the Keysight to the "data acquisition" thread and the Pendulum to the "instrument driver" thread. But the problem still persisted. in the Keysight loop I had made use of the VISA User Data property to store and track the number of channels were being queried. This VI was taking ~2secs to execute when the Keysight was not connected. This was a surprise to me because I thought it was just a passive property node that would return its value (quickly and without error) even if the instrument was disconnected. But apparently, its doing much more under the hood, possibly even trying to reconnect (possibly VISA open under the hood?) to the Keysight instrument. After temporarily disabling this code and all instrument query in the 10 sec sampling loop, the interference or blocking of the Pendulum went away. Lessons learned: If an instrument is disconnected physically, make sure you disable any queries to it if the VISA session isn't valid or didn't' connect properly in your initialize state. I'm still not sure why a VISA query timeout or User Data call would block a separate VISA loop with a different address from executing if they are properly setup to use separate threads (maybe I'm still not doing that correctly). I guess I could use NI I/O trace to get more details about what's going on under the hood when the User data property is read. What's also weird to me is that the VISA timeout for that session was 10 seconds (not 2 seconds) but every call to the User Data property took almost exactly 2 secs. Avoid using the VISA user data property for passive storage because its not actually passive. the "Is Not A Number/Path/Refnum" works with VISA sessions. Even though I disabled sampling now if the Keysight initialize state fails, I'm also using the "Is Not a Number/Path/Refnum" as a paranoid check before executing the sampling code now. Looking at the VISA probe VI that Darren linked to, it appears like the code also checks the VISA property "Rsrc Class" to see if the VISA session "Is Instr" if the "Is Not a Number/Path/Refnum" returns a False. Does anyone know if this is a passive call under the hood? Thanks for everyone's help.

I like this solution. It doesn't ban external links entirely, instead it asks a mod or admin to approve the post with external links. I got got an email to approve of a post, just like I would get an email for reported spam.

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.

I wonder, would it be possible to use your SQLite Logger to extend the messenger library to have a logging capability similar to the Worker Framework Message logs. https://docs.workersforlabview.io/workers-tools/workers-tools-menu/workers-debug-server/worker-message-logs

I’m going to be using this thread to post my adventures at NI Connect.

I put a temporary ban on inserting external links in posts (except from a safe list). We'll see what affect it has.

C:\Program Files\NI\LVAddons\nivisa\1\vi.lib\_probes\default\VisaProbes.llb\VisaProbeInstr.vi

Does anyone know where the VISA Instr Probe (custom probe) source code is located? I'm interested in how the "Is session valid?" and "Is Instr?" Booleans are determined

Open the search function (Ctrl+F) and browse for the "NaN" constant. A dialog pops up telling you this palette item is not supported by the Find Dialog... You can search for the "NaN" string and it will find all the NaN constants (plus all the occurrences of the "NaN" string). You can search for all other constants (pi, machine epsilon, +/-Inf, etc.), but not for the NaN constant, which is just a numeric constant with NaN typed in it. You can search for ALL numeric constants, but not for a specific one, say "1". Of course, you can search for all "1" strings in your code, and the constant 1 will show up among the search results, but it will be hidden in a long list of irrelevant results. And try to search for a constant with units... You can't. What would be nice is to look for a constant irrespective of its unit, as for instance 60 s = 1 min. Did I encode that time constant as 60 s or 1 min? I need to search for 60 AND 1 to find out.

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

Thanks for raising your concerns. I'm aware of the problem. The root cause I believe is the forums framework itself. It has many safeguards, but it seems that the spammers are always one step ahead. There are still more avenues I can explore, so I haven't given up.

You actually have 2 levels with LLB's (semanticly) and that's more than enough for me. I also don't agree with all the private stuff. Protected should be the minimal resolution so people can override if they want to but still be able to modify everything without hacking the base. This only really makes sense in non-LabVIEW languages though so protected might as well be private in LabVIEW. And don't get me started with all that guff on "Friends" But in terms of containers, external users can call what they like as far as I'm concerned but just know only the published API is supported. So making stuff private is a non-issue to me. If I'm feeing generous and want them to call stuff then I make it a Top Level vi in the LLB. Everything else is support stuff for the top level VI's so call it at your peril. I still maintain PPL's are just LLB's wearing straight-jackets and foot-shooting holsters.

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?

*prerequisite. Packed libraries are another feature that doesn't really solve any problems that you couldn't do with LLB's. At best it is a whole new library type to solve a minor source code control problem.

@drjdpowell I’ve tried to reproduce the error with the DVR but so far unsuccessful. when you have a chance can you review or comment latest pull request? Targets mostly libpq install, threading, etc. thanks

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.

There isn't anything really special about lvlibs. They are basically containers with a couple of bells and whistles. If you look at them with a text editor you will see it's basically a list of VI's in an XML format. The main reason I use them is that they can be protected with the NI 3rd Party Activation Toolkit. A secondary reason I use them is for organisation and partitioning. It would be frowned upon by many but I use lvlibs for the ability to add virtual directories and self populating directories for organisation and contain the actual VI's in llb's for ease of distribution. I don't see them as a poor-mans class, rather a llb with project-like features.

This is the situation in 14 and 19 here. In 14 Wire has some interesting properties in 14, but not Value. Note that e.g. Attach Probe is accessed as a property in 14 and a Method in 19; and BD is an array of integers in 14.

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.

Yes, Diagram property exists, and as a reference, since at least 8.5, I've checked. Edit : and ... I put here a simple VI containing the following code. It's saved in LV2015 version, if someone can tell me with which version it won't be broken... Thanks ! value of wire classe reference.vi

Rolf is correct, I forgot to enable scripting in the LV19 I used to check OTOH, in LV14 "Block diagram" is indeed present but is an array of I6 rather than a ref. I can't guess what was its intended use back then, maybe it was just an uncooked feature.

I can create it without problems in LabVIEW 2018 and 2020! So it is either that Scripting is not enabled in that LabVIEW installation or a bug in backsaving some of the scripting nodes to earlier LabVIEW versions. And I'm pretty sure that the Diagram property (called Block Diagram in the menu) is available since at least 2009 or thereabout. I can check this evening. My computer at work only has LabVIEW versions back to 2018 installed.

Thank you ensegre ! Very strange that diagram property does not appear in LV2019/2021 ! it's the basis for scripting...