Allow Data in Wires to be Forced During Development

[JackDunaway]

Currently, you can place a probe on a wire while developing, which is an indicator of the data on a wire. I want the ability to CONTROL the data on the wire, with a data forcing mechanism.

The implementation would be very simple... right click on a wire, and in the context menu the option "Force" would be right under "Probe." It would pop up a window of the forcing control, and while the VI is running and forcing is set to "Enable", the programmer can control the values that pass on the wire. If the force window were set to "Disable", the data in the wire would be completely controlled by the VI's logic.

I think the implementation by NI could be trivially simple. If you only allow a forcing control to be added during edit mode (not while the VI is running), the force could be added as an inline VI (as denoted by the green rectangle on the wire). The code inside the inline VI would be as follows, and the front panel would be "Data Force (1)" as shown above.

Of course, if you could add a force to a wire during runtime like probes, props NI. But I would be PERFECTLY happy if you could only add these force controls in edit mode prior to running.

One level further (and this would be AMAZING, NI, AMAZING): enable and disable certain parts of the cluster that you would like to force and allow the other elements to be controlled by the VI logic. I made the example above because it would be very natural to ONLY force Sensor1 and Sensor2, and letting the output run it's course from your forced input.

[AristosQueue (NI)]

DWarns are states that we don't expect to occur, but if they do, we know how to correct for them. They generally indicate merely a place where the UI could be more performant (because if we never went into a given state, we wouldn't have to work our way out of it) or that may be an issue for future features that don't yet exist. In general, ignore them (but please do let LV send information back to NI when you're promted since it helps us improve the product for the future).

[X.]

Not that I want to hijack the thread, but in answer to Aristos Queue: I am an avid LabVIEW crasher of sort and I was told to insert this flag in my ini file to help NI sort out those crashes. Then, as a side "benefit", I started getting all sorts of .cpp error warnings (like the one I just mentioned), which - I think- resulted into additional LabVIEW error reporting requests (which I keep sending, unless this is a recurring warning).

Warnings are a small annoyance in the sense that after clicking the OK button in the pop-up window, LabVIEW resumes execution. But to get back to Aristos comment: why is NI support then getting back to me with requests for more details about the circumstances of these warnings if you guys know what to do about them?

[AristosQueue (NI)]

X wrote:

> why is NI support then getting back to me with

> requests for more details about the circumstances

> of these warnings if you guys know what to do about them?

There's a difference between "we know what to do right now in the heat of the moment to set things right again" and "we know how to keep this state from ever happening in the future." DWarns indicate that somehow LV got into a state we never expected, but we have some compensation code to put things right again, but it might not be what the customer wants (like aborting an edit transaction that goes insane). The VI is fine, the user didn't crash, they can keep working, but it wasn't the right experience. We get more info from customers willing to share that info because it lets us figure out how that state happened in the first place.

Often DWarns are added when we find a crash but it isn't a reproducible crash, and we find a way for LV to keep going but we still want to determine how we got into the crashy state in the first place.

I hope that explains the distinction... and thank you for providing those follow-up details.

[kdnelson]

This idea was posed in 2009 and one of the comments said it was in the "mid-range" plans, with "short range" being 2-3 years.  This puts it right in line for implementation Real Soon Now!

I haven't seen my preferred embodiment in the comments, so here are my 2 cents.  Note, I have given some thought to how to deal with wire branches and constant folding.

No new style of probe is required for this feature!

When a probe is applied to a wire, the probe window appears.  If this is an isolated wire, the probe value is displayed in the window in a control.  This allows the value to be edited.  If the wire has branches or other side effects, the value is displayed in an indicator.  However, there is an option on the pop-up menu "allow editing."  If the user is willing to accept the side effects, he or she can allow editing and change the probe to a control.  Optional: all the affected wires turn red in the diagram.

If the user wants editable probes without side effects, and to allow editing of "difficult" wires (perhaps those with constant folding are particularly difficult), there is an option in "execution" windows of the .vi properties.  Underneath "allow debugging" is a sub-option "all wires are independent."  This option disables all optimizations and allows all wires to be edited.  When debugging is finished, this option is turned off to restore optimizations.

What happens when a probe is used: when running normally, probes transfer their input value to the output and nothing changes.  However, if the probe is a breakpoint or when single-stepping, the execution stops just after the probe is updated.  At that point, the user can change the value in the probe window.  This updates the actual memory location used by the wire, so the .vi proceeds using the new value.  If there are multiple readers of that memory location, this causes side effects, which the user accepts.  (But this can be eliminated with the option described above.)

Hope to see something like this soon!  Thanks.

[DanRichards]

In my current medical device project, we have a test team that takes our releases and check for bugs. They require support for 'white box' testing to manipulate variables to ensure that the software responds correctly. The folks in the test team are more comfortable in C-based environments, where it is more common to see the ability to force a new value when the software reaches a breakpoint. To make a distinction, in that paradigm, there are two build outputs - the main binary and the debuggable binary. It would be nice to deliver LabVIEW binaries in a similar paradigm to them so they don't need as much (or any) custom design to perform white box testing, which comes with the added benefit of knowing that the non-debuggable source is the same as the debuggable source.

With zero understanding of how difficult this would be to implement, perhaps a starting point would be to enable this functionality whenever 'enable debugging' is selected in the build specifications. To reiterate, the benefit is that we wouldn't need two versions of source code to create two versions of the executable (one lean and one debuggable). The alternative is custom design, which creates the need for additional risk mitigations.

I don't mean to suggest that NI should simply copy other environments, but rather sharing my perception that some of the existing paradigms out there have tangible impact on how design outputs can be used in design for high-reliability applications.

[Philipp_Elhaus]

This has been first proposed 10years ago - has there been implemented anything like that by now? 

[AristosQueue (NI)]

We have returned to this idea many times over the years. We have never found a good way to implement it. LabVIEW's entire design for thread safety is predicated on the idea that *nothing* but the upstream node can set the value in a wire. A regular probe is just an other downstream reader of the data. But a probe that can modify the value constitutes a second writer, and trying to inject code that pulls the value out, freezes execution for a while, and then writes it back into the location, has proven tricky. There's a heavy risk to the whole execution stack from adding this feature. We leave the idea open as a constant itch to remind us that we want this to work, but it hasn't made headway in a while -- it gets deprioritized in favor of other just-as-significant features that we actually know how to implement.

[JonP]

@AristosQueue: would it make like easier for you if the only values we could force are the current wire values when stopped at a breakpoint? For me, that is quite a common condition: set a breakpoint, find that the current wire value is bad (usually on the wire that has the breakpoint) but have no way to check that a different value works without fixing the problem and trying again, only to find that I didn't quite work out the corrected value properly, repeat N times... So you (NI) would only need to force the value once on the wire's current value when the VI is suspended, which must be in memory somewhere.

Of course this is not an ideal solution especially if the breakpoint is in a tight loop, but it would be a lot better than nothing.

[AristosQueue (NI)]

JonP: More than help, stopped at a breakpoint is the only time we think it might be viable. 🙂

[JonP]

Great, go do it then