LabVIEW Idea Exchange

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

Since LabVIEW 2021 is announced that will adopt the advantage features of NXG, I expect some thing like:

- In NXG we could dock constants to functions & nodes. hope can also be in LabVIEW 

- In NXG we could also reduce space of block diagram by (Ctrl + mouse click & move up/left) while Down/right is to extend the space. In LabVIEW still couldn't reduce the space. all mouse direction are extending the space.

- provide unplaced terminal, controls and/or indicator pallet, is very use full.

- zoom in/out, I've no Idea why NXG can while LabVIEW can't.

My software is used in microscopy, and the screen brightness can be annoying for people looking into the microscope. Nowadays, all microscopy has a range of dark colour schemes, to suit the user, to either work in complete darkness, or just low-light situations.      

 

I want to be able to do the same, i.e. make custom color schemes.   The system color schemes don't quite satisfy, so I really want to do this programmatically.

 

For most controls, i can nicely change all colors using the property nodes.  But strangely enough, some controls simply don't give the option, even though you can do it manually.  The color options seem to be very inconsistent in this respect...

 

For example, the numeric Knob or Dial are perfect.  You can set the color of the knob, as well as the color of the ticks, the text, etc.   Similar for a slider, where every little detail can be set.

 

But strangely enough, the normal numeric (digital) lacks the option to set the color of increment/decrement button.  However, can set those colors manually.   The menu ring however, doesn't seem to have any way to change the color.

 

That doesn't make senso to me....   Why give the option to set all the colors of some controls, and then not have that option available on other controls?  

 

My request is to make sure that ALL controls have the color properties you need to color them programmatically.  The Knob and Slider are nice examples where it is done very well. 

I would like to be able to target an entire sub-palette for searching, rather than just a single vi.

 

That way, for example, if I want to find every vi that contains any of the Queue functions, I could get them all in a single search, rather than having to search for each vi in that palette.

An image explains this best:

 

stripbookmarkname from bookmark text.PNG

Removing the bookmark from the text when it is already displayed as the group name will reduce the level of information noise in the bookmark manager, and make it easier to read the bookmarks.

A BD control/indicator/constant can be changed to either other type by contextual menu. For individual objects, Constant as well as Show/Hide are a choice; but for multiple selections, not -- why?

Screenshot from 2015-05-14 00:24:24.png  Screenshot from 2015-05-14 00:25:03.png

 

Note that this is not exactly a duplicate of Every GUI Programmer's Dream... (completed in Labview 2012), rather a part of the implied request which has been left out.

When integrating libraries written in C# a common scenario that occurs is the necessity to cast a method to a generic delegate defined in the class in order to, for instance, subscribe callbacks to events belonging to sub-classes inherited by the object instantiated by the Constructor Node.

 

So far LabVIEW efficiently allows to subscribe to events, registering a VI as callback in case the event involved is fired, but does not allow to cast a VI to a generic delegate and that's very limiting.

 

The only workaround existing is to wrap the C# library, adding an additional C# layer that instantiates the delegates on behalf of LabVIEW and then exposes plain methods, properties and events that are straightly callable by LabVIEW itself.

 

The idea is to allow  LabVIEW to instantiate generic delegates based on the definition of the delegate provided by the C# library and return the delegate object so that it can be provided as input to library's methods requesting it.

 

This feature would make the LabVIEW integration of C# dlls more solid and completely manageable within LabVIEW code without further wrappers needed.

Imagine that I have a UI with dozens of graphs all showing acquired time history data.  Time could be on the X axis, but it could also be on the Y axis depending on the convention of the UI.  The user wants to see what happened between 1 minute ago and 2 minutes ago.  The user needs to look at data on various graphs to make a determination.  The user wants to go to one plot and make a zoom operation on the time scale and have all other plots show the same time scale interval.

 

Why not have a properties tab on plots that allows the developer to define a named linked scale and assign a scale on the current graph to link to the global scale.  So the developer can drop XY graphs and set the time scale to link to create a standard time scale common between plots.  When the user changes the time scale on one linked plot, it automatically propagates to all other linked plots.  The common scales would be global across any VIs in memory.

 

This would be useful for linking time scales, but I also see it as potentially useful for linking other scales, say the Y scale is temp and the user wants all temp plots to match scale.  This would be harder though as some negotiation would be needed if autoscale is turned on where where all plots would have to report their min/max to a process that would then pass out updated scale ranges as some reasonable interval (1 hz, 10 hz, etc).

 

All of the above can be managed with resize events and programmatic handling of those events, but I waste many dev hours on that task.  I'd love for this to be an out of box feature.

Knobs and dials require the user to move the mouse in a circular arc when adjusting the value, which isn't very ergonomic or precise. If the user isn't careful, passing the mouse over the center of the knob while adjusting it can cause the value to change rapidly and unexpectedly.

 

knob_vertical.png

 

The idea is to add an option for the knob or dial control to be adjusted by only moving the mouse along a single axis (vertically or horizontally).

I have a set of Icons that I use, saved in the folder \<User Docs>\LabVIEW Documents\Icon Templates\VI\BS Icons.  I've gone through a bit of work to organize this folder, adopting the "Reverse Alphabetic Order" that seems to be the Ordering Principle here (i.e. the Icon "Zebra" is first, "Aardvark" is last).  Yet when I open the Icon Editor after starting LabVIEW, "All Templates" is selected (by default), rather than my BS Icons Library.

 

One way to "fix" this is to empty (or delete) the two "Frameworks" folders, both of which contain a (differing) Icon called "_blank" (so-named, I bet, to "reverse-sort" first in the list).

 

This is, I realize, a minor "cosmetic" issue, but creating LabVIEW VI Icons is an important part of LabVIEW Style, so why not make it more User-Friendly?

 

Bob Schor

Just recently ran into an issue with XML namespaces where the LabVIEW implementation just didn't cut it. The AE had R&D confirm this too. The work around, after trolling through the vast sea of .NET XML features & forums, was there. Something this simple shouldn't burn up this much time.

The world around us uses JSON & XML extensively yet the examples are minuscule. It doesn't matter if new examples are .NET, Python or something else but we need to get to solutions quicker.

 

Since a few days I'm struggling to debug a packaged library. The project library works when called with development system. If called by the corresponding executable I’m only getting error 1498 and there is no way (to my knowledge) to obtain more/usefull information. Even inside the LVInternalReports folder no information is stored. REALLY useful as well would be the bugfix of CARS #684847 which is reported since version 2016, which prevents to show the block diagram of nested PPL if called from the executable…

So please give a more convenient way to debug packed libraries and fix the mentioned CARS.

Dear all,

 

timeouts and UID properties of "Modbus Master.lvclass" and "Modbus Slave.lvclass" can currently be set but not read out (they should).

 

See discussion here.

 

Sincerely,

TDMS files generally come in pairs.  There is the TDMS file itself which contains all the data and meta data stored in the file.  And there is usually a tdms_index file.  This is the file with the meta data in it, but not the actual data.  The idea being that this index file is created from the original file, but since it doesn't contain all the extra data, it is faster to search through for a particular offset in the file to find something.

 

If a TDMS file exists in a folder without a tdms_index file, it will generally be created when calling the TDMS Open function.  This means when DIAdem indexes it, or when Excel Importer opens it, or when Scout opens it, this index file is created.  Often a useful way of looking at a folder of logs is to look at the Date Modified or Date Created and look at the newest.  But if we are viewing a folder of TDMS files which don't have the indexes, as soon as we open one to view it, the index file will be created with the modified and creation date being set to right now.  This suggestion is to have it be set to the same value as the original TDMS file.  As always pictures are useful.  Here is a folder of TDMS files sorted by the date modified.

 

Before Open.png

After double clicking that file the TDMS editor of choice opens it and the directory looks like this:

After Open.png

The index file is created, but since it has a newer mod date it moves to the top of the list.  My suggestion is to have the index file have the creation and mod date set to the TDMS file so the directory will look like this after it is created:

Proposal.png

Yes I realize you can write code to set this but I can't think of a reason why I would ever want to know what the date and time that the index file was created.  I'm only interested in the data, not the index file.  If this is implemented on the TDMS API side of things, then all tools that get made from that point forward will have the file modification set automatically.

Remark: I'm using LV2015SP1, maybe there is already a change in LV2016 which I do not know!

 

Question:
Why is the decoration-element-palette of the block diagramm located inside Functions => Programming => Structures ??

In my opinion it's just a styling element which can be used for everything and nothing.
So my simple idea is to move it to the top level Functions-palette so that it can be easily found and reached.

How about Indexing cluster element by name or order number?

 

 

AdarshaPakala_0-1625234655052.png

 

This helps dynamic indexing or programmatically indexing the cluster elements.

 

 

Thank You

Adarsh

LabVIEW from 2006

CLA from 2014

On larger diagrams (e.g. state machines) it's sometimes annoying to search for a special control or constant that defines the data type of the wire (especially if it is hidden or out of the visible FP area) or just to see the exact type of the wire.

To make this easier I have several suggestions:

1) add the data type to visible items: Right-Click to a wire -> visible items -> datatype   (should show either the basic data type like "U32" or the name of the type def control or class.


2) add a tool-tip function to wires. After a few seconds of mouse-on-wire the type / type-def name should appear

(ToolTip.jpg)

ToolTip.jpg

 

3) add an option to open the type def control file by right click to a w

ire (see RightClick.jpg); alternatively to #2 the menu could also show the data type

 

RightClick.jpg

 

Most of the time when I add an event it's a "Value Change" type - the default type.  I usually double-click on the Event Source wanting the dialog to accept the selection and close.  Since double-click (on event source) is currently ignored, why not treat it as if the "OK" button was pressed?

I wanted to suggest if it would be possible to add an option to resize the "Browse for Variable" screen which would help with the development of the new project. Especially when you have a generic subVI where you just change the variable but keep the logic built.

Download All

In the world of tab controls, a tab caption refers to the actual text in the tabs that you click on to select the different pages, see attachment "Tab Caption". Currently, there is no property node that allows you to change the font characteristics of the tab captions. The font characteristics can be customized non-programmatically by right-clicking on the tab control and selecting Advanced/Customize. However, within the customize control all the tab caption properties are linked, so if I make the font color red for the page 1 tab caption, it will automatically change the page 2 tab caption text as well. The same thing applies to the other font characteristics.

 

This functionality would be useful for those users who want more control over the aesthetics of their front panel. For example, if a user wanted each tab to represent a test that he was running he could change the individual text and color to represent whether or not the test passed, green "passed," or failed, red "failed."

 

The current legend properties are too low level - requires a loop to iterate on active plot and set/get legend text.

There should be high level (express ?) VI's to do the most common task of labeling a plot legend.

Yes this can all be done with lower level primitives today but why waste everyone's time with coding something that is always needed.

Ideally an express VI that takes a reference to a plot and an array of numbers of strings and allows the user to generate an appropriate legend for the plot based on the array input. The express VI can be saved and modified by the user for special, uncommon applications but most users can just use express VI to quickly create legend for plots.