Stagg54

A question about this came up the other day and I didn't have a good answer.

If you have a VI that needs to be run multiple times in parallel and all the results collected, which is better? Parallel For Loop or Async Call and Collect?

They are already calling it in a for loop serially and are just looking for better performance - it talks to several identical hardware devices so the for loop autoindexes on the Hardware refs. Parallel For Loop seems like an easy answer, but what are the tradeoffs? I seem to remember something about Parallel For Loop and the number of cores - I don't really know. I haven't used the parallel for loop much.

My initial answer was to just try both approaches and benchmark them.

And we wonder why LabVIEW is losing out to tools like Python..

I am not an AF person, but I think if you look at the State Pattern Actor, I'm pretty sure it uses that override.

Nancy, Malcolm, Taylor and I are putting on an online unconference for LabVIEW consultants.

https://www.lvconsultantsummit.com/

It feels like you are trying to be too clever. Brute force seems like the easier way. Yes it's less elegant. Unless your cluster is enormous, I would probably just brute force it.

It is a huge challenge in LabVIEW. It is often overlooked by beginners which causes lots of problems.

I often just have a common folder on disk full of typedefs.

I have tried to use more generic types as much as possible when transferring data across module boundaries. If I can I pass some native datatype like a map, set or array. For a waveform, why not just a simple native waveform? If you have metadata, IIRC waveforms accept metadata just like variants do.

Occassionally, I'll even pass a simple cluster without making it a typedef. ie. an x-y point is just a cluster of 2 doubles. No real need to make that a typedef. Of course as soon as it gets any more complicated, then you probably need a typedef.

I've also given a lot of thought to using JSON to pass data between modules, but haven't quite worked that out yet.

On 2/22/2023 at 6:21 AM, djolivet said:

Maybe you should try to land some freelance LabVIEW work?  Back in the day you could locate this type of work through your local NI rep, or attending various NI events and networking.  It seems like NI is much less active these days so I'm not sure if that is still feasible.  I once picked up a years long freelance gig off a freelance programing website (the site has long since disappeared)

Finding work is one of the bigger challenges and often results in a lot of waiting around for contracts to resolve and then having a bunch of them resolve at once. Feast or Famine.

If you don't like downtime and just want to write LabVIEW code, being a consultant is a horrible idea. Find a better employer.

Just copy-paste this into Git Bash - that's it!

cd && git clone https://gitlab.com/sas-blog/LVCompare-Merge-Setup.git && cd LVCompare-Merge-Setup && ./setupLVTools.sh

For more info checkout the repository here:

https://gitlab.com/sas-blog/LVCompare-Merge-Setup

Demo'd here:

forgot to mention this part:

Presenters at the GLA Summit will be eligible to receive 30 recertification points for NI LabVIEW certifications.
Attendees will also be able to receive 20 points.

We are looking for presentations.

more info here:

https://www.glasummit.org/

Quote

Just like politicians.

Marketing - the 3rd oldest profession!

Those original scripts will no longer work with new versions of Git. In newer versions the 2 files being diffed will have the same file name. The script needs to account for that condition and rename the remote file.

I have  a created a similar bash script here that accounts for that.

https://gitlab.com/sas-blog/LVCompare-Merge-Setup

7 hours ago, jcarmody said:

Off topic, but you've struck on a perfect name for my next online chess account!  I'll drop the "you're" and add a few underscores, but that's it.  Thanks.

I'll just stick with the self-deprecating one "yes_i_am_aware_i_am_still_an_idiot". Probably not taken.

see here for how to load stuff dynamically

https://www.sasworkshops.com/ppl-plugins/

That solves part of your problem. The other half is about organizing your object heirarchy. The GOF can help here.

You can buy the original, but this is better. 

https://refactoring.guru/design-patterns/book

I would envision using an interface for switch and an interface for DMM.

the DMM with a switch would implement both. You would need some way to discover that or hardcode it into a config file or something.

Sorry if that is a little vague, but I could envision several different ways to do it. I'd probably just sit down with LV and iterate until I found something that works. And then sit and stew and make sure I didn't miss anything. I'd still be prepared to throw away version 1 in favor of version 2 because you are sure to miss something.

Good luck.

55 minutes ago, bbean said:

I haven't found a way to override the Python print command so that it prints to both the terminal (python scripts) and to the UDP session (LabVIEW VIs).

I'm no Python guru,

but maybe a decorator?

and or maybe monkeypatching?

or some combination?

I'll be there. But since you are also going to GDevCon NA, we could do a LAVA BBQ there as well. Or might might I suggest a LAVA tubing event? There is a whitewater park a block from the venue.

4 hours ago, ShaunR said:

20 years ago they were building better software. Discuss 

Possibly. Depends on your definition of better. They certainly had more constraints to work within and it forced them to be more efficient with things like memory usage and storage space. One could argue that makes for better code, but optimizing for those things often compromises readability. So what do you value more? and how do you define "better" software?

On 3/21/2022 at 3:42 AM, Mads said:

To work well I need to keep and manipulate 110% of the problem in my head  (the extra 10 percent (or 200%) is the array of continuously variating attacks on the project my fantasy throws at it while I am working on it to find holes, weaknesses and opportunities in the plan 🧐) , and to do that I need to be "alone inside my head".... 

To that I would say, someone else looking at your code is much more likely to find the holes than you are. If the holes were obvious to you, you wouldn't have put them there to begin with. We inherently understand that, that's why we do code reviews. However, often the code review is too late to really change things. What if we caught those problems while they were being written and fixed them then? 

What's the old saying "2 heads are better than 1"?

On 3/21/2022 at 3:42 AM, Mads said:

Wow, I would *never* program in pairs. Who can stay in the zone with someone else messing with the flow (see item 8 on this list...)  Working together while discussing the work and writing pseudocode is good, but while actually programming? Yuck.

To work well I need to keep and manipulate 110% of the problem in my head  (the extra 10 percent (or 200%) is the array of continuously variating attacks on the project my fantasy throws at it while I am working on it to find holes, weaknesses and opportunities in the plan 🧐) , and to do that I need to be "alone inside my head".... 

The Joel test was good for its time, but it's 20 years old. I think it's time we reevaluate it.

Number 8 is probably one of the most outdated. Remote work didn't even really exist back then.

Here is a more modern take on it.

https://www.sasworkshops.com/joel-3-joel-test/

On 3/21/2022 at 12:33 AM, Antoine Chalons said:

Do you do that?

In 15 years I only met one LabVIEW Dev who was in a job where management organised pair programming. I'd like to hear feedback from people who do that 🧐

I have done pair programming with clients and it works quite well. Granted these were one-off sessions working to solve a very particular problem. I mostly work alone so I haven't used it in a wide spread way, but I know people that have and are successful with it. Given the fact that most corporate management is still stuck in the industrial age, it's not very widespread. 

Seperate projects is not that uncommon, but I second what Neil says. Innosetup works great if you are still building installers. Much nicer than the NI build-in one and the results are orders of magnitude smaller. Offers you a lot more control too.

Lately I've just migrated to doing NI Packages instead of installers. They seem to work fine. Although you would still have the same problem with multiple devs working in parallel. 

One other often overlooked solution to the whole working in parallel problem is pair or mob programming. No need to worry branching, merging or stepping on each other's toes.

Apparently it's contagious!

On 3/2/2022 at 7:40 PM, X___ said:

quoted from this video (not my input):

Well NI just solved the distribution and licensing problem didn't they? No one's complaining about that any more.