crossrulz

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).

On 3/5/2024 at 9:55 AM, crossrulz said:

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

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.

On 3/5/2024 at 7:32 AM, Francois Aujard said:

Thank you all for your answers

In the end, only the first one is useful. Is there a case where I might prefer the 2nd or 3rd solution over the first?

In fact, the 2nd solution will always be waiting for the end of execution, even if you set the option to call and forget

 

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.

23 minutes ago, Phillip Brooks said:

You can also tell that my posts are not AI because I keep editing them 😅

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.

11 hours ago, codcoder said:

So yes I went for "brute force".

But I managed to solve it using VI scripting, i.e. automatically creating undbundle-by-name from the public cluster to bundle-by-name to the private cluster. So even if the creation process is obscure the result is easy to read by someone who knows only little LabVIEW. Which was what I was aiming for.

Sounds like an OOP solution is what you really want.

4 hours ago, codcoder said:

So will the corporate colour scheme revert from green to blue now to complete the circle? 

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.

12 hours ago, Lucky--Luka said:

I mean: what is that for loop doing?

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.

I am personally a fan of StarTech.  I have not used their PCIe adapters, but their USB-RS232 adapters are really good.

https://www.startech.com/en-us/cards-adapters/serial-cards-adapters?filter_bustype=pci%20express

As far as working with MAX, they just need to be normal COM serial ports and VISA will do the rest.

48 minutes ago, HYH said:

And then NI killed both CDS ( without warning ) and MathScript ( with years of warning ) here in 2023. CDS was NI's own re-implementation of MATRIXx, which they got/bought back in 2003. 

It took me a bit of time to figure out CDS is LabVIEW Control Design and Simulation Module.  Yeah, that kind of came out of nowhere, but it was really only used in academia as far as I am aware.

MathScript was also dropped mostly due to it being a major PITA to maintain, especially since Matlab was such a better product to do something very similar.  As soon as NI and Mathworks became friends, I saw this coming.

1. Move the VISA Configure Serial Port to before the loop.  No need keep re-initializing it.

2. You shouldn't need the Flush Buffer.

3. You should not need the wait.  This would also eliminate the need for the Sequence Structure

4. Since you are expecting a response immediately after you send the command (or soon after), you should not be checking the Bytes At Port.  This would eliminate the need for the Case Structure.

5. Because of the termination character, tell the VISA Read to read more bytes than you expect back.  In this case, I would probably use 50.  The read will complete when the Line Feed is encountered.

6. Since you are dealing with space separated data, use the Spreadsheet String To Array with a space set as the delimiter to make an array of strings, each element corresponding to a piece of data.  You can use Index Array if you really want them separated out.

22 minutes ago, hooovahh said:

I remember a presentation by Jack Dunaway years ago at NI Week I think that talked about some of the event behaviors, and how it has changed in some releases.  This was in the 2012 era.

Then, a couple of years later, NI completely redid how events work behind the scenes which corrected some things Jack mentioned, complete with an NI Week presentation.

I don't think VISA works with UDP.  It will work with TCP.  So you are going to have to use the UDP functions to communicate with this device.

If you can read the serial number from the device, then you can just use Format String to create the file name and then write to the file as you already are doing.

0x08 is a Backspace.  In \ Codes, that is \b.

A little more information on the \ Codes here: Backslash ('\') Codes Display LabVIEW Help

Wire a value into the shift register on the left side of the loop.

Crosspost on the darkside: https://forums.ni.com/t5/LabVIEW/connect-LabVIEW-USB-or-LAN/m-p/4309342

The announcement for the acquisition did happen in early April.  Now it is just waiting for approval by the US government and who knows what other legal red tape for it to actually happen.  One of the articles mentioned the acquisition finalization was expected to be in Emerson's financial 2024 H1, which starts in October.  Do not expect to hear anything until that happens.