LabVIEW Idea Exchange

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

.net calls can end up being pretty verbose in LabVIEW, having to pipe between property boxes to get to some nested value, when the call is pretty straightforward when written in a more traditional language. In addition, trying to replicate some .dll functionality seen in c++ is frustrated by how different the calls look. Having the ability to drop into a function block to write .net code would make it much easier to port functionality + debug.

Even if there was a penalty performance wise, it would still be a nice middle ground for getting a prototype off the ground before optimising it for LabVIEW.

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.

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

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.

Currently, the "Tab" key is not individually mapped to an action for Block Diagram interactions; my suggestion is to use it to swap between "control", "indicator" and "constant", in the same way we already do with the options of the right-click menu "Change to Control/Indicator/Constant".

As an example, having selected a control on the BD, by just pressing "Tab" we would transform it into an indicator, a second press to a constant, and a third one would bring it back into being a control.

 

I understand this is a simple thing, but personally, I feel this ends up being one of the most repeated actions we end up taking as developers and I believe it would be intuitive to map it to a familiar key to many of us - tab.

 

Thanks all,

Cris

(In LV2017) "Browse Relationshiips\Unopened SubVIs" shows a list of icons with truncated VI names - about 12 characters per VI. When looking through a list of similar icons, one has to hover over each icon to see the full VI name.  This is impractical when hunting through tens or hundreds of SubVIs.  If unopened SubVIs could appear as an alphabetically-sorted list of VI names, it would be very helpful.

 

 

 

Ever tried to parallelize a loop?

You just have to place your mouse over what feels an approximately 1 pixel wide area on the left side of your loop and press the right mouse-button without moving the mouse. If there was no input or case terminal around a context menu opens that gives you access to the function you need.

Point anywhere else and the contect menu doesn't contain what you need.

 

The context menu entry could also show if the mouse hovers over any other parts of the loop as well to make the area easier to point at.

Currently, the only way to add a webservice to a project, is by right clicking a Target and selecting New->Web Service.

There's no way to add existing Web Service definitions to a project, other than manually performing the copy operation at the XML file level.

This prevents proper re-use of IP!

 

Webservice in project.png

 

I would propose extending the capabilities of a Library to also support Web Service definitions as Child objects.

That way, the library can act as a container for the Web Service definition, and can easily be reused in other projects:

 

Webservice in library.png

I tried using an XML editor to manually put a Web Service definition underneath a Library, LabVIEW didn't like that!

When you want to look for a specific VI in your project using Ctrl+F you have an handy option to search vi by name. But this is quiet difficult to find the VI you are looking for in this windows : All VIs are listed (without structure) and there is no Filter. Something similar to Event selection window would be much better (That would have a filter and where VI's would be grouped by libraries and class)

 

This "Find all instance" could also be added directly in the project explorer, in the Right click -> "Find" menu

 

 

Download All

LabVIEW functions "Set Waveform Attribute" and "Get Waveform Attribute" could write/read any attribute name/value to waveform. But, according to help files (http://zone.ni.com/reference/en-XX/help/371361N-01/lvwave/set_waveform_attribute/), there are default attributes such as device number, channel name, etc., which could be set by NI-DAQ, and Express VIs. But sometimes there is need to set them manually (for example, while reading data from FPGA and building waveform from it).
It would be handy to include to Waveform pallete simple API with polymorphic VI to set and get those default attributes. Then one should not remember what exact name it has, but just take the function, select which attribute he needs, and use it.

 

Sincerely, kosist90.

 

Refer to http://zone.ni.com/reference/en-XX/help/371361P-01/lvpict/draw_line/

 

Under the Pen -> Style, there is a "Dot" option.

 

But the output is not really a dot but a short dash. Can labVIEW make the output into a real single pixel dot?

 

Same applies to draw circle VI.

 

It would be useful to insert a VI directly from a project or from a class into a line.

 

Problem: There are currently two ways of moving or transferring a VI or CTL from one lvlib or lvclass to another (or from having no owner to having an owner).

Method 1: Drag-and-Drop. Select the VI or CTL, drag to desired lvlib or lvclass, drop in desired location.

  • This works well in small to medium projects, and will probably remain the quickest and most common way of moving a item from one owner to another.
  • This does not work well in large projects, which can have dozens or hundreds of classes and libraries, sometimes deeply nested within complex virtual folder structures (for good reason). In this situation dragging the item can take a long time, especially when the destination lvlib or lvclass is "off the screen" and slowly scrolling through the project becomes necessary. This is done by hovering the mouse in just the right region in the top or bottom of the Project Explorer. This can be tedious and wastes time.

Method 2: Remove and Re-add. Select the VI or CTL, remove it from its current owner by right-click >> "Remove from Library" or by pressing Delete key, select destination lvlib or lvclass, right-click >> Add >> File... , then select the file on disk (this last step can take time in large projects with large folder structures).

  • This can be quicker than method 1 in large projects.
  • This method is technically a workaround. It does not directly transfer ownership of the item.

Note: Both methods usually now also require moving the file on disk to the new owner's folder location. This can be done using the Project Explorer Files view, but is an additional step that takes time. It's also possible to simply forget to move the file on disk (best practice is not encouraged). 

 

Solution:

  • Right-click the VI or CTL, select Move to... option
  • A window appears. This window may use a Combo Box or a Listbox to display a list of all the lvlibs and lvclasses available in the project.
  • The user selects the desired destination owner and presses OK.
  • The item is moved to the destination library.

1 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Nice-to-haves

  • The Move to... window may contain buttons or other mechanisms (e.g. clickable datagrid headers) that enable the user to sort the libraries and classes in the project by name in alphabetical or inverse alphabetical order, and to filter: display only lvlibs, display only classes.
  • When the selected VI or CTL is initially part of a lvlib or lvclass, that owner will be omitted from the list displayed in the Move to... window.
  • The Move to... window could contain a tickbox named "Also move on disk to new owner's folder?" or similar. When this is ticked, the item is also moved on disk to the folder of the new owner. This would remove the need to use the Files view to move the item on disk (would save time) and would help encourage a best practice (member items should be located in the same folder as their owner).
  • The Move to... option should be available when multiple items are selected. The items may initially be owned by the same owner, or may be owned by different initial owners.

This idea is inspired by the "Project Explorer "Move to Owner Folder" option in Files view" idea.

Suppose a front panel contains the three elements seen below, with the first one being selected.

1 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

In the situation above currently pressing Tab does nothing. It would be useful if, instead, pressing Tab would cycle the element selection to the next element in the tabbing order, as seen below.

2 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

If Tab was pressed again, it would cycle to the next element in the tabbing order, as seen below. And so on.

3 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

Notes

  • This idea would speed up development by enabling us to cycle through element selection without using the mouse.
  • When used in conjunction with the F2 idea, this would enable us to use Tab + F2 combinations to quickly cycle through elements and rename their labels and/or captions.
  • This idea could be extended to terminals on the block diagram. Suppose a terminal is selected on the block diagram, pressing tab would navigate to another terminal on the block diagram.
  • I'm aware that currently it is possible to use Tab or Shift+Tab to cycle between elements forwards or backwards when the VI is in Run Mode (Ctrl + M). While that is useful, this idea asks for more.

Thanks!

The current register event callback node is allowing an easy way to handle ActiveX and .Net Framework events. This node is also very similar in appearance to the property nodes, yet it does not have an insert (Add Element) or remove (Remove Element) function available in the context menu. Since the property nodes, and also the named (un)bundle nodes are having this implemented, I think it would be nice to have these easy to access functions instead or having to grow the node, change all the elements below the one that we want to insert and rewire everything.

One downside of this idea is, that it will throw the wires a little further away than the upper mentioned named (un)bundle and property nodes do, since it is a 3 terminal height element.

In the drivers (DAGmx,NI-Scope/Fgen,...) 

If a value (usually as DBL)  enters a config vi,  it could be coerced by the driver.

That vi should directly output the actual value.

 

Most often seen in the Forum: A user declares a non valid DAQmx Timing Sampleclock and wonder why the wfrm(data) is not what he expected.

Yes, RTFM help, you can read the properties after configuration  but it would easy to add an output to the config vi with the actual (maybe coerced) value. Making the user avare of that 'feature' (instead of popping an error 😉 )

 

Should not only cover samplerate ,  other values like FGEN standard funktion parameters (frequency, Phase), actual range, ...

I like channel wires for obvious reasons. I like to have modules, which work on their own, coming with their own GUI. This is convenient for developing my modules and testing them. Afterwards I want to be free to insert this module into a bigger project, which takes control of my module.

The channel wire controls on the connector pane can be set optional, but LabVIEW throws an error, when executing a VI with not connected channel wire control. (All branches of a channel wire must be connected to a channel endpoint...)
Please make VIs working with not connected, optional channel wire controls on the connector pane. That way, we can have channel wire based modules, which can run on their own, as a single VI, or can be controlled remotely without any change.

Quiztus2_0-1707901224255.png