LabVIEW Idea Exchange

Can we get a "Loose Fit" plot axis option that actually works?

In the plot above, it's really hard to tell without squinting what the value was over time. Did it transition from 5 to 6, or 6 to 5? If you toggle the "loose fit" option in this plot, it looks exactly the same.

Can we add a property to specify something like "LooseFit.Padding"? Users could enter a percentage of full scale value, so then once the native autoscale algorithm is performed, it bumps out the y-axis min/max values by x% of the full range.

Add "Find All Instances" for polymorphic VIs. Right-clicking a normal VI's icon in the upper-right displays a pop-up menu with quick access to a "Find All Instances" item which helps greatly when navigating code to find all callers, then their callers, etc. However, when a caller happens to be polymorphic "Find All Instances" is not available and the work-flow is broken. Ctrl+F or Edit, Find can be used but the Find dialog must be manually configured: "Search for" Objects may have to be selected if Text was last used; "Select Object" must be set from a looong list of VIs. By that time, concentration is lost.

I'd love to see an option for the label of structures to be visible by default, similar to the already existing "Subdiagram labels visible by default" option.

Currently to AutoScale an axis once, you need to set the ScaleFitX/Y property to 1. However this is really just like calling a method since the value of the ScaleFit property remains whatever it was previously. As a result, I find this mechanism unintuitive and would prefer to use the invoke node to call a suitable method named ScaleFitX/Y since it is an operation that just happens at a moment in time rather than changing a property.

Current Method: Property NodeProposed Idea: Invoke Node

Hi All,

I had posted this same idea in another post but it didn't have enough clarity and was mostly misleading the forum members. I was not able to edit it that I had to post this in a new thread here. 

The Idea

I felt that it would be good to have an option to switch to the last visited case in a case structure with numerous cases when going through the cases for debugging or understanding a code. It often happens that I have to scroll through the list of cases to get to a case and then may be I'll have to check something in the top most case. Again if I have to check the last visited case, I have to again scroll all the way down to the case, which becomes a little tedious. Instead, it would have been good if we had some kind of option to switch to the last visited cases sequentially (in a right click menu of the case structure or some keyboard shortcut after selecting the case structure). 

I'm sorry if someone has already posted this in the idea exchange forum. I tried to search it but couldn't find any such posts.

Regards,
Nitz

We have the option for finding the items that doesn't have any callers in the Project. So it would be good if a "Delete" option is also available in the same window as shown below. The same option can be disabled if the item selected item is locked and can only be enabled if it can be really deleted from the project.

The "Convert Instance VI to Standard VI" right-click option on malleable VIs made me think if this technology could be used for debugging otherwise inlined VIs (and therefore also malleable VIs)?

VIs are obviously inlined without their block diagrams, so my suggestion would require two changes:

1) 'Allow debugging' must be settable in combination with inlining in VI Properties >> Execution.

2) LabVIEW IDE and RTE would have to call inlined VIs in different ways, depending on this setting. Suggestion follows:

Running in the IDE

The IDE would now create a temporary unique instance for each running inlined subVI that has debugging enabled. This would allow us to double-click on an "inlined" subVI while it's running, and have that temporary instance open up ready for probing. Settings like the 'SubVI Node Setup' dialog would now also be available for inlined VIs, if they have 'Allow debugging' on. Set 'Allow debugging' off and inlined VIs will behave as today (so no change for any existing code).

Running in the RTE

Executables are built with 'Enable debugging' either on or off (Advanced page of the Application Builder). I suggest that Application Builder builds in unique instances in place of debug-enabled inlined VIs when 'Enable debugging' is on, and bakes in ordinary inlined code when 'Enable debugging' is off. This would allow us to debug into inlined (and thus also malleable) VIs inside executables with remote debugging. Loose VIs called with the RTE would have had their inlined callees compiled with either debug capability or not, depending on their 'Allow debugging' setting as discussed above in "Running in the IDE".

What do you think - would it be nice to be able to debug inlined VIs?

If you are going to call it a developer suite, put the developer tools in it. The following toolkits need to be added:

• NI LabVIEW VI Analyzer Toolkit
• NI LabVIEW Desktop Execution Trace Toolkit
• NI Requirements Gateway
• NI LabVIEW Unit Test Framework Toolkit

Of course this will increase the cost of the developer suite. I find it easier to convince my boss to approve a cost increase versus purchasing a new toolkit.

When working with User Events as an API between modules there is a nasty little thing which unfortunately keeps rearing its ugly head.

If we retrieve a cluster of User Events (or an Event registration refnum) from a module with events we should be listening to and wire this to an event structure we get a memory leak if not all events are handled.  This particularly occurs whenever the API is extended and not all listeners have been updated.

It would be much easier to track down these kinds of problems if the Event Structure would display which User Events are in the associated Registration Refnum but are NOT yet handled.  This would be a great too in tracking down rogue Events and eliminating possible memory leaks due to implementation errors.

Currently one has to iterate through ALL of the user events and observe the warning "this event is handled in another case" in order to find out if all have been handled or not.