crossrulz

If you look at the actual array sizes, things will make a lot more sense.

1. The Build Array will add the number of expanded elements to the first dimension. The array size after the first Build Array is (2,0), which is still an empty array.

2. The Transpose Array will swap the array sizes. The array size after the Transpose Array is (0,2), which is still an empty array.

3. Again, the Build Array will add the number of expanded elements to the first dimension. In this case, it will add 1 to the first dimension, resulting in the array size being (1,2), which is no longer an empty array.

To be honest, I always thought those should be in the Visible Items menu.

Another part of this history: JKI forced NI's hand to release scripting (officially supported and open for everybody to use) with their Right-Click Framework. This is how I discovered scripting. I think I even wrote one or two plugins for myself. Then something happened in LabVIEW 2011 or 2012 that broke it. I asked Michael Aivalotis about it and that's how I found out this part of the story. JKI had no intention of fixing the issue because their mission was accomplished.

What exactly are you referring to when you say "library"? A dll? A LabVIEW library (which is sort of a container for code)? A third-party package of code?

I just noticed the LabVIEW Wiki YouTube account is now gone. What has happened to the videos that were there? My VIWeek presentation (Proper Serial Communications) was one of those handled by this account.

2 hours ago, ShaunR said:

Ask it how I can get past the sign-up CAPTCHA to use it?

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?

1 hour ago, Rolf Kalbermatter said:

Not quite, they don't use NXG to create these application. NXG is truly and definitely dead. But they use the according C# frameworks and widget libraries they were creating for NXG.

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

1 hour ago, Rolf Kalbermatter said:

Someone from NI was busy creating another solution that could build PPLs and in the process of building them also relink any dependencies on lvlib's into dependencies of lvlibp's but that didn't quite finish.

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

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.