LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

NI packages installed though winget

In a standardized architecture, there are some cluster that need to be specfic to the current project.

In labview 2013 the reference to these clusters was automatically done without preserving default value.

In newer version of labview we have to review and update each specific cluster contained in the common part of the code .

It would be great to make an exception on some type def, on which the default value doesn't really matter.

Allow Custom Properties for VISA

So one can set many of the standard properties for VISA connections. However the serial port latency setting is not one of these. It can easily be set by a standard POSIX ioctl call for both linux and MacOS (who the heck knows how Windows does it). Many character based devices can be manipulated through these ioctl calls.

To be specific, the FTDI USB-Serial port driver chips used in MANY devices as a USB interface or just as a serial port have a slow default latency that is fine for preserving CPU cycles but not great for modern high speed custom communication.

1. Just add a a property that sets the serial port latency using an ioctl IOSSDATALAT property configuration.

2. More generally allow an interface that will call ioctl with a supplied property and the LV programmer can pass the correct property configuration.

3. Less satisfying but possibly easier to implement is to have the VISA property be the file descriptor number. This simplifies the programming where one has to now get the "Name" property and then search the process information table for that "Name" (or really path) and then extract the file descriptor. Only then can one set the latency for that device.

Remove data repeated from 2D array

The idea of this VI is making a function of remove data repetad in 1D but in 2D array, this function is not added yet in Array panel and I think can be usefull at the moment for operations request a segregations of data in 2D arrays.

The function consist in put in the control of the VI the column we want to search and compare the data repeated.

Also this VI give you the data was deleted from the 2D array.

View All (2)

Get rid of per VI Control Style

Feature > Display data over wires?

When a project file has been changed, you can view a list of the changes that have been made to the project when closing it. Unfortunately, these changes often lack important details.

For instance, the most common change I make to project files is adding or removing items (even if inadvertently, such as opening a new VI and then immediately closing):

However, the message doesn't indicate which item was added or removed. Usually when I'm looking at this window, I want to know specifically which item was added/removed so that I know whether or not it's important to save the project file or if I accidentally added something that I didn't want in the project (or removed something that I did).

Background: We are in a situation where we have been supplied with a library of VIs we need call in our code, but they use silver controls. This means that in SubVIs that we write, if we have to create controls and indicators from these VIs, they are created as Silver. Our default control style is not silver so this looks very mismatched. We like our non-UI VIs to use system controls.

I am aware that one can create 'fresh' controls and indicators in another style matching the type and wire them up, or one can right click on the controls and indicators and replace them with a different style of the same type (although this isn't guaranteed to have the same appearance as dropping them fresh, as it may inherit modifications made to the control/indicator and other properties), but it would be handy to have a quick way of creating 'fresh' controls and indicators in the style chosen under Tools>Options>Front Panel>Control Style for New VIs .

Example: when I convert a Silver waveform graph to modern I get the graph on the right, whereas the graph on the left is a 'fresh' modern waveform graph.

So how could this 'default control' option be selected by the user? I had a look to see if this has been suggested before, and indeed altenbach suggested it here. I like both suggestions (Maybe a "shift-right-click...create" or similar? Maybe a preference setting or LabVIEW.ini entry?), though because shift is for the tools menu, perhaps ctrl+right click is better .I am posting it here as I cannot find an existing Ideas Exchange entry.

I understand that this might be difficult to implement due to the way controls and indicators work under the hood, and the fact that not all control/indicator types are available in all styles. I guess this is already handled in the Control Style for New VIs setting so might not need too much extra thought. Custom clusters might be trickier though, not sure.

Current behaviour: 'create (all) controls and indicators' applied to a subVI creates them in the style of the subVI

You can see that my 'silver' subVI creates silver controls on calling VI.

Desired Behaviour - If ini key to modify existing behaviour is applied (e.g. CreatedControlsAndIndicatorsAreDefaultStyle=True), or the VI is selected with shift+right click, the 'create control', 'create indicator' and 'create all controls and indicators' will create using the default style.

e.g.

I *think* when you have System selected, 'Error Out' drops down a Modern error control as there is no System error control, if I understand this correctly. It's worth thinking about cases like this.

When applied to my example above, if my default was modern, the subVI's 'Silver' style controls and indicators show as Modern style in the calling VI, and they are 'fresh' rather than converted :

Optional: LabVIEW *could* modify the menu item when you access via ctrl+right click, but this is not essential. I don't think these options should be added to the menu permanently alongside existing options otherwise it gets too cluttered.

It would also be nice to have a quick drop shortcut similar to Ctrl+D with this behaviour. Ctrl+shift+D is already taken.

Final thought: I could live without this feature if my other suggestion Front Panel Object's Style is shown under its properties (with the ability to change styles) was implemented, but it avoids the extra step of creating the controls and indicators before converting.

View All (3)

I often use LabVIEW projects. Projects may contain libraries, classes, etc.

Changing the contents of any component (such as a library) within a project causes the project file to change -- even though the project definition itself shouldn't have actually changed. For instance, if this is my project:

and I delete a VI that is inside an .lvlib, the project file itself claims to have had an attribute change:

In theory, this top-level project change isn't necessary -- since the project should just reference the library, and only the library should reflect a change.

These unnecessary file changes make it trickier to deal with source control, merging code, tracking changes, etc, along with adding one more file that you get prompted to save every time you close a project.

Rename "Show Case" to "Find Case"

Since LabVIEW 2020 selecting "Show Case" from the right-click menu of a case or event structure will call a plugin that lists and allows you to filter/search the list of matching cases. That is great.

Figuring out that this is what you need to do to find one or multiple cases though is less intuitive. I would argue that most users would start by looking for a phrase like "Find Case", or "Find Case(s)". That is what a similar action is called when we e.g. right-click on a control and try to find its terminal, local(s) etc - we select "Find", then Terminal/Reference etc...

Sub-idea: Leaving the list of found matches open (if there are multiple) even though you select one of them could often be beneficial.There is a great plugin from wiebe@CARYA that lists event(s) associated with a given front panel item which does it that way. It makes it easier to go through all the found cases if needed, instead of having to redo the search. And of course it places itself in the Find submenu; making it a "Find Event" option(!).

LabVIEW 2021 now has this pop-up, which lets you know if you still have VIs running in the background when you try to close a project:

Great! Because previously you were alerted that some VIs were still running, but not which ones. So this helps substantially with debugging.

However, I usually just want to abort these VIs without closing my project. There's still no (obvious) way to either open or abort these still-running VIs. That leaves me twiddling my thumbs (often for several minutes on large projects) while I close and re-open the project.

The request: Add the ability to either open or abort these running VIs from this window. It could be as simple as adding an "Abort All" button...or even adding documentation on how these could be closed:

(And yes, obviously the correct solution here is for me as the developer to fix the bug that's leaving these VIs running... however, in the real world, sometimes this is either lower priority than other issues, or falls onto someone else's plate...and in the meantime you're left regularly waiting for your project to reload.)

If you copy a group of controls/indicators from a front panel to another, the layout of their terminals on the block diagram is not maintained (instead it is typically messy...)

Vice versa: If you copy terminals from a block diagram to block diagram the block diagram remains the same, but the control layout is messed up.

Why not just keep both as they were when copying?

Bonus-idea: If you try to fix this by using the diagram clean-up function controls with the same name, but an iterative suffix (which the IDE is able to automatically generate itself as well, so it has a relation to it alread) the clean-up ignores the order of the names when ordering the controls...(so it might stack them nicely, but then control ...<n+1> is not put after/below ...<n> e.g. Perhaps it could be a bit more intelligent and include that in the ordering algorithm too?

Full LV linux support with flatpack

Flatpak is a distribution-agnostic package manager, as long as Flatpak is installed on the system, the same Flatpak package can be installed on any distro. A Flatpak package contains not only the application, but the libraries needed to run it.

So, if NI creates flatpak package with LV and all of its dependencies, then we would have a LV that it's able to run in any distro! Without to having the hassle to manually support every major distro or (like at the moment) only supporting a few of them.

Allow the user to right-click a given test result on the Results Window called "Retest", which re-runs the selected test, and if the test now passes where it previously failed, it clears it from the Results Window.

Start with this:

Right click on the selection, and select "Retest":

The VI Analyzer just retests the selected tests. And then once complete, it returns to the VI Analyzer Results Window, with the selected tests cleared from the list (assuming they passed):

View All (1)

Probing a typedef results in a vertical list showing all the fields in the cluster. Creating the typedef cluster often involves organizing the fields in a particular layout, setting units etc. It seems like probing the data and displaying it in the same format makes more sense.

For instance, I have a cluster of camera information set up as a strict typedef:

When I probe a wire of this information I get:

This cluster isn't too big so getting to all the information doesn't require a lot of searching and scrolling, but that can be an issue. What's more of a pain is that the default unit for angles is rad and I cannot mentally convert them quickly so I end up having to double-click each 'rad' label in the probe window and change them to 'deg' so I can confirm the data is what I expect.

I know I can create a custom probe to display the typedef, but having to constantly create custom probes for each cluster is a bit of a burden.

Am I missing something? Is there a good reason to NOT display the probe using the typedef?

View All (4)

If you build a PPL with a class and then probe the class wire, all you get is the name of the class, whereas probing a source class shows you its private data.

Currently the only way I'm aware of (hopefully I'm just ignorant on this matter) to see the private data is to create extra code to expose it in some form. This also often requires the PPL in question to be rebuilt which can be a huge pain when trying to debug. If the PPL is built with debugging enabled, wouldn't it make sense to show the private data contents in probes?

This idea started when I realized the WebDAV API provided by NI does not have the ability to read the File Creation information on a remote file.

"That's okay" I thought, I'm a programmer and will add it myself. Looking at the source it looks like NI just leveraged someone else's protocol, and wrapped it into some Call Library Function Nodes. NI could have written the WebDAV API wrapping their own HTTP API functions, using G instead, allowing for customization but they didn't.

"That's okay" I thought, I'm a programmer, and I'll look into recreating the WebDAV API, by calling the NI HTTP API. Looking at the source sounds like NI didn't implement all of the HTTP functions available, only the most basic ones. And since WebDAV requires more than just the PUT, GET, and POST, that means also having to update the HTTP API to have those functions, so that I can rewrite the WebDAV API. Oh but look at that, NI also just (seemingly) wrapped someone else's implementation again into Call Library Function Nodes, this time calling the ni_httpClient.dll. NI could have written the HTTP API wrapping their own TCP primitive API functions using G instead, allowing for customization but they didn't.

So this idea is for one or more of the following things, from the easiest, to the most difficult.

Add the File Creation Date, as returned information from the Get File Info of the WebDAV API.
Implement the WebDAV API in G, and eat your own dog food.
Implement the HTTP API in G, and eat your own dog food.

Format Data to String for File

Who doesn't like dumping data to CSV files? But there is a few pain points unless your data is already a string array or the same data type.

The usual way I end up doing it is formatting data to a string, then concatenating it with a delimiter. Then have to figure out if its a new file and prefix the header string. (Its also annoying open file doesn't return an empty file flag (True if New, or Replaced, or Existing AND empty)).

Then you need to add a new column of data - now there is a problem of keeping format specifier strings and header strings in sync. And then you end up with a stray delimiter so your column headers end up offset from the columns... And your format string breaks if you don't get the format code in the right place. And the data you want to dump increases until you have over 60 columns and its a nightmare maintaining long format and header strings, concatenate strings etc!

Format Cluster to String.png

It would be nice to format a cluster to a string. Optionally include the header row. For a 1D array could take its name and append the index to it.

Named Format into String.png

View All (2)

LabVIEW Idea Exchange

NI packages installed though winget

Review and Update from Type Def. should have exception to auto-validate the changes.

Allow Custom Properties for VISA

Remove data repeated from 2D array

Get rid of per VI Control Style

Feature > Display data over wires?

Details on which item was added/removed in Project Explorer

Default Style can be applied to controls and indicators created from SubVIs

Changes to sub-components of components of projects shouldn't force change to project file itself

PowerAutomate connector and Drop-In connector VIs

Give "Call Chain" primitive an input to decide how to handle clones

Rename "Show Case" to "Find Case"

Add ability to open/abort running VIs from "Abort Running VIs" popup.

Keep block diagram layout when copying between front panels and vice versa

Full LV linux support with flatpack

Add ability to retest one or more selections in the VI Analyzer Results Window

Probe of a typedef cluster should use the typedef for display

Class data in a debug enabled PPL should be probe-able

WebDAV Creation Date, HTTP and WebDAV APIs

Format Data to String for File