Provide an option to disable auto-insert of shift registers

[MichaelBalzer]

Provide a way to either temporarily (via key press) or permanently (via a LabVIEW option) disable the automatic creation / insertion of shift registers when adding a loop around some existing code. Much like the auto insert feedback node in cycles option.

This feature generally gets it right when dealing with references or error clusters, but other times it'll connect irrelevant data together, requiring extra effort to undo and rewire. The auto-wiring also creates weird bends when connecting the shift registers. When an unwanted shift register is then changed back to a tunnel, the bent wires remain in place.

A typical use case:

[wiebe@CARYA]

Could the key to temporarily disable auto wiring when dragging in\out of a loop be reused? (Is it "w"? Not sure.) We might need a key to temporarily disable all auto-magic.

+1 from me.

[AristosQueue (NI)]

It's just as wrong to go always to tunnels, so a tools>>options setting won't help to permanently turn off. You won't know we will get it wrong until you've already done it, so an adjustment key doesn't help. Ultimately, this is just a CAR against the tunnel creation... we need to get the detection right.

[AristosQueue (NI)]

In this case, the system is noticing the pattern string in directly across from the submatch string out and making them be shift registers.

It's more a problem with the Match Regular Expression node not having its terminals aligned right. It's an edge case (literally).

[MichaelBalzer]

We might need a key to temporarily disable all auto-magic.

I'd prefer a permanent option!

It's just as wrong to go always to tunnels, so a tools>>options setting won't help to permanently turn off.

The option for auto-inserting a feedback node in a cycle exists. I don't understand why this also can't be optional.

You won't know we will get it wrong until you've already done it, so an adjustment key doesn't help.

That's exactly the problem though. I don't know if LabVIEW will get it wrong. I don't know what else it will get wrong. Even if it's right 99% of the time, I need to double check 100% of the time to see whether LabVIEW got it right or not. I feel I'm no longer in control of the code I'm writing, and instead am running around after LabVIEW fixing the code it's generating.

I know with a tunnel option the wires will always become tunnels, and there will be no changes to my wiring layout. I can then select which terminals to turn into shift registers, and adjust wires accordingly. I'm in control of my code again.

Here's some more examples of unwanted, incorrect, or inconsistent shift register creation.
This one is unrealistic and of ill consequence, but the wires are all over the shop.

OK, I'll try use the auto-shift registers to my advantage. LabVIEW has decided this case doesn't warrant auto shift registers. I'm in a situation where I've no idea what LabVIEW is going to do.

This example shows that the auto-shift register is dependent on the incoming wire location, as mentioned by AQ. Again, I'm in a situation where I've no idea what LabVIEW is going to do. I can make a best guess, but I shouldn't have to.

[MichaelBalzer]

Please do raise a CAR if it will improve the existing shift register creation. I'd still like it to be optional though!

[wiebe@CARYA]

I agree that tunnels could be bad, like shift registers. There are a few benefits to tunnels:

a) it's how it always worked,

b) they are less "destructive", they don't change the positions of the wires.

For me, it would be nice to optionally don't get the automagic LabVIEW sauce, but fall back to tunnels.

Wouldn't say no to improvement of the automagic LabVIEW sauce though.

[AristosQueue (NI)]

TL;DR: There's some config tokens in this post that you may want to use, but they won't be elevated to Tools>>Options and might stop working in the future, but they're good at least through LV 2018. Devs will file CAR if they see something they know how to fix.

Details:

MichaelBalzer wrote:

> That's exactly the problem though. I don't know if LabVIEW will get it wrong.

But we also know that always going to tunnels is wrong (refnums and error wires being the most obvious cases, but there are others). The right answer is easily found in the common cases but in the edge cases is only found by sentient-level analysis, and LV isn't an AI. Turning off the operations means LV will be wrong more often, but still not 100% wrong. So you always have to check, no matter what. The editor addresses how often you have to fix stuff and how long it takes you to fix stuff.

Regardless, there are two config tokens you may want to use. These tokens are not necessarily maintained code paths and may be removed in future releases, but they *should* work at least through LV 2018.

• SmarterAutomaticTunnelCreation=FALSE
  Defaults to true; if you turn it to false, it disables the entire feature ("selection of autoindexing vs  concatenation vs last value based on downstream types" and "shift registers instead of tunnels"). You should still get autoindexing of arrays on For Loops as that was the old behavior going back to LV 2.0.
• AutomaticShiftRegisterCreation=FALSE
  Default to true; if you turn it to false, it disables shift register creation upon creation of loop.

These are not being added to Tools >> Options because we don't intend to maintain the alternate code path. We make things into options when both versions are equally correct. In this case, we know that the "always make tunnels" is frequently wrong and is the source of bugs in user VIs when users don't know any better. We are aiming for "less wrong" because "always right" is beyond our ability to code at this time.

MichaelBalzer wrote:

> Please do raise a CAR if it will improve the existing shift register

> creation. I'd still like it to be optional though!

The devs are looking at this particular situation and seeing if they can do anything about it. It's tricky, and it may fall in the cases that require deeper analysis than we can currently provide (as I said above, there are edge cases that require true understanding of the intent of the code to pick the right pairing). But it might be a bug they can fix. If they identify a way to improve the algorithm based on the case provided here, they'll file a CAR.

[Intaris]

We are aiming for "less wrong" because "always right" is beyond our ability to code at this time.

That's a great guideline for every programmer.

[wiebe@CARYA]

I don't want it always off. It's usually great.

I want to see if it does a good job. If it did, great. If it didn't, CTRL+Z, and redo while pressing e.g. W (like dragging code out of structures). That will get me the tunnel version that is easier to manually tweak, without SRs moving the tunnel positions.

[AristosQueue (NI)]

wiebe@CARYA wrote:

> I want to see if it does a good job. If it did, great. If it didn't, CTRL+Z,

> and redo while pressing e.g. W

Hm... that might be a workable solution. I'll mention it to devs.