-
Posts
263 -
Joined
-
Last visited
-
Days Won
10
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by bbean
-
-
3 hours ago, Rolf Kalbermatter said:
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.
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.
-
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
-
Thank you. One of these solutions should work well for me.
-
Does anyone know if there's a VI hidden away in the LabVIEW directory somewhere that returns whether a Format String is valid eg the "Valid" Boolean on the screenshot ?
I'm terrible with regex but I can get an AI code generator to make a regular expression but I'd rather just use a LabVIEW built-in VI to be "safe". FYI this is the regex generated by AI if anyone cares:
%(?:\d+\$)?(?:[-+#^0])?(?:\d+)?(?:[._]\d+)?(?:\{[^}]*\})?(?:<[^>]*>)?[a-zA-Z%] -
Does anyone know the status of GPM and/or Gcentral? I went to gpackag.io and website isn't working.
last commit here https://gitlab.com/mgi/gpm/gpm was a few years ago -
10 hours ago, 김진철 said:
Hello, I would like to save parameters for UI elements and load them when the program exits.
What's the easiest way to do this?
I think UI element parameters might include things like the color and thickness of graph lines, tab positions, and the maximum and minimum Y values for the graph.
you could try this property saver. its pretty old. See the examples in the palette that gets installed
-
Hi @drjdpowell,
Before I reinvent the wheel, do you have any examples of python modules sending messages to one of your LabVIEW TCP Event Messenger Servers (or a simple UDP Receiver / Sender pair)?
I'm interested in extending an existing LabVIEW Messenger Actor to guys on the python side as an API. I'm not sure the best way for them to send message, but a simple one would be to simply send a string with the format (Message Label>>Msg Param1, Msg Param2....)
-
1 hour ago, X___ said:
Emerson is busy leveraging its upcoming integration of LabVIEW in all aspects of its business:
https://www.emerson.com/en-us/news/2023/07-emerson-exchange-immerse-2023-registration-open
https://www.emerson.com/en-us/news/2023/emerson-to-acquire-flexim
https://www.emerson.com/en-us/news/2023/emerson-to-acquire-afag
I didn't see the word "LabVIEW" mentioned in any of those press release. Just seems like Emerson is on a buying spree. Typically this happens at the end of a business cycle when companies (CEOs) run out of ideas for how to improve their business from within. It will be interesting to see how Emerson executes and brings all these acquisitions together under one umbrella and whether LabVIEW has any role.
-
1
-
-
I want to say I've seen this when one of the modules has gone bad. Have you tried pulling them all out and then installing them one by one to see if one of them causes the problem?
-
On 5/25/2023 at 1:35 PM, Jordan Kuehn said:
The demo made me wonder if it could theoretically create drivers from spec sheets automatically. It seems like it would be a well bounded problem, create labview wrappers for the commands listed in the manual.
you can already do this in a limited fashion in python. This is a simple example from a single prompt but you can see where its going:
https://poe.com/s/BEWvBcTIEkrVXzTezpza
The manual was probably online when the model was trained so it already has knowledge of it in this example. But once the size limitations of the text entry increase, you will be able to just upload a manual.
And here's a simple refactoring to make an abstract class
https://poe.com/s/MJp4t75WVrA5MR5SiS8B
On 5/25/2023 at 4:04 AM, ShaunR said:Why does AI type so slowly?
I believe the way they work is they are predicting each character on the fly
-
- Popular Post
- Popular Post
sounds like they were too busy updating NI Logo and colors to implement VISA. Oh well.
-
3
-
On 4/5/2022 at 8:56 AM, Phillip Brooks said:
I am writing a wrapper to a Python class.
The class has several states and will raise an exception when a method is called that is incompatible with the current state.
Are there any best practices for passing exceptions back to LabVIEW? I was thinking of using the LabVIEW error cluster as a return type.
That seems reasonable. I have a wrapper class and pass back a pass/fail numeric and a status string, but now thinking back it might have been more appropriate to just pass back a standard labview error cluster.
In my case, the python wrapper can be run from either LabVIEW or directly in python. The thing i struggle with is passing back real-time status that normally is provided in the terminal via python print statements when python scripts run stand-alone. I'm testing an approach that just sends these via a UDP session but I haven't found a way to override the Python print command so that it prints to both the terminal (python scripts) and to the UDP session (LabVIEW VIs).
-
17 hours ago, Tlam said:
But there is no plan "B", which is very unfortunate. I know what I want my automation software to do and look like, but it does not exist. I'm not sure I'm up to the task of making my own, so I guess I'm stuck with going to Python, unless NI suddenly changes course.
What type of instrumentation and data acquisition systems does your lab work with ? Mostly VISA type serial/gpib/LXI instruments or mostly data acquisition cards / PXI chassis type stuff?
-
1 hour ago, ShaunR said:
If I buy a subscription license and then decide not to renew, what happens to my software?
With subscription software, you will need to renew at the end of each term to maintain access to your software and associated services.
Yikes. Software as a service?
This isn't enticing you to upgrade from LV 2009?😀
-
1
-
-
On 4/23/2021 at 6:12 AM, pawhan11 said:
Has anyone here successfully migrated from TestStand to some open source automation frameworks?
In our hardware test we have a lot of things happening in parallel and so far I haven't found reliable alternative for TS.
I would investigate cosmos. I haven't migrated a complete project to it yet but I'm implementing data collection, storage and telemetry GUIs to it for a new project working with python and FPGA programmers. A lot of the python programmers use python and it as a replacement for LabVIEW/TestStand. I haven't used their Script-Runner (TestStand-ish stuff) but the current version is highly capable for data collection, saving, presentation, limit checking. They are working on cosmos 5 which will run in a docker container and have web based gui's
-
1
-
-
Ok. I misunderstood. But maybe there's something in there that can help. I remember having to do a lot of work arounds with callback VIs to get printing a panel without a prompt for filename to work. Attached is a 2014 version.
-
If you are using Win10 you can try the VI(s) in the attached LLB. We typically create a "print" VI that shows all the controls, decorations logos etc we want to print, then run the VI in this llb.
I threw the llb together real quick...hope everything works.
-
-
1 hour ago, Thoric said:
Their roles are:
- One is Dialogue style GUI Editor for populating an Array - a relatively simple actor.
- Another is a Dialogue style GUI Editor for a more complex file management need. Manages remotely (FTP) stored files.
- A third Dialogue style GUI Editor for managing another Array - a relatively simple actor, like (1).
- A local file management actor for receiving configurations and collating them into a JSON file - a simple decoupled actor with the ability to gather JSON objects from any other actor for storage and retrieval.
- A simple actor that adds log entries to a local text file, and uploads the local file to a remote FTP folder.
So they don't all have one common dependency that the other actors don't also use. The first three present their FPs, but so do many other actors. Some depend on FTP interaction, using a separate internal library we have, but not exclusively so.
I think I'll try cloning one of these 5 actors, trial build it then strip out 1 feature, and repeat until it builds successfully to determine which component is the problem...
This is a long shot here, but do they all need to run in the UI thread but their preferred execution system is set to "same as caller" and then something gets screwed up when they are called by dynamic dispatch in the runtime? What happens if you set their preferred execution system to "user interface" and retry.
-
agreed. As part of my trials and tribulations with MAX I had to repair NI VISA. With NIPM18.5? no option to do that so they recommend uninstalling and reinstalling...fair enough. Tried that and NIPM wanted to uninstall LabVIEW..wtf. Upgrading to the latest version of NIPM (19.6) provided a better experience allowing you to repair installs now.
-
- Popular Post
- Popular Post
MAX
That is all.
-
3
-
On 1/21/2020 at 11:51 AM, drjdpowell said:
Please upgrade to the latest Messenger Library version.
Is the latest version 1.10.9.115? Is there another higher version somewhere because that one seems to still have the issue.
-
Has anyone used IPFS as a tool for storing and distributing test data (multiple gigabytes)? My use case would be to run tests that store data on local windows machines and then distribute that to other users who may have linux, windows etc and also to a centralized archiving location. The users and test machines are in a relatively strict network environment and most users machines are locked down. Some of the linux users may have elevated privileges to install things like ipfs but I'm worried about a typical windows user who may want to get the files easily without having to go through a bunch of command line steps to install ipfs on there machine after requesting elevated privileges.
-
9 hours ago, hooovahh said:
I don't have anything to add other than I've seen this but not in any recent projects I've worked on. It always frustrated me when I'd drill into some VI that was taking forever and it would be some property node or Read/Write/Open that was supposed to have a small timeout.
Thanks for the quick response. its a rather annoying problem.
7 hours ago, Rolf Kalbermatter said:Once VISA calls into the Windows USB driver it can only hope that this driver will return within a reasonable time. I
7 hours ago, Rolf Kalbermatter said:Personally I guess some previous command you send hasn't been fully processed by the device, or you haven't read the entire response, or haven't reset a status flag in the device or something like that. These things all shouldn't be able to lock up the USB interface, but they can and sometimes do.
I think this may have been the problem but wont know until I test again on Monday. You are correct that its a PM320E. And so far their driver has been a pain. The suspect command is the error query the parent class implements by default "SYST:ERR?" but PM320E requires ":SYST:ERR?". A nuance (nuisance) that I failed to notice.
PS. I think I may have borked the instrument up by upgrading the firmware too. Oh well thats what you get for trying to get something done before a holiday weekend.
VISA probe location
in LabVIEW General
Posted
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).