Make Sync.vim extendable

[S.Allen.881]

The new Sync.vim is one of my favorite new features, as it takes significantly less space on the block diagram than a flat sequence structure or other alternatives. However, whenever more than two wires need to be synchronized, additional instances of the vim must be added:

I think Sync.vim would be an even better tool if the user could drag up or down to add additional terminals (like "build array," "build cluster," etc).

[AristosQueue (NI)]

There's a reason it isn't in the palettes: there's dissent among LV R&D about whether it should have shipped or not. I have a hard time imagining it getting any augmentation.

Do you need it that often? It should be rarer than a sequence structure, and G code already steers clear of those as often as possible.

[S.Allen.881]

I use it most often in cases where things need to occur sequentially, but aren't directly related (essentially in place of a flat sequence):

I suppose an alternate solution would be to add "error in" and "error out" to all relevant subVIs in the sequence (even if they don't have the potential to generate an error). Is that the best practice?

[AristosQueue (NI)]

In general, anything that is reference based can generate an error; anything that is hardware based can generate an error. Basically, almost anything that isn't a pure function with no side-effects can generate an error. Given that, it's pretty rare to have a subVI that has parallel side-effects that doesn't have error terminals.

In your picture, "Set" is clearly doing something that "Meas" cares about. If that's talking to some external thingamajig, then that should have an error. But maybe you're just setting the value into a global VI or a functional global VI... those don't generate an error. In those cases, the first question to ask is, "Why are you doing that?" There are good reasons and bad reasons. Often LV works better -- in lots of ways -- if you eliminate the global storage and just wire the value through to the downstream functions. No need for sync, generally easier to read, definitely easier to debug (because you can just put test values on the panel instead of having to setup an external source of data).

If after all that, you still don't have a data reason to have a dependency between the asynch parts, then its legit to use synchronization. It's not an "always wrong" tool, just a "usually wrong" tool. 🙂 And it is abused by numerous LV users who get themselves into binds that kill their performance, or enable them to *think* they have safe parallelism. For that reason, doing things that make it easier to reach for is often a disservice.

[S.Allen.881]

OK, thanks for your awesome feedback! I will try to include error codes in my subVIs in the future and avoid synchronization tools whenever practical.