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.

[altenbach]

Excellent suggestion. I remember suggesting something like that about 10 years ago. Basically a probe to inject data into a wire. This seems to be along the same lines.

We would simply need a new type of custom probe that inserts itself into the dataflow, i.e. the data needs to travel from the wire in and out of the probe and then back into the wire, breaking the normal dataflow. The rest we could do ourselves by making a custom probe. (Of course pre-made probes should be available for simple datatypes)

Now debugging can be made more interesting and we can play "what if" games while the VI is running. We could throw an error into a wire to see if it is handled properly. We could test what happens if one of the values turns to zero, or negative, we could stop an infinite loop by forcing a termination condition, etc, etc.

 I would probably find a use for it :D.

Message Edited by altenbach on 06-13-2009 10:32 AM

[lsn]

This is too good suggestion. This would save much time while debugging. One can also avoid switching between fron panel to block diagram for entering input values and viewing the highlight execution.

[Noel]

I'd like to implement something like this where a user can force error and warning values at run time to test their error handling routines. 

[JackDunaway]

Great! We've got some Blue Support!

Well, Noel, can you make it generic so that we can force ANY datatype... not just errors?

[AristosQueue (NI)]

You wouldn't be able to drop one on a running VI -- dropping one would cause the VI to be recompiled in order to isolate the wire so that it doesn't share memory with any parallel branches or share upstream with constants and/or control default values. Essentially the inplaceness and constant folding that LV normally applies magically behind the scenes would have to disappear for that wire. I can't come up with a way to allow this at run time. Everyone ok with that restriction?

[JackDunaway]

PERFECTLY OK with that restriction!

Edit:

You can hardly even call that a restriction. Forcing a wire is a very deliberate action... you typically are aware of the "what if" scenarios you want to test prior to running. One might argue that you may even impose that restriction... plan the test before you run.

Message Edited by mechelecengr on 08-21-2009 12:45 PM

[AristosQueue (NI)]

The only reason I say it is a restriction is that the following is useful in debugging in other languages:

1) Run code.

2) Wait three hours until you hit desired breakpoint.

3) Check value of current variable (wire).

4) Decide that the value is wrong. File a bug report to the person who has to fix the upstream code.

5) Change the value currently in the variable (on the wire) to desired value and continue execution without having to stop your program and wait three hours again.

[JackDunaway]

That's a pretty severe case, way out in the tail of the .001% of code distribution. I would venture that 95% or more can have "instant gratification" (less than 5seconds) between hitting run and forcing the wires. 4% could be forcing within a minute, .5% could be forcing within 5 minutes... and so on.

The most obscure code I have ever debugged has taken no longer than 6 minutes between hitting the "run" button and then watching the probes. (I know because it was earlier this week!)

The point I'm trying to make is, yes, you're right, this feature is completely useless if you have to wait 3 hours and you chose the wrong wire to force (or didn't have a force set up, because you didn't know you would want one). But don't let that obscure case have too much of a negative impact when deciding whether this idea is worth implementing... it would be useful 99% of the time for 100% of LabVIEW programmers.

Message Edited by mechelecengr on 08-21-2009 03:54 PM

[JackDunaway]

To amend to my previous post: I may want to tweak those numbers to include a larger percentage of people who may have to execute for a longer period of time before coming to the code they want to force. It's not necessarily a function of how long it takes their code to reach a certain execution point, but they may just have to wait on an external trigger in the process or stage in the experiment (e.g., waiting a couple of hours for a temperature to stabilize). The longest continuously running experiment I have conducted took about 6 hours to slowly raise an oven to 2000F. And like Aristos said, I would have had to wait 6 hours before getting to the "interesting things" that I would want to do some "what if" scenarios on. 

Regardless, still an immensely useful tool, even if it is only available to set up "force probes" in edit mode.

[Damir]

Excellent idea. But there are security issues on RT systems. You could launch strategic missile with unlucky click!!! It should be protected with "are you really really really sure???" and setting to explicitly enable this option. If it is not possible in run time, it can be done with simple inserting case and control in edit mode. I use this all the time (takes time). But at run time, I would give the kingdom for it... But anyway, I agree with "still an immensely useful tool, even if it is only available to set up "force probes" in edit mode". Idea is good Kudoed, so I'm looking forward too see it in LV 2009.0.1! By the way, where is humor in LV forums? We are working with joyful tool.