LabVIEW Idea Exchange

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

LabVIEW has nice debugging window which is very helpful for DLL debugging purposes. It's able to output numeric variables, strings, LV paths and so on. But it also lacks some standard functionality that makes it not very comfortable to use. Currently this window looks like that:

 

DbgPrintf window

 

First main disadvantage of this style is that the window has no scrollbars so we can only see last 24 rows of text. Older strings are completely unavailable if they are not cleaned up from memory at all. Second disadvantage is that user cannot copy or export that debug text to clipboard or text file. It's especially important when working with large numbers or complex data which is hard-to-remember and hard to rewrite by a hand. And third disadvantage is that the window misses some standard elements which almost any window has: minimize/maximize buttons, right bottom resize corner etc.

 

Because of these drawbacks I'm forced to give up this DbgPrintf function and use standard Windows console window (AllocConsole / FreeConsole from WinAPI). That requires additional work in the code and not so easy to use as the mentioned function. Also it's not cross-platform way of debugging.

 

So, it would be perfect if that window looked like that:

 

DbgPrintf (new look)

 

As you can see there are new abilities of the window:

1. It has both horizontal and vertical scrollbars, so all the text can be read;

2. It allows to select the text and copy/export it to clipboard or .txt file;

3. It has minimize/maximize buttons on the title bar;

4. It has right bottom resize corner which is used to change window size;

 

That's the basic functional but there may be some additional settings for window appearance or for ease of debugging.

Adding value or led indicators in block diagram to make easier debugging.

It would be handy of the palette editor removed the file extension automatically on the short name when added.

 

Palette names suggestion.png

And when you open an old file in a new version, do the opposite. 

 

 

Such a bizarre thing not to be implemented! 

In addition to these ideas that suggest saving FP size and position for run-time

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/We-need-to-uncouple-the-quot-edit-mode-quot-FP-size-from-the/idi-p/917235

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Remember-user-selected-window-position-and-size/idi-p/2055654

It would be nice to have a tool to precisely control window size and scroll of the pane (not only window position). Sometimes it is hard to set them with pixel precision.

Ctrl key plugin to try (Ctrl+X) is attached. Works only with single pane VIs for now.

Double clicking a reentrant defined Vi opens always it clone instance. But nearby most of the time i have to edit the function and thus need the original VI open instead of the cloned instance.

It would be comfortable if you add an entry in the context menu like 'Open Prototype VI', so i don't need the navigate through the project explorer to the desired VI for editing.

I would like to see a new vi's suggested name contain the text that was placed in the icon.

 

Icons have four fields: Line 1 text, Line 2 text, Line 3 text, Line 4 text.  Suppose the text in the icon is "parse" "new" "text" "file", I would propose that when saving a new vi instead of suggesting "untitled #.vi" it would suggest "Parse_New_Text_File.vi".

 

No text in the icon fields?  no problem, stick with "untitled" in that case.

The scroll bar in the string constant is literally useless since whenever I try to scroll things inside the string constant the constant moves and not the content. So it would be good if the user focuses the mouse pointer in scrollbar and makes a click the string constant should not be selected letting the user to scroll the text inside the string constant.

When you have a probe to se the data in an array, you se all elements in one row (in the Value column) and just one element in the Probe Display area. If you have a large array, it is difficult to get a good overview.

 

My suggestion is that in the part of the probe window called Probe Display, you should be able to pull the bottom right corner and see several elements simultaneously.

 

Probe 4.png

 

An extra feature would be to also show the array size anywhere in the probe window.

I'm manually building a cluster constant because it isn't figuring out what I am feeding in.

 

When I go to click on the wires, the "error" indicator makes it more dificult to specify the proper wire.

 

Something should be done during mouse-over that allows the wire line to be on top of the error (triangle-X-triangle) icon.

 

Capture.PNG

Hi All

Not sure i am the one who is providing this suggestion

 

Hope everyone is aware that Read Write Spread Sheet string has been updated with different names, i hope that it serves the purpose of earlier Functions too.

When we are trying to open a code 2015 which is developed in earlier versions Read and write spread shett string shows Red cross mark.

 

Though it works without any issues it will be good if it automatically gets updated with New VI's. if its left as it is just not to create a conversion from 2015 to 2014 the same technique can be followed.

 

 

 

.Spread Sheet String.PNG

In any useful drafting program they have a "create array" and they aren't meaning a numeric creature.  They mean a geometric array.

 

References:

 

An advanced user menu for Front Panel should allow arrange of objects similar to how CAD tools do. 

 

In particular - if I have 81 items, I should be able to arrange them in a 9x9 grid array with ease.  I don't get to pick that I have them, btw.  

 

If I programm a VI with a statemachine pattern I have to use a type def control. This is stored in a seperate file on the disk. If I copy this VI to an other project I often forget to copy the control file. This often causes problems. It woluld be fantastic to have the opportunity to bond or integrate the control to/in the VI.

It would be useful if there was functionality within the VI Analyzer, under the style section, that checked for overlapping on the block diagram. This would allow you to be able to check readability and check for some mistakes. For example, it is possible to copy and paste while loops on top of each other. VI Analyzer should be able to tell you that there are 2 while loops overlapping to help with style and debugging. 

Wiring the blocks feels difficult especially for large program and also the block diagram crowded with wires. I would like to have "On page connector" feature in LabVIEW like that in Multisim. I feel it to be a very important feature, please vote this idea if you feel the same.

An old topic but perhaps a new flavor.

I always set error in to required when connecting it to the lower left terminal on the connector pane.

By this I get rid of the so detested "(no error)" part of the control name, and it prevents you from being lazy and not connecting error in for situations where you think it's of no use, but you actually would be better off doing so. It also prevents an unconnected error thread passing through behind the icon, giving the impression that error in is connected when it's not (I've seen this once; quite a nasty bug).

In the few cases where I really don't want (or have) an error thread connected to the VI, I use a home made No Error Constant like this:

No error.PNG

So, I would like to have this Right-click option on the error in teminal to simplify this:

 

No Error Constant II.png

 

A big bonus if NI makes it a constant and uses my minimalistic artwork for the icon 😉 instead of inserting an error ring with 0: no error.

 

/Lars-Göran

Shrinking the dialog height seems buggy.

The folder navigation disappears too soon and leaves loads of wasted space instead of just shrinking the folder/file view.

Save as wasted wasted space.PNG

 

This is the minimum height before the file/folder view disappears:

Min dimensions.PNG

 

The dialog minimum width also seems large for no discernible reason (controls wounld't be clipped even if smaller).

There is no way to add programmatically a 2nd y axis. Need it to display same data with different units on left and right y axis but currently there is no way to add a 2nd y or x axis programmatically.

Normally setting the property "blinking" leads to slow blinking at a fixed time intervall of front panel elements. In automated processes you just want to give the user feedback which knob or parameter was changed by your state machine or other processes. So a short blink (e.g. 50ms) can do this job to pay the users attention. If you set and unset this property e.g. in a consecutive sequence structure you will not notice any colour change of your front panel element.

 

LabView 2015 doesn`t support this feature. You have to program workarounds (e.g. with FGV`s) which either leads to unwanted pausings or interruption of your program.

 

So, a new property node for triggering one short blink at a selectable time would be helpful.

If you have a project where a VI is used on multiple targets, and contains conditional disable structures that vary between the targets (loading Vis that are not compatible with all targets for example) - you may see application build previews fail until you open the affected VIs on the relevant target just to get LabVIEW to update the conditional disable structure.

 

The actual build is smart enough to do this, but the preview function is not. This has the funny side effect that installer builds can fail when the relevant application builds suceed; because the installer will run a preview on the application builds even though they are already successfully built, and then fail because the preview will fail.

 

Now, I'm sure the installer build's use of the preview has its good reasons so I will not suggest to remove that, but rather suggest that the issue is resolved by making the preview functionality smarter; If (and only if) it runs into trouble when generating the preview, it should do the same as what the actual application build is now able to do; load the troublesome VI - and see if the issue is easy to resolve on the fly.