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.

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/

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

The conference went well. We got lots of good video, but it will take a while to edit. I don't have an exact timeframe, but they should be posted within the next month or so. We had an extra cameraman and better lighting and angles this year, so the videos should be even better than last year.

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