LabVIEW Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

Problem: Currently it is impossible to know in advance what errors (what error codes) a node or native VI can produce. (Native VI = VI that ships with LabVIEW)

 

For example, I recently implemented a module that communicates with another endpoint using the LabVIEW TCP primitives we know and love: TCP Open Connection, TCP Read, TCP Write, TCP Close Connection. In order to create robust software I needed to understand what error codes each of these primitives can generate, and in what circumstances.

 

Through initial testing I discovered that TCP Open Connection can generate errors 56, 62, and 66. I then handled these errors locally in the code.

 

Around two weeks later, during further testing of what I thought was a fully complete and tested module, the module unexpectedly started experiencing error 60 many times per second. The module had never experienced error 60 before. The module was configured to broadcast an event each time an error was detected. This flooded the listener (the DQMH tester VI that was listening to all broadcast events) with thousands of error messages per second. The tester VI front panel buttons became unresponsive, because the tester was flooded with so many incoming broadcasts. The only way to break out of the cycle was to abort the tester, then close the project to shutdown the module.

 

This way I learned "the hard way" that that TCP Open Connection can generate error 60 in certain circumstances, in addition to the error codes I had handled already.

 

Solution: The detailed help of each node and each native VI should list all error codes that can be produced by that node or VI. For example, in the case of TCP Open Connection, the detailed help should contain a description similar to the below.

"

TCP Open Connection can generate the following errors:

  • Error 56
  • Error 60
  • Error 62
  • Error 66
  • and so on listing here any/all error codes that can be generated by the node.

"

 

This list would be extremely useful, as it would make us (professional LabVIEW programmers) aware of the various error codes a node or VI could occur generate. This would encourage the programmer to think of ways to handle all those possible errors, thus resulting in more robust code.

 

By reading the "Explain Error..." message of each error code the programmer could also understand the circumstances in which the node or VI generates each particular error.

 

Notes

  • In summary, this idea suggests an improvement to the detailed help documentation of each node and native VI.
  • It should be possible to automate the creation of the lists for each node and native VI.
    • For nodes whose source code is written in C++, a program could be created to scan the source code files and return the list of possible error codes generated by the function.
    • For native VIs, VI scripting could be used to achieve a similar purpose and output the list of errors that could be generated by that VI.

I am currently struggling with the issue that the shown knob permanently triggers "Value change" event as long as the user has not finished adjusting it yet (left mouse button is still pressed). This may be an intended behavior, but it is not in my case.

For boolean elements, there is the configuration option of "Mechanical Action". For strings, there is the option "Update value while typing". However, there is currently no such option for numerical elements.


Therefore, I would like to suggest the following:
Add an option "Update while adjustment" - true by default, so it acts as it do currently. If this option is set to false, the "Value change" event would only be triggered after the input is completed by the user.

The situation:

There is a user interface that provides the user with an array control.

The array control provides the user only one or a limited number of elements.

The user must use the scroll bars or the index control to select the correct element that he wants to modify.

 

The problem:

The user can scroll to a position beyond the last available array element and enter data. This increases the size of the array as expected, but not as desired in the given situation.

After the user finishes entering, the program must check the size of the array and reduce it again.

The proposed solution:

There should be a "max. array index" property of the array control. It should prevent the user from scrolling to a position beyond this maximum element index and/or editing such a position. It should also prevent adding elements via the right-click menu when the maximum number of elements has already been reached.

 

Extensions:

There could also be a minimum property that prevents the user from deleting array elements so that the total number falls below the minimum.

 

Notes:
The proposed solution should only affect the user's input capabilities. It should not change the size of the array if it was specified programmatically.

Suppose that in the scenario seen below we would like to merge the error out terminal of VI 2.vi back into the main error wire. This is, of course, a common programming pattern.

1.png

 

 

 

 

 

 

 

 

 

Currently we would need to insert a Merge Errors node into the existing wire (Pressing Ctrl + Space, typing "erg", then Ctrl + I is probably the quickest way to do this), then wire the error wire as desired. Currently creating a wire from the error out terminal and ending that wire onto the existing error wire results in broken wires, as seen below.

2.png

 

 

 

 

 

 

 

 

 

It would be useful to have an option that specifies that a Merge Errors node would automatically be inserted in this case. That option could be named something like "Automatically insert the Merge Errors node when suitable", and could be located in the Tools >> Options... menu alongside options such as "Place structures with Auto Grow enabled" or "Auto-insert Feedback Node in cycles".

 

When the "Automatically insert the Merge Errors node when suitable" option is ticked, a Merge Errors node would automatically be inserted in the scenario described earlier, as seen below. This would save the few seconds required to execute the Ctrl + Space, "erg", Ctrl + I sequence.

3.png

 

 

 

 

 

 

 

 

 

 

Notes

  • I would be happy if the default value of the "Automatically insert the Merge Errors node when suitable" option would be unticked, which would maintain the current default behaviour.
  • Even if the option would be ticked (enabled) by default, I think it would still make sense from a usability point of view. I suspect that the number of times people intentionally use this feature would be greater than the number of times that people wire error wires together by mistake and would wish for the wires to be broken.

Thanks!

It would be nice to have some sort of overlay on the Controls and Indicators that are hidden on the block diagram, to quickly see that its hidden on the FP.  Add a black frame or grey out the background.  

ScottOHara_0-1722868772543.png

 

 

If you have an event that contains a cluster typedef, then the event structure automatically unbundles the data:_carl_0-1633037893996.png

I generally want to work with the entire typdef though. Why not expose the entire typdef to improve code maintainability?

 

(No one wants to re-bundle that data just to send it to a subVI or new event...and then risk losing data when a new property is added later.  Workarounds include adding a typdef of a typdef, or going class-based...but that overhead/creativity shouldn't be necessary.)

 

I would like to have the possibility to "negate" some comparison functions such as "Empty String/Path?". This can avoid to add the "Not" operator.

The picture below is a possible implementation. The dot on the input (on the output ok also) is showing the negation.

Labview Idea.png

This might be good to be implemented for the following functions:

Labview Idea 2.png

Hi,

 

Sometimes we have to check the execution of just a part of a long VI and I use to do is:

- set a breakpoint just before the part,

- run the VI,

- wait for the breakpoint,

- set highlight

- and follow the execution.

 

I believe that would be nice to set the highlight just like breakpoint clicking over the wire and, when the execution reaches it, show the execution.

 

LV_Lamp.jpg

CTRL+Click on an input is a great little tool to switch the input.

 

However, it only works when both inputs are wired. Often (, I or QD connected a wire wrong,) I feel like switching the input, before wire-ing the 2nd. Only to find it doesn't work...

 

Having to connect the 2nd wire just seems to disrupt the flow, being focused on the first input. Being forced to make things worse (connect two wrong wires) before being able to make it right just feels itchy to me.

Switch one wire.png

 

It's a minor thing, but I never understood why it would be limited to 2 wires.

I use Error Rings for custom errors and I love it.  Being able to reuse existing codes but give addition information, or using extra string or numeric inputs makes my code more compact and readable.  But one thing I noticed is that if I perform a search in LabVIEW, it won't look at the text in the Error Ring.  Here is an example.

 

Error Ring Search 1.PNG

Even though my Error Ring contains the text "table" and it is even shown in the node, the LabVIEW search returns nothing.  There are times that my users get an error and they send it to me.  Then I will search for that text in my project only to find it isn't there.  But it is actually there, just hidden away inside the XNode that is the Error Ring.

 

Can we improve the LabVIEW search function to search inside Error Rings?

One of the things that sometimes bugs me when using LabVIEW is that if you have a front panel or block diagram in a small window, many of the menu options and toolbar options are inaccessible without having to resize the window first. You have to have a minimum window size to be able to access all of the toolbar functions.

 

Still don't get it?

 

This is how big I want my SubVI window to be:

2014-10-01_13-24-54.jpg

 

Problems with the above:

  • A lot of the toolbar buttons and menu options are completely inaccessible
  • I'm sure it was for good reason (probably some other icons that appear there), but there's also a load of empty space to the left of the run button which would allow me to fit more of the toolbar on screen

To be able to access the entire toolbar, the windows has to be at least one of the following wide:

2014-10-01_13-25-13.jpg

 

 

Why is this a problem?

 

  • Normally my front panel windows are nicely sized according to the controls and indicators on the front panel (e.g. controls top left, indicators top right, error clusters bottom), for most SubVIs this usually means that the window is thinner than the minimum width to show all of the toolbar options.
  • If you have a fixed size UI panel (e.g. for dialogues) - if you want to align / space objects on the panel you have to make it larger, do the scaling and then resize back to the original size which isn't ideal (possibility for not resizing to the original size correctly)
  • Similar to the above but if you have a UI where you have fit/scale to pane you might want the initial size of the UI to be smaller than the minimum width

Existing workarounds:

 

  • Just before submitting this idea I realised you can shrink the 'search' bar from the toolbar to make it slightly better2014-10-01_13-25-38.jpg
  • Use the OpenG (?) VI for 'fit to largest decoration - this is OK for some UIs but not really suitable for the SubVI case above

Proposed solution:

Please make it so that the menu and toolbar are accessible regardless of window size. One solution would be to have a button that allows you to 'scroll' the toolbar or have a pop-up dialogue that shows the missing toolbar buttons as per the image below.

 

MS Paint skills (icon lifted from Chrome's bookmarks bar):

2014-10-01_13-24-54_fixed.jpg

 

As an aside, MS Word manages it fairly well (even though it isn't that readable), and it has a LOT of toolbar buttons:

2014-10-01_13-44-07.jpg

 

Please consider my idea (or Kudos it) for future versions of LabVIEW - it will improve usability of the IDE.

When wiring to a growable node that is currently full requires you to either pull the node bigger first and then wire or wire and create a wire stub, then pull it larger and the Connect the stub to the terminal. 

Instead change the behavior so, if wiring is started and ends over a growable node, the node will grow automatically and add the wire being created to the new terminal. 

For example: starting an error wire and ending on a merge that is currently full, the node automagically grows by one and adds the wire to the new (last) terminal. 

Compound arithmetic allows you to invert inputs or outputs. I find myself often checking for a string or path to NOT be empty. It would be nice to be able to invert the output the "Empty String/Path?" function instead of needing to wire up the additional "Not" function. It would look kind of like this:

Empty String Path NOT.png

Thanks!

When a string control, indicator or constant is switched from any mode other than Normal Text, display a small glyph (similar to the radix indicator on numeric controls) to allow you to see that the display is something other than Normal Text.

 

New String.PNG

 

I'm not sure if this is a bug report or a feature request, but I think it should be fixed/implemented, all the same 🙂

 

If you right-click on a Boolean funtion (And, Or, Exclusive Or, Not, etc.) and replace with a Compoint Arithmetic (CA) function, the CA function is always set to the "Or" configuration.  I would expect it to be smart and put the CA node into a configuration (including negation/inversion dots) that is equivalent to the Boolean function that it replaces.

 

Replace with CA.png

Many times a while loop needs a delay for one reason or another, even if its just to add a small delay so the program doesn't peg the processor.  Having this would clean up BDs, and it would also act as a reminder to make sure your code doesn't peg the processor.  (with nothing wired to it, it would default to zero)

Built In Delay into While Loops.png

Sometimes when dealing with the Bundle/Unbundle by Name nodes, I start with more elements than I actually end up using. Then, my block diagram looks something like the following:

 

bundle by name with unused elements.png

Maybe I'm just lazy, but I really hate removing each unused item from the Bundle/Unbundle by Name node over and over. Right click on unused element, click "Remove Element", Right click on next unused element, click "Remove Element", etc... Ugh!

 

So I'm suggesting a "Remove Unused Elements" when you right click on a Bundle/Unbundle by Name nodes. With this option, right clicking on one of these nodes would look like this (emphasis added Smiley Wink 😞

 

remove unused elements.png

The result of this operation would look something like this:

 

BAM.png

Now I can spend my time coding instead of getting rid of individual elements! Smiley Happy Thoughts? 

The context help for this large typedef would be more readable if the nodes were collapsible like the XML viewer for Internet Explorer.

 

nodes.JPG

It would be a small yet very welcome improvement if the 'size to text' option could be added to the enum and ring options when in arrays rather than having to manually adjust them.

 

Enum vs Combo box.PNGHere we have a combo box vs enum in an array. Both contain identical lists which consist of the following: Enum List.PNG

 

Now if you right click the combo box you get the option to size to text: Combo List Option.png Right click the enum and you don't: Enum in Array Right Click.PNG

 

Also, when you 'size to text' on the combo box list, it sizes to the item you selected rather than sizing to the longest string as shown here: Combo Box Not To Longest String.PNG

Yes you could argue that it did exactly what you asked but my preference, and I'm sure others will agree, that it would be best to size to the longest string. Maybe have two options in the list. 'size to current element' and 'size to longest element'

 

 

Regards

 

Mitch

First of all I know this may sound crazy, but I do have a specific use case (2 actually) and I think it generalizes well.

 

Use Case

Caraya uses a Quickdrop shortcut ctl+u to run all unit tests in your project. I have a quickdrop shortcut that I use to run VI Analyzer on just the files that have changed in Git.

 

Both of these shortcuts are incredibly useful. However it requires having a VI open. There are often times when I just have a project open and want to use one of these shortcuts. For example when I first open a project, I often want to run the tests first thing. I realize you can add these type of things to the tools menu, but then I have to memorize 2 different ways of doing something depending on context. It would be much easier to use the QD shortcut here.

 

I realize  that QD is typically used for dropping objects (on the bd and fp) and that doesn't really make sense from the project. But these shortcuts (and I'm sure there are others) don't rely on that functionality. Also you could adapt QD to act on highlighted project items or allow you to "drop" a new VI or class or library or something.

 

I mentioned it to Darren and he mentioned it would require the C code changes to allow the project window to capture the ctl + space event. The project window already does handle some ctl key events. Apparently ctl + space seems to be unhandled. I'm sure there is probably more to this idea than simply that, but I feel like it is worth exploring.