Allow Data in Wires to be Forced During Development

Question

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.

Answer 1

You can workaround this today by creating a subVI that does "Open Panel When Called" that takes in a value and outputs a value. Use the dialog template that ships with LV (File >> New... and pick the dialog template) and you can whip one of these up pretty quick. Then just insert it on whatever wire you're trying to adjust.
Speaking to the longer term issue, I was on the team that worked on Custom Probes, and we discussed the possibility of a probe changing the running value. The problem is that to support this, you have to turn off inplaceness entirely. It's the same performance hit that you take when you turn on the After Probes option (on the block diagram button bar). The performance hit is so large that we can't make it something that you could generaly have available and still have LV get off the ground.
Now, there are some wires that are isolated from other wires -- wires that are sourced at independent copies of the data -- and those could be modified without needing to recompile. So we've started investigating ways of indicating on the block diagram "this wire is debuggable, but this wire is not." It's a concept that might also help with the constant folding feedback issues, etc. So far, that hasn't gone so well, but we keep trying. We really need a significant boost to the graphics capacity of the block diagram to make this viable... and, yes, resources have been allocated to bring that about someday.
This is a good idea, and R&D has noted the Kudos count. It's on the roadmap, but the mid to long term roadmap. [Note that short term = 2 to 3 years.]