crossrulz

Is ShaunR actually a robot? https://www.youtube.com/watch?v=UymlSE7ax1o

I have had this in my toolbox for a long time to do what you are asking. It is part of a QuickDrop plugin I made to "fix up" a VI, similar to Darren's Nattify plugin. Size Diagram Window.vi

Hopefully, these are just those sleeper accounts Michael mentioned earlier.

You are limited by the max rate of the AI module. What module are you trying to read from?

Yeah, but when the picture are suddenly in the "Unread Content" stream, it makes it a lot harder to ignore.

And now I'm seeing NSFW spam. Seriously, until things get fixed, all new signups should be blocked.

It is called Search 1d Array for a reason. It cannot search a 2D Array. So now the question is: What do you expect for an output? Do you want to prioritize search the row or the column?

To put in a little more detail... For NI, NXG was way more than just a rewrite of LabVIEW. NXG was a framework that all of their applications would use. This is most obvious with the UI. There is a full project just to manage the UI components: Fuse Design System

That sounds like the LabVIEW Solution Builder, which I use. It works quite well.

I have been using PPLs in my architecture for many years with very little issues. But I am generally using them in Windows only and the PPLs are pretty small. I use the LabVIEW Solution Builder to build my core libraries. I will also state that NI is actively working on the PPL build process behind the scenes.

What is the communication bus that is used to talk to the instruments? Assuming anything VISA, it is likely that the communication time will swamp out any gains from going parallel. As a gut feel, I would likely go with the Parallel FOR Loop simply because it is easier to code up than two FOR loops (one to launch the VIs and a second to collect the results).

Update: There is now a 2024 Q1 patch that fixes this bug. So you no longer need to wire up the Type Specifier when using the static VI reference wired to the VI Path input on the Open VI Reference. The patch also covers several security issues. Those who are using 2024Q1 really should go into NIPM and get the update.

FYI, there is a new feature in LabVIEW 2024Q1 where can wire the reference to the VI Path input on the Open VI Reference. You do also need to wire up the Type Specifier if you need the strict type. NI has stated the need for the type specifier as a bug per this thread on the dark side: New Open VI Reference Functionality

Top: Start Asynchronous Call - Loads a VI, starts running the VI, and then waits for it to complete. The SAC returns as soon as the VI has started to run. The Wait On Asynchronous Call is what waits for the VI to complete and return its outputs. Middle: Call By Reference - Loads a VI and runs it. The CBR will not return until the called VI is complete. Bottom: Run VI Invoke Node - Loads a VI and runs it. If you wire FALSE to the Wait Until Done input, the VI runs asynchronously. If you wire a TRUE to the Wait Until Done input, the invoke node will not return until the VI is complete. You do not have a direct way of getting the results once the VI is complete.

Sounds like something a real AI would do to throw off the humans...

1. Use Read Delimited Spreadsheet File to read the file and get a 2D array of strings. 2. Your text file does not have any tab characters. Are they supposed to be space delimited? 3. You have duplicate values in your text file. This could be causing an error when you try to set them.

I avoid named queues and notifiers. So what I do is put the notifier reference in the event data. This makes the calling VI in control of the reference.

What hardware are you using? I see it is cDAQ, but what modules and chassis?

One of the few times Block Diagram Cleanup can be useful.

Sounds like an OOP solution is what you really want.

I'm glad I wasn't the only one having that thought.

It is now official: Emerson Completes Acquisition of NI, Advancing Global Automation Leadership

In this exact scenario, I think I would make a "Waveforms" library that would contain the waveform data type and any other general waveform processing VIs. Any module that generates or processes a waveform can then depend on that library.

It is formatting each byte into an ASCII representation of the byte.

For 7-10 years, you will probably be fine sticking with LabVIEW and TestStand. For those of us who are more like 20 years out, looking at alternatives is advisable. I am personally interested in Rust, but also want to get back into the C world for embedded work.