crossrulz

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.