LabVIEW Idea Exchange

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

I couldn't find a similar topic so sorry if it's already been asked 🙂

 

When adding an VI into a loop, container or select case, I do always trying to reverse-wire the inputs like the error input.

 

No-go.png

 

Unfortunately, LV will not recognize the datatype, if you connect an input from the input to somewhere else.

 

It's always needed to create the element (constant, front panel element) inside of the loop, move it out, and reconnect.

 

So it'd be great if you could simply connect the wire to the loop entry and then create there the element.

The updated diagram expansion  (Ctrl+Drag) and its new counterpart (Ctrl+Alt+Drag) is a definite improvement in 2015.

However, they still both act globally on the diagram:

 

Screen Shot 2016-06-28 at 14.19.02.png

 

Shrink and obtain this:

 

Screen Shot 2016-06-28 at 14.19.12.png

 

All the objects outside of the case structure have been moved around because the shrinking action acted on the whole diagram, whereas my intent was to only compactify things inside the structure.

It would seem that the next step to improve the functionality of these tools is to allow the user to define their scope:

- define a region of interest meaning: DO NOT CHANGE ANYTHING OUTSIDE THIS ROI

- perform the action (expansion or shrinking)

 

In this particular case, this would work like this:

 

Screen Shot 2016-06-28 at 14.23.33.png

Screen Shot 2016-06-28 at 14.24.12.png

 

There is still some cleanup to do, but this is much less of a pain that fixing the carpet bomb effect of the current approach.

Arguably, this is easier to grasp with the "shrink" tool, but just think of the exact inverse series of steps to get an idea of the difference between the image at the top and this (the result of the current expand):

 

Screen Shot 2016-06-28 at 14.28.42.png

We often use multiple instrument APIs in parallel (with occasional sync points). It would be nice if diagram cleanup could recognize that and not interweave them.

 

Here's a quick and dirty merging of examples from Switch, DC Power, and DMM to illustrate:

 

Each API is aligned on its own horizontal line. The error cluster is used for sequencing.

Capture.PNG

This could benefit from some automated squeezing. However, Diagram Cleanup flattens it to a more compact, but argueably less readable form:

Capture2.PNG

If track assignment wasn’t automatic (maybe using the instrument descriptor line), perhaps the user could ctrl-click a set of Vis and assign to a track (track 1 for Switch; track 2 for NI-DCPower; etc.). Then diagram cleanup would place each track on a different horizontal line. If you click and drag a member of an assigned track, the whole track slides up and down together (along with dedicated constants, controls, indicators, etc.), maintaining relative positions. 

 

We spend a lot of time manually wiring our diagrams to keep the APIs in separate tracks. Diagram cleanup is awesome for small pieces or API-homogenous Vis. If it could keep multi-API Vis clean, it would make our code development and documentation more efficient.

When adding a control as a cluster constant it's important to see what's the controls name in order to use the constant correcty.

 

As you can see on the right side of the image there's how a control will be added when you drag&drop it into the block diagram.

 

Vorschlag 2.png

 

To show every label it's quite a lot of work to click on each single item (it's hard enough to hit the control correctly!) open the contect menu and select "Description" to show up.

 

It'd be a great relief, if you can simply select "Show all labels" to perform the same operation with 3 but 20 clicks.

 

Also there should be a function to automatically select if the text should be upper, lower, left or right to the constant.

When we have multiple Enum values using a same case it is difficult to see what are the values using it. It would be good if we have a Tip strip showing the values handled in that particular case would be more meaningful instead of having "Selector Value" as a tip strip.

 

There is also an idea on removing the tip strip totally and it got fair response.

 

TipStripCaseSelector.png

Please ignore if already suggested!

I would like to encourage NI developers to produce an Advanced Signal Processing Toolkit (with the wavelets functionality like the one for WINDOWS) for MAC OSX.  I have been using Labview for some time now but i really dislike having to change OS platforms just when i use wavelets.  I am sure I am not alone here as there are many using Labview in the OSX environment.  

Changing the connector pane of a subVI requires relinking to the subVI in all callers. Until we relink (right-click...), the subVI is bleached and the caller broken.

 

When refactoring old code, subVIs often contain odd connector panes and one might want to change to a more typical pattern (e.g. 4-2-2-4), and reassign connectors to established policies (e.g. error in/out at the bottom corners). Also, sometimes there was poor planning and we need just one more connector terminal.

 

Currently, relinking to a subVI clears all "subVI node setup" settings. This is unexpected and I suggest that these settings are retained instead.

 

Example scenario:

I was working on some very old code (originally from LabVIEW 4.0 :o), and there was a single instance of an interactive subVI that was set to show the front panel when called and close afterwards ((in the subVI node setup of the caller, not in the VI itself). This subVI was interactive and required user interaction to complete. It had some odd connector pane (four horizontal terminals all the way across the icon, top as input and botton as output) and I wanted to change it to the standard 4-2-2-4 pattern. After changing the pattern, I did some switcheroo on the connectors, correctly rewired in the caller, rebuilt the app and deployed it to the PC controlling an instrument. (I could not test run locally because it required the presence of the instrument)

Bam! Triggering the subVI call no longer showed the front panel and since the caller required the subVI to return before continuing, everything was locked up. I had to kill the build executable via task manager. Now the guessing game started, trying to figure out why the app would lock up. Since I also did a few minor changes elsewhere,  It took me a while before realizing that I should maybe look at the "subVI node setup". Sure enough, all settings were cleared. These settings were retained during 20 years of version upgrades and I did not expect them to change behind he scene and without warning :D.

 

Anyone can easily verify that relinking to a subVI will clear all settings in the subVI node setup. Would anyone expect that? Probably not!

 

IDEA SUMMARY:

Relinking to a subVI should retain the existing "subVI node setup" settings.

 

The existing settings are most likely also appropriate after the connector pattern has changed. This is the expected bahavior. There is no reason to clear these settings. Thanks for your votes!

 

Chocolatey:

The package manager for Windows (like apt-get but for Windows). https://chocolatey.org

 

Chocolatey it's a command line tool to download and install software with focus in automation and unattended..

 

something like:

 

choco install labview

 

and after a few coffees, voila. All installed.

 

it also supports local files, e.g.

 

choco install labview --source d:\

 

in case you have the "package" in the d drive.


 

 

Installing NI drivers should be something like:

 

 choco install NIDrivers               //full installation

 

 

choco install NIDrivers.NIDCPower            // Only NIDCPower 

 

Toolkits could be handle in the same way.

 

Chocolatey also handles dependencies. So requiring LV before installing any toolkit should be straight forward.

 

 

Instead of doing all this:

Captured1.png

I would like to be able to just drop a VI on the Start Asynchronous Call node, and get this:

Captured1.png

Strict typedefs and non-strict typedefs differ significantly.  There's too much of a gap for me.  Sometimes I'd love a control to be somewhere in between.

 

There have been times where I wanted to force a typedef to have a constant size or colour or other parameters without having to force all other parameters to be identical.

 

It would be nice if a typedef could simply be gradually converted to strict by selecting which parameters are locked.  That way we could shoose to long only boolean text, width or colour but leave the other properties free.  VI Server would need to return an error that the type definition does no0t allow that change, but that is kind of already there for when you try to change properties of a strict typedef.

 

So by default a typedef would refer to data only (See HERE) but any further cosmetic changes (to which the datatype does NOT belong) we could simply select which parameters are locked and be done with it.

LabVIEW's Query Input Devices uses LVInput.dll to return information about the Keyboard(s), Mouse(s), and Joystick(s).  However, it appears that the number of Joystick entries returned is limited to 8, whereas on several machines that I've examined, the "joystick" device can be present in slot 10 (as noted by DxDiag's Input test, which otherwise matches what LabVIEW returns in the first 8 slots).

 

Can this function, which returns an Array, be modified to return as many entries as the DxDiag utility returns for DirectInput?  This would facilitate using multiple joystick-like devices as control units using standard LabVIEW procedures.

 

Bob Schor

A value change for the autoscale setting of a graph / chart scale is currently not registered. It can only be detected by polling for the scalefit value. The range of detectable events on charts and graphs is currently incomplete. The scale range change event and the autoscale range change event trigger at the same time in unpredictable order. This makes it hard to detect whether a user manually adjusted scale minimum and maximum or adjusted the autoscale settings value in the scale attribute. Different user actions all trigger a scale range change event without any way to discriminate the cause of this event. 

The getting started windows fills with irrelevant entries if we open many VIs and projects from the forum. We probably never want to see them again. Also, if items exist that have the same name, but reside in different folders, they will show with the full (often very long!) path and the filename is not directly visible unless we e.g. hover over it or make the window gigantic. Here we want to remove the stale one, even if a copy still exists on disk.

 

We can currently do some cleanup by editing labview.ini but it is tedious. (just try it!)

 

I would like to request a feature that allows us to easily and permanently remove any entry in the list.
(...maybe it could even show for pinned entries?)

 

IDEA: I suggest to show a special glyph that, when clicked would remove that entry from the list.

 


It could also be e.g. an "X" (or similar) that shows next to the pin when hovering so we can either pin or thrash an entry.

 


These are just some suggestions, but there should be a way to easily weed out unwanted entries from the GSW. Of course the actual files will not be touched. We would just go back to the state before we opened that item.

Download All

I would love an update to the signal processing VI's contained in NI_MAPro.lvlib to support waveforms with a SGL Y-value representation. The library is locked and most VI's call dll's that are not able to be modified anyways (by me that is, I am not all that strong in traditional text based languages). It would be nice to also support SGL waveforms within the .llb's contained in vi.lib/measure; although these are mostly unlocked and able to be modified.

 

Working with a cRIO, the FPGA to host DMA channels encourage the use of SGL data type so I went with it and kept it as SGL throughout my application. For some functions I turn my SGL array into a waveform with SGL Y-value representation. I was disappointed to learn that most of the signal processing waveform tools contained in NI_MAPro.lvlib do not support the SGL Y-values.

 

 The predessesor application was done on the usb cDAQ line that i was using DBL representation Y-values. I want to re-use a lot of code and was hoping the waveform signal processing VI's would accept SGL Y-values. For now I am stuck converting my data type for the sole purpose of re-using code; at 50kHz on 36 channels this can become a performance issue.

Recently, user cprince inquired why all of the possible Mouse Button presses were not available in LabVIEW.  In the original post, it was not clear whether this referred to "normal" mouse functions (as captured, say, by the Event structure) or whether this referred to the Mouse functions on the Input Device Control Palette.  The latter has a Query Device, which shows (for my mouse on my PC) that the Mouse has 8 buttons, but the Acquire Input Data polymorphic function for Mouse input returns a "cluster button info" with only four buttons.

 

The "magic" seems to happen inside lvinput.dll.  If, as seems to be the case, the DLL can "see" and recognize 8 Mouse Buttons, it would be nice if all 8 could be returned to the user as a Cluster of 8 (instead of 4) Booleans.

 

Bob Schor

There are a lot of ideas about improving the navigation of the Find Project Items window, but I could not find this one.  When I search for a project item and get a list of matching results, it would save a lot of time if I could select the ones I want, GoTo all of them at one, then open them all simultaneously from the project window.  Opening multiple items has been around for a very long time.

 

Currently:

1. Select first result

2. Go to item in project window

3. Open item

4. Edit item

5. Save item

6. Close item

7. Go find results window

8. Select second item

9 Repeat 2 thru 7 again and again

 

This would take about 70 steps for 10 items

 

New idea:

1. Select all results

2. Go to all results in project window

3. Open all items at once

4. Edit item

5. Save item

6. Close Item

7 . Repeat 4 thru 6 for all items

 

Under 35 steps for 10 items.

Find Multipe Items

After some searching, this ideas was already discussed in the comments of this declined idea. but I think it deserves to stand on its own, so here we go.

 

We have a nice menu entry "Menu...Edit...Make current values default" that (if nothing is selected) does just that. In 99% of my cases only the controls are important, because all the indicators, while often containing tons of data (graphs, arrays, etc) can be easily re-created from the control values at any time.

 

So while the control values are useful to be able to run a VI out-of-the-box with reasonable input values, default values for indicators just contribute to VI bloat, increasing the size on disk.

 

Making indicators default is useful for the rare cases where a forum users want to show what he gets or expects to get, but not in general development. Yes, we can of course select all controls first, but they might be scattered all over the panel and over several tab pages, so that's not a good solution. (We could also request a menu in addition to the "edit...select all" e.g. called "edit...select all controls", but that is probably a different idea.)

 

In summary, there should be a menu entry that ignores indicators when making values the default.

 

It should also work if multiple items are selected "Make Selected Control Values Default", in which case it would ignore any selected indicators.

 

With a case structure I can place the mouse cursor over the structure and Ctrl + scroll wheel to cycle through the cases without it being active. If I try doing this on arrays it doesn't work.

 

For front panel arrays the numeric indicator must have focus for this to work. Doesn't work when the array data is selected. I understand that multidimensional arrays would be a problem, but for 1D arrays it would be nice if it cycled through the elements.

 

For array constant block diagram elements, no scroll action works regardless of what is active. Again it should allow the user to cycle through elements for 1D arrays simply by hovering over the item and Ctrl + scroll wheel.

 

original.gif

 

Not a duplicate of http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Array-scrollbar-quot-scrollable-quot-with-scroll-wheel/idi-p/1009220

 

[admin edit: Adding animation image at the request of the OP]

 

Make it easier to find the right product in the uninstaller

If you install a lot of National Instruments developer tools the uninstaller becomes very crowded. You can have 50-100 components, often with similar names and varying name structure. Finding the component you want to uninstall/modify/repair can be difficult. 

 

The fact that things a split into so many separate components is practical, but the components should be organized better:

They could be:

  • logically grouped
  • have descriptions
  • there could be a search/filter function available (that accepts wildcards)

Allow us to specify a new source location

If I want to repair or modify an installation it might turn out that the original source for the installation is gone, or I have a new (identical/compatible) source that I would like to use instead. It would be nice if the uninstaller handled this, instead of insisting on the original. 

 

Currently there is a method for setting the control value of another VI via the Control Value Set Method. But there is no set with signaling method which allows control of VI's which react to changes on front panel controls. This makes it hard to automate VI's that are using front panel control events. There is a tedious work around to get references to control on the front panel and then use value signaling method . It would be very useful to just have one additonal method that does the signaling in additon to setting the value of the control.