LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Top Authors
cancel
Showing results for 
Search instead for 
Did you mean: 

Allow Data in Wires to be Forced During Development

Status: New

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.

 

DataForcing.png

 

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.

 

ForcingImplementation.png

 

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.

Wirebird Labs: Expert Toolkits for LabVIEWDeploy, by Wirebird Labs: Expert Toolkits for LabVIEW
32 Comments
Knight of NI Knight of NI
Knight of NI

I don't want perfomance affected by this change. If it slows LV down one notch, it is too much!

 

So only implement this idea IF it can be shut-off.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Active Participant
I just tried to create a custom probe but it only appears to allow inputs. When I wire up an output, instead of changing the value to the output, the custom probe disappears. Is there a way to configure the probe as an inline value changer?
Trusted Enthusiast
Ben, I would give up two or three notches in development mode for this feature. Of course, any overhead would be stripped in a built executable.
Wirebird Labs: Expert Toolkits for LabVIEWDeploy, by Wirebird Labs: Expert Toolkits for LabVIEW
Knight of NI
One issue that also needs to be addressed is wire branching. The current probes can be placed anywhere but here the outcome potentially depends on where the probe sits (before or after a branch). It should be implemented in a way that this probe must sit at the original source for the entire possibly branched wire harness. Such a probe would always change the data in the entire wire connected to the probe (upstream and downstream).
Message Edited by altenbach on 04-21-2010 12:49 PM

LabVIEW Champion. It all comes together in GCentral GCentral
What does "Engineering Redefined" mean??
Trusted Enthusiast

Yes, good point, altenbach. For instance, take a look at the original illustration. The location of the forced signal (or injected signal, if you may) would placed be as it is currently illustrated regardless if you clicked near the sink of the large Unbundle, near the sink of the Bundle, or most appropriately clicked before the junction.

Wirebird Labs: Expert Toolkits for LabVIEWDeploy, by Wirebird Labs: Expert Toolkits for LabVIEW
Trusted Enthusiast
Trusted Enthusiast

This calls for a "force copy data for each wire branch" node... which exists already: VI of the Day (10/15/200​9) - Always Copy

As in:

 

ScreenHunter_001.jpg

Proven Zealot

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.]

 

Active Participant

This sixclear VI High tutorial shows how you can kinda get this behavior using suspend when called.

 

No I'm not suggesting this is as a solution to this idea.  Just something I hadn't known about until that video was published.

--
Tim Elsey
Certified LabVIEW Architect
Trusted Enthusiast
Trusted Enthusiast

That's cool.

I tried it on a random VI of mine making a call to "Ramp Pattern by Delta", setting the subVI node as "Suspend when called" and when I tried typing in something in the output, I got this:

 

ScreenHunter_001.jpg

 

That's not so cool...

Trusted Enthusiast
Trusted Enthusiast

I forgot to mention that this nicety is only visible if you have the "DWarnDialog=TRUE" flag in your ini file.