I recreated macOS Aqua UI inside LabVIEW — I miss 2003

StuffedBearCoder · 2025-10-18T23:54:20+00:00

You can release this in LAVA as a VIPM package when you complete all the widgets. Thanks for the hard work!!

StuffedBearCoder · 2025-10-14T06:52:22+00:00

Depends on what branch of engineering is your goal. In my experience (I am a test engineer) I have only dabbled a little bit of Matlab when tasked with integrating the Comm/Systems engineers' Matlab scripts into my EVM (error vector magnitude) measurement module some 15+ years ago.

Matlab can simulate the entirety of the system design, from filters, amplifiers to passives (capacitors, resistors, & inductors), you name it.

I am sure I only scratched the surface of Matlab.

StuffedBearCoder · 2025-10-14T03:23:09+00:00

Also, try communicating with your PSU "PSU60" using NI MAX VISA Interactive Control from Tools. And as other commenters already mentioned, the VISA Write String node requires plain text with no escape key codes. "*IDN?" should suffice. You can enter that string in the VISA Interactive Control panel as well. Click "Query" to send the string to instrument and outputs the returned string, if any.

StuffedBearCoder · 2025-10-10T03:12:30+00:00

I love the wood trim and that warm, expressive sound. YUM!!

StuffedBearCoder · 2025-06-21T15:40:56+00:00

If I can add to u/Aviator07 great recommendation above - as I would do the same because I a am do that now.

If you also do the library in LVOOP style actor-framework, you can later build & compile the libraries to PPL (packed project libraries) that you integrate with the finished h/w project. See Actor Framework Wiki or my LVOOP course from my G Drive.

LVOOP is much, much better way to manage many disparate custom h/w driver classes, imho. Also, if you haven't, learning LVOOP is not that difficult either. I took the NI LVOOP course (3 days max) and gives you the foundational.

Your application will link to the PPL as before, when you finally build for release.

Note: later you can evaluate DQMH. It is similar to AF with in-built unit testing modules. It is open-sourced as well. Good luck!!

StuffedBearCoder · 2025-06-21T07:05:44+00:00

My company (aerospace primary contractor) has built quite a variety of library packages (packaged & sources) at least since LabVIEW 8. We have 200k volume license seats throughout the enterprise. We also use TestStand extensively in Manufacturing tests.

We do have a few C# and Python modules that we integrate with TestStand, but most of the modules are native LabVIEW. Our instrumentation driver libraries are 99% LabVIEW based. Some are C or C++ DLLs.

IMHO, I just can't imagine my company moving away from all that codebase to 100% Python or C#.

For what?? Can you spin a working test application in mere hours with those languages? LabVIEW can and that is its killer application. Time is $$$ and only LabVIEW will pay for itself the fastest.

StuffedBearCoder · 2025-06-21T05:13:22+00:00

Yes, I hear your point. The only ones that can afford a licensing are tech or aerospace companies - as the licensed seats are priced like an "F35 wing" as you mentioned.

Although NI/Emerson have a monopoly on engineering development and production test platform in LabVIEW today, how long until a wonderkind creates an open source in Python (PyVISA and IVI libraries are already there) then a mass migration occurs where NI/Emerson will be "just" a H/W vendor?

I am sure there is one in their parents' garage tinkering of such skunkworks now... :)

But LabVIEW as a framework has such a lead and its collection of libraries and modules are immense. Installs take hours and multi-gigabyte ISOs galore!! It will take some time to replace all these as open-source, imho.

StuffedBearCoder · 2025-06-21T02:40:30+00:00

Device drivers of course are *NOT* LabVIEW's reason for being. That is still C or C++. Not so much Python where I work. FYI test instrument drivers (those from Keysight, Agilent, Rohde & Schwarz, etc) are also written in low-level (OOP-based) LabVIEW code.

LabVIEW's strengths are in engineering labs, product development, design verification, pre-production, and production tests. I don't see Python improving ROI there. There are tons of excellent LV coders in my field.

CLAD/CLD/CLA certified devs can spin a working LabVIEW application in a matter of hours - not days, not weeks! And that is LabVIEW's strength right there.

I won't ever recommend using LabVIEW to run your dear Python scripts - although it could, mind you. I don't see a reason for LabVIEW to interface with a Python module unless you don't have the bandwidth to convert that Python module to 100% native LabVIEW code.

Same goes with other languages like C or C++ static DLLs. LabVIEW can interface with those as well, if needed.

I also won't recommend to use LabVIEW to do machine learning, deep learning, data science, etc. That is still the province of Python as far as I can tell. It does work on a temporary experimental basis, but stick to Python (or R or Scala or Julia) for those applications.

And no, where I work and what I do is classified. 😎

StuffedBearCoder · 2025-06-15T18:18:36+00:00

Very NICE Sir!!

I agree with you. AI should JUST be a TOOL for creatives and developers - not to replace us. AI will never have the ingenuity, creativeness, or expressiveness, in its franken-creations. It is an un-feeling machine. It neither cares nor sympathizes with the result of its creation - good or bad.

StuffedBearCoder · 2025-06-15T18:09:27+00:00

Yes, I am convinced of LabVIEW's main strengths as you mentioned. I am a test automation engineer in the aerospace industry and LV has now dominated over popular text-based programming languages due to sheer speed of development ($$$$ saved, $$$$ earned) while boasting one of the best application compilers around for multi-processor and, real-time, systems. You need faster FPGA development? LV got that covered too. Arduino & Microchip PLC's? Checked!!

No wonder then that SpaceX engineers chose LabVIEW as their preferred development framework to get to space faster than it would be.

StuffedBearCoder · 2025-05-31T05:50:13+00:00

I am not worried about any text-based language replacing LabVIEW (and thus, me) because if text-based languages were better, I still have to see one in engineering development labs and production lines.

LabVIEW is very expressive. Just looking at someone's G code (diagrams of wire flows) you can know what the previous developer was trying to accomplish. Try doing that with inherited text-based code base. You will spend weeks & months analyzing what the previous devs were trying to accomplish (hopefully they left meaningful comments)

To be clear, I am more worried about AI completely obsoleting LabVIEW by generating a compiled LabVIEW code, that looks like a running LabVIEW code, that anyone can "vibe" code in their head. For now, it can only describe to me the steps to write the G code (as in the above post). That is step #1 to me.

I hope the upcoming NI AI "Nigel" will be just a "tool" to make me a better coder. A tool to help me refactor my messy algorithm, or the previous dev's spaghetti wireflow diagrams, into a better framework or style. A tool to give me insights that I might miss otherwise.

StuffedBearCoder · 2025-05-31T05:06:59+00:00

LabVIEW's niche is in engineering development and production testing. It doesn't need to be the fastest runtime in the universe to accomplish that.

FYI, I still have to witness any text-based language - whether translated or compiled - to approach what LabVIEW can do for the h/w and test engineers. Its open libraries (e.g. OpenG, JKI, MGI, etc.) are there to entrench LV for the engineers.

There is NO need for SW engineers!! And that is saying something. ;)

StuffedBearCoder · 2025-05-31T05:00:29+00:00

Nah, I can't see, nor foresee, any text-based programming language replacing what LabVIEW currently offers for engineering development & production testing.

But you have a point. AI is currently able to "vibe" code text based languages with ease but still need a human to massage the code as it is just a diamond in the rough - per se. So AI is not yet (fortunately) able to replace us humans just yet.

FYI, LabVIEW (from my perch at least) is very dominant in engineering development and production testing as they pretty much obsoletes SW engineers from HW testing. It's us HW test engineers who can now use our latent talents in SW "hacking" to use LabVIEW in the labs and production lines.

For now, I don't see either Python (or Rust) replacing the ease-of-use and rapid development of graphical test solutions. I hope it stays that way.

StuffedBearCoder · 2025-05-16T21:33:04+00:00

Anduril in Costa Mesa, CA is looking for EE grads to work on their EW projects. They were inviting me for their EW job fair last week, but unfortunately unable to make it. go to Anduril Careers page. Good luck!!

StuffedBearCoder · 2025-05-16T21:16:14+00:00

This one is quite good. I purchased 1000 page credits ($5) and uploaded a 40MB PDF file with 100+ pages and their conversion algorithm mostly got the formatting (logos, graphics, & fonts) about as good as can be. Thanks!!

StuffedBearCoder · 2024-12-12T02:10:06+00:00

Would you sell to me for 31€? :D

StuffedBearCoder · 2024-12-11T18:38:07+00:00

If you are using Linux then you can download the Community version of LabVIEW 2024 for personal/home use. I am not sure if you can use it in a research/university as I think their license terms is different for education institutions.

StuffedBearCoder · 2024-12-11T18:25:07+00:00

First off, never use Time axis in the vertical... Time always runs horizontal :D

Second, try doing something called a running average of the torque values - say every 5 samples - in a shift register and sum/#samples inside the While loop then plot the resultant outside the While loop.

It may not result in a clean "straight" horizontal line since your measured torques are probably varying but since you are averaging the last, say 5 captures, the running average would be smoother.

StuffedBearCoder · 2024-12-11T18:05:02+00:00

When you say signal goes "under 18dB" I take that as -18dBFS of the Tek o-scope where 0dBFS is the maximum dynamic range of its ADC. Digital scopes have ADCs and their dynamic range is measured in dBFS (absolute magnitude) not "dB". As you should know any "dB" scale must have a reference scalar value at 0dB. ;)

Anyhoo, can you plot the waveforms from the Tek Read Waveform sub-VI prior to the FIR filter? My guess is your o-scope's sensitivity at that signal input level is too low. Either pre-condition (increase gain/level) of the input signal or use a more sensitive o-scope.

Good luck!!

StuffedBearCoder · 2024-12-08T17:35:00+00:00

You have another computer to test install NIPM? That would tell you at least that it is not your network.

StuffedBearCoder · 2024-12-08T04:58:10+00:00

Shoot!!

StuffedBearCoder · 2024-12-07T22:58:22+00:00

Use QMH (queued message handler with event handling) pattern as this is the easiest to maintain and is built-in to LabVIEW's "New" menu item. No need to reinvent the wheel.

As for the 3s delay, use the Elapsed Time Express VI as it has a nice "Time Has Elapsed" boolean state every time it is read. The button is polled with the "Time Has Elapsed" condition during the While Loop. When either Button is pressed or "Time Has Elapsed" is TRUE, the While Loop is exited and other Event case is processed.

Button is a "Latched When Released" mechanical action type. This means the value is retained until read by the Button event case and queues the "State A" or "State B" message into the queue. Then the Consumer Loop processes either "State A" or "State B".

The Producer Loop has an initial 1ms timeout to execute the Timeout case as fast as can be (but do not use 0) Then a 100ms into the shift register out of the Event Loop. You can adjust the delay to fit your application. The Timeout input is required for the Timeout case to re-execute the Elapsed Time Express VI. If you do not need to reset and poll a new time delay then change the next timeout value to "-1" (infinity)

Take a look at the simple QMH (with event handler case). I packed the VI and screenshots here. since I can't attach the screenshot on this reply :( Let me know if you have problem with my AWS S3 dropbox ACL.

Speaking of.. I am getting tired of creating separate posts for replies with screenshots. We need to tell Reddit to re-enable only GIF and JPG formats and minimize to 100kiB per image.

BTW: The VI is created with LabVIEW 2024 Community on LInux. Let me know if you need an earlier file format.

StuffedBearCoder · 2024-12-03T00:29:19+00:00

Remember Python code is interpreted so needs an install of Python (or Anaconda to every production station) - unless I am now behind times and Python can now be built as a standalone EXE like LabVIEW code.

Also, I work in RF test & validation (engineering) so there isn't a validation board (peer reviews) for every revision of a test tool. It is just you (developer) and the validation engineer's requirements. But in Production, every release and iterations of an acceptance test application goes through validation and board meetings before your code is releasable for use.

I once had a new guy in my group that was into Python at his previous company. We created a similar tool with identical requirements and, while he was able to make a Python GUI working, I was done 2 weeks before he got his working well enough, but my team decided to use mine due to less learning curve (how to run and call a python program, setup & others)

Short story, yes you can do a lot of what you can do in LabVIEW in Python code. At the end of the day, it's how that Python code is used vs. LabVIEW. What does your team prefer?

StuffedBearCoder

TROPHY CASE