LabVIEW Idea Exchange

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

This is a "repost" of an idea back from 2009 - I would like to see if it will get any traction now.  

Original idea Here

 

I have been using the DETT pretty extensively for the last few weeks, and would love to see some simple usability improvements with a few additions for automation.

1. Better handlling of arrow up, arrow down and page up/down key strokes.  It is very jerky when scrolling through pages of a long trace

2. Addition of a search function - especially for user defined strings.  I use them as placeholders to indicate where I am in a sequence of events, and having an easy way to find them would be great.

3. Rolling save of logs.  It is way to easy to run out of memory and lose a trace.  Having a way to automatically stop and save a log and start a new one would be a great way to automate data collection.  Here is a screenshot of how Wireshark does it:

 

Wireshark capture options

 

Feel free to add more thoughts, these are just a few of my major ones.

 

Rob

VI Analyzer has a spell check ability (woo hoo!!)

You can even add custom words to a custom dictionary, for the case where you have a need to.

However, for a out-of-the-box spell check system for an application used heavily by the Test and Measurement community, I was very discouraged I needed to add words such as

Agilent

GHz

preamp

to the custom dictionary to stop getting them flagged as misspelled.

How about a standard out-of-the-box dictionary refresh to include technical terms commonly used in T&M applications?

LabVIEW should ship with a Set Operations palette item, including the common operations such as Union, Intersection, Complement, and Cartesian Product, as well as more advanced operations that I don't know about. These operations would act on 1D arrays of almost anything. Floating point numbers and those would have to have some kind of "error in value" input that defaults to the machine epsilon or equality checking. Output would be a 1D array on the input datatype with the values, and perhaps an output for matched indices.

 

Yes, these are quite easy to make yourself (loop+search), but I think that it would be beneficial for the community for NI to provide it. The VIs found at http://zone.ni.com/devzone/cda/epd/p/id/3929  are... Interesting, to say the least. NI might be able to provide better performance, too.

One thing I like about using Project Libraries is the ability to configure an Icon for the library that is overlaid on all of its new VIs. If you change this icon, you are asked, whether you want to apply this to all the VIs in the library. Unfortunately, once you have created the icon, there is no simple way to re-apply this icon to VIs and CTLs that you have added to the library. You can work around it using a few property and invoke nodes to programmatically call the proper method, but a simple button on the 'General' page of the library properties would make things a lot easier.

Rewrite the CAN Frame API library by using the 4x2x2x4 connector pattern for each VI.

 

Currently, the 13 (thirteen !!!) patterns (4x2x2x4, 4x2x2, 4x1x2x4, 4x1x1, 4x3, 4x2, 3x1x2, 3x4, 3x3, 3x2, 2x4, 2x3 and 2x2) lead to wire bends and make the alignement of the VIs more difficult.

 

21229iFF8ADD1D8AF4B5F5

I love the new quickdrop plugins!  I've written a few that I use all the time.  (Reset front panel to origin, emergency abort vis, etc.)  The only thing I don't like is the requirement to name the plugin the same as the letter that will activate it.  Since my 'q' plugin and 'shft-q' plugin have to reside in the same vi, it is a bit harder to share plugins with others.

 

I would like to have the ability to give the plugins a descriptive name and have a configuration utility where I can assign hotkey combinations to each of my plugins.

Hi, guys

 

Do you use Templates in LabVIEW?

 

You might have used VI templates in LabVIEW (*.vit).

You might have used control templates in LabVIEW (*.ctt).

 

You might even used VI templates and control templates together.

 

Why can't we create templates for complex libraries like project files or (class-)libraries?

 

For example:

I've created three template VIs which are connected to one control (TypeDef) template.

(The three VIs are for loading, editing and saving the data of the control template to a special kind of data.)

 

014.jpg

 

But using the VI templates will create a separate control (TypeDef) for each VI!

 

015.jpg


If I could put the Templates together in a library or project, It would make things easier,

because LabVIEW 'could' already know about the connection between the two template VIs

and the template control (TypeDef).

 

That's just a simple example which could get much more complex on whole project templates.

 

Until now I have to copy the project template and use it as I need to. It works somhow, but

multiple people using the same template causes much trouble (Someone always forget to create

a copy before changing it Smiley Surprised)

 

So there's the idea. What do you think?

Right now the only two Image Displays available - Modern and Classic. Please add Silver Display here.

 

Vision-Silver.png

 

Sure, we can get similar decorations with customization, but it will be very nice to have Silver Display "Out of Box".

One thing which occurred to me today is that the majority of examples which ship with LabVIEW concentrate on one function or another.

 

What we don't seem to really have is an example for an actual functioning application with a GUI which actually does something useful.  Or at least I'm unaware of something like this.

 

I think it would be neat to include a sample project for an application demonstrating how to load and save to INI files, set front panel objects, Custom menu interaction, how to synchronise loops and so on.  Just a small-ish program which does SOMETHING useful (not the Icon editor, that's too complex).

 

I think this might help a lot of people "get" the things needed for a decent application as opposed to running code from within the IDE all the time.

 

Shane.

It seems that Mixed Signal Graph does not know Cursor Events (Grab, Grab?, Move and Release). Is there any particular reason for this? If not please incorporate this idea in the next version of LabView.

How about an NXG home edition, so folks can try it without any heavy time or cash commitment. It would help acceptance and uptake in the LabView community.

Similar ideas have been posted before with even more options added to the String Probe.  Maybe if we start with something simpler, we can expand from there.

 

I would like the String Probe indicator to resize, at least horizontally, to the full space provided in the Probe Display section of the Probe Watch Window.  As the user resizes the Probe Display, the String Control would also resize.

 

It would be nice if this behaviour could also be extended to a String Array.

I would like to have some kind of compiler optimalisation options.

The save time is often to long, Editing is annoying

Editing in LV2010 often halts for 10-20 seconds because it it recompiling the code for some reason.

If we had some option to turn off "advanced optimalisation" things might go fluently, like in the old days.

 

There are several methods to exchange data between parallel loops.

These methods however are (intrinsically) not following LabVIEW's dataflow-along-wire paradigm.

 

If you think in different layers, where several loops are running in parallel at the surface, you could have subsurface datatransfer.

You could add a new "tunnel mode" to the LabVIEW 2013 right mouse menu on the border of a loop.

There you could also specify whether you would like the data passing the boundary to be queued.

You would however think of something to visualize these settings at the loop boundary as well as having some error terminals in case of queues.

 

 

Underpass_data_transport_be.jpg

Most SCC systems expects the source files to only contain source, and not (as in LabVIEW) both the source and compiled code.

This means that most SCC system flags the sourcecode file (i.e the VI) as changed whenever a recompile is performed and saved.

Since LabVIEW wants to recompile the VI's very frequently regardless of real sourcecode changes, it would be better to split the VI into two files, one containig only the sourcecode and another containing the compiled code.

This way we could configure the SCC system as with other languages to ignore the compiled files and only handle REAL source changes.

 

Note that the flag "Don't save automatic compiles" only helps for readonly-flagged  files, which isn't enough when when working in SCC systems that doesn't use locking

 

I find the color of the Reorder Button on the front panel a little confusing.  The colors of the two circular arrows being gray gives me the impression that the buttons is disabled for some reason, especially considering the related buttons to the left have some color with green and yellow boxes.  It causes me a slight mental block every time I want to use it.  I would suggest that the Reorder button be given some color, such as green, so that it mentally gives the impression that it is allowed to be pressed.

Message Edited by Ravens Fan on 06-21-2009 01:15 AM

With the advent of LVOOP, some things have changed about the way we work with LV.

 

I currently have an example of an instrument driver (USB) which I'm implementing using LVOOP.  I have many different individual commands, each with their own input and output values.  I have one nice "polymorphic" VI with all of the creator VIs for every command organised nicely in a menu with several levels.  I say "polymorphic" because I don't set the VI to adapt to the data type.

 

After processing the instrument command, I again use a "Polymorphic" VI (See above regarding the "") for reading the various values from the processed command.  Both of these "polymorphic" VIs use menus and do NOT adapt to data type.

 

I have basically two VIs for every class, one to create the query / command and others to process the data contained within the created object.  I have two VIs for EVERY instrument command.

 

What would be cool:

Having a special VI for a class which is presents the user with a menu for the individual functions (no adaptation to data type) which itself can be included in a regular polymorphic VI (adapting to the object type).

 

Polymorphic class functions.PNG 

 

This would allow the user to select a different instrument command and have the corresponsing process VI on the right automagically update to present the user with the commands available for that particular object. 

 

That way we could create an entire instrument API with only TWO VIs ("polymorphic" creator and polymorphic-"polymorphic" function VI).

 

Shane.

Message Edited by Intaris on 01-29-2010 02:42 AM

Most of the time I have quite a lot VIs (Blockdiagrams and Frontpanels) opened. Therefore my Windows Taskbar is full of files and it is very annoying to quickly swap between them since they are not identified via their names, only as 'Frontpanel ...' or 'Blockdiagra...'.

 

Most classic programming IDEs keep track of opened files using a taskbar (see picture)

taskbar_IDE.png

 

It would also be nice to sort the opened VIs between Block and Frontpanel.

 

Fixed examples are: Exclipse, Netbeans, Visual Studio Code

Dynamic taskbar (can be positioned anywhere on screen as overlay): Gimp

The built-in mouse wheel support for numeric controls is very convenient, as it allows comfortable tuning of values using the mouse wheel. But it has a potentially dangerous flaw: the default mode is "On Key Focus", which means that when you click inside the control, you can change its value by scrolling. But when they move the mouse somewhere else in the window and scroll (e.g. in order to zoom a graph), the focus stays in the numeric control, and you unintentionally change the value of the numeric control. This behavior has the potential to damage our hardware, as we are controlling high voltages and pressures using numeric controls.

Setting the Built-In Mouse Wheel Support property to "On Hover" keeps the values from changing when the mouse cursor is not above the control. But unfortunately it also changes the value when the control does not have the key focus, leading to another source of unintentional value changes.

So my suggestion is: If you add the option "On Hover AND Key Focus" to the Built-In Mouse Wheel Support property, accidental changes of values by scrolling could be prevented effectively.