LabVIEW Idea Exchange

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

The idea is to enable read access to the "Error List" programmatically (scripting) in LabVIEW.

Inspired by the conversations on this idea.

 

Scenario: I have a section of code that has missing subVIs and controls (they're typedefs), and I want to disable it.  I put a diagram disable structure around the code, and it means that the missing VIs are okay, but LabVIEW still requires the typedef'd controls to be loaded <- this causes a broken arrow, even through the only broken code is within the diagram disable structure.

 

Solution:

  1. If all uses of the control are inside a disabled structure (including the FP terminal, all staticallly bound property/invoke nodes and local variables), then the control effectively vanishes from the panel and all behaviors at run time (not literally vanishes, maybe make it look different).
  2. If any use of the control is not inside a disabled structure, the control remains in play.
  3. This means that if the control is linked to a typedef, the typedef is loaded if any use of the control is not disabled, but if all uses of the control are disabled then the typedef is not loaded (and, therefore, if the typedef is missing, the VI is not broken) -OR- such typedefs are delinked at runtime, and relink when the VI stops.
  4. The use of "typedef" in #3 applies equally to references to LVClasses, XControls, Active X classes and anything else that may in the future be added that a control references.

I have been using some polymorphic VIs lately and I believe there can some improvements to the interface.

 

1. If I add a new VI to a polymorphic VI, the list should scroll automatically to the end and highlight the item that has been added recently.

       - Highlighting does not work all the time as of now. If you have selected the first VI in your polymorphic VI and then Add, it will highlight the recently added item. If you have selected any other row and press Add, it highlights one row before the row it was originally highlighting. (I guess it's doing some circular kind of action) I am not sure if this is more kinda bug!

 

2. Able to move multiple items at once - I can move only one item up/down right now. Ability to just drag, drop multiple items and change the order would be great!

 

3. If I click on any instance VI, it opens up that VI. If I click on the same instance VI but in the menu name/selector name columns, it should open up the "Edit Instance Name" dialog box. It's really hectic when I have my Polymorphic VI fully maximized, selecting an instance VI, coming to the bottom, pressing Edit Name button and editing the names.

Another option is to right click on the instance VI and select Edit Name.

 

Regards,

Saranya

The new and improved wire labels in LV2010 are neat, but could be even better if they did not loose their labels when wired into or through structures and/or sub-VIs:

22304i54B001A3D70920D4

My suggestion is that a wire, when labeled, should keep the label name when the wire value is not changed or able to be changed. Even through structures and sub-VIs, like most PCB routing programs with their "signal names".

It would also be reasonable that the wire label value should default to the name of the control where it is originating.

In this way, using the wiring-tool, you will get much more readablitity in your diagram when debugging code. A right click option of "highlight signal wire" could be the next step ;o)

Every now and again we run into an issue on RT that is caused by the use of a front panel item property node use. A listbox Item Names property for example..

 

In the IDE the code works fine so no one detects the error at that stage, but when running as an application such properties do not have access to the front panel item, and fails to deliver the expected result. Now the help text for such properties have remarks that state that they are available in Real-Time Operating System, and are available in the run-time engine...For all practical purposes however the latter statement is not true *if running on RT*. It would be nice to have a remark about that in the help box.

Here is the remark list as it is today:

itennamesproperty.PNG

Related idea:
https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Option-to-check-for-Development-System-vs-Run-Time-Engine/idi-p/3795807

Support LabVIEW-UML integration.  Integration means supporting code generation from models and reverse engineering to models.  The UML tool must support the latest UML specification from OMG.  (This includes the specifications for interoperability.)

 

Other considerations when selecting a UML tool should include:

UML features and ease of use of the tool.

Support of SysML.

Integration with version control.

Additional features of the tool.

Cost of a license.

Size of user base.

 

As discussed here a long time ago, I typically hide the labels of controls inside radiobuttons. We want to show the boolean text, because it is clickable. The labels are just in the way and clutter things up, so they are typically hidden.

 

A radiobutton control acts like an enum, with the items names corresponding to the control labels inside the radiobutton control. This makes it difficult to add more radio items, because shift-dragging an existing control creates a duplicate with the old label name incremented.

 

I typically immediately change the boolean text to the new selection, but to change the label, I need to go to the properties page and update it from there.

 

In these scenarios (and maybe others), it would be nice to have an option to synchronize the label with the (OFF) boolean text: changing one will update the other and vice versa.

 

It could look as follows:

 

 

 

For the radiobutton controls, I would also recommend that this option be enabled and that the inner control labels are hidden by default.

 

 

 

 

When I want to insert a line of text in the Enhanced Icon Editor of an existing VI it usually means I have to overwrite my existing text or cut and paste it.

 

I.e. If I simply want to go from this:

 

21203i5E96ED314B36205F

 

To this:

 

21205i0BA9C1C27BE039D4

 

It's not that easy and it could be much quicker.

 

I would like to be able to Right Click (or a similar method) on the Lines Cluster and select "Insert". 

This would insert a blank line and move the Line Text and Line Colors accordingly, preserving existing settings thus allowing me to easily edit the above icon's Lines quickly and easily.

 

In all these years, I have never had a need to open or edit the .aliases file or the .lvlps file.  Why not make these files hidden by default?  They don't need to be visible.  If somebody forgets to copy them, a new one gets created anyway.

The title says it all.  Currently this is not possible.

 

And yeah sure there are workarounds, like using a Waveform Graph.  But they aren't good enough.  I can't use waveform graphs, because I want to use STACKED PLOTS, which isn't possible (see here) in Waveform Graphs.  So please give me one or the other:  Stacked Plots in waveform graphs or Cursors in Waveform Charts.  Right now, I need both.

I didn't find a post on this but i could be mistaken. It would be nice if there were a selection on the Replace Array Subset to Insert data into an index that may not be initialized. The work around is simple therefore the functionality should be easy to add. I know most will argue that this is a waist of development time but it was worth throwing the idea out there.

 

20455i9FFBD25F46FF35F9

It is very common to build an array or string in a loop using the Build Array or Concatenate String primitives. Unfortunately, while easy, this also incurs a large performance degradation (see this post for some examples) and this is not communicated to the creator in any meaningful way, other than slow code. I propose changing the primitive appearance in some obvious way to show that a performance degradation is happening. This would only happen if the primitive was in a loop, since these functions are a normal part of LabVIEW programming.  Some possible methods of showing issues:

 

  1. Change the border of the icon from a black line to an alternating red and yellow line (for an over-the-top effect, make it "crawling ants")
    BuildArray-RedYellowBorder.png
  2. Change the background of the icon from light yellow to dark red, while changing the glyphs to white, so you could read them
    BuildArray-DarkRedBackground.png
  3. Double the width of the border and make it red instead of black
    BuildArray-WideRedBorder.png

Accompanying any of these would be a mouse-over or pop-up to explain why the colors changed. The change would also be explained in the context and primary help. I would definitely want a switch, probably in Tools->Options and the labview.ini file to turn the behavior off for advanced users. New users would see the change and should be able to find out why it is occurring fairly quickly. The help files for the nodes should give alternatives for using them in a loop, such as the post above or replacing a Build Array with a conditional index.

 

The majority of the problem comes from Build Array, Delete from Array, Insert Into Array, and Concatenate Strings, so an initial pass at this problem could target them only. The Build Array and Concatenate Strings issues could be largely removed by using compiler optimizations similar to the ones currently being used for the conditional index, although algorithm changes by the developer can lead to higher performance than the generic case (see link above). The Delete from Array and Insert Into Array issues are usually solved by algorithm changes on the part of the developer, so an indication of an issue would be useful.

 

Good day forum

 

Proposal: add "retain value if unwired" option to shift registers. particularly useful to reduce wire clutter inside and outside of loops.LIX.png

Have a great day

 

 

As shown in this discussion, the [path] version of the polymorphic "Read Key" VI lacks the "read raw string" input of the [string] version.

To properly read certain raw UNC paths (e.g. \\a\b\c), this input should also be exposed on the [path] version of the polymorphic VI.

 

(The change is trivial and is just a matter of exposing this input of the [string] version that is used inside the [path] version to the connector pane of the [path] version..)

So far there is no difference if we click with the (empty) WireTool on an already existing wire or instead we click on a glyph, in the small flashing black box representing a (already connected) connection. Both operations start a new wire branch. What about if in the latter case, instead of starting the new branch, the (empty) WireTool disconnected the already connected wire, grabbing it?

Screenshot - 26_03_2013 , 12_36_21.png

Screenshot - 26_03_2013 , 12_43_28.png

 

The grabbed wire should become "marching ants" as usual, making clear that we are now rewiring the connection.

As soon as we "grab" a wire, the operation should become identical to a "normal" wire connection, in all its aspects. For instance we could change mind and delete the whole wire with a simple right click (and this could be another way for deleting a wire without using the keyboard).

This operation should be startable from both sink and output terminals.

 

The only thing we would have to remember is the difference between to click on a wire and to click on a connector. The difference between the two places is already made clear, even in a very short wire, by the fact that the connector's area starts to flash when we are on it before we click.

 

This idea comes up in my mind reading this Steen's idea, with wich it integrates very well. The sum of the two ideas would make the rewiring of every kind of connections very quick and easy. So, if you like my proposal and you vote for it, I think you should also vote for the Steen one

 

Cheers.

 

Marco.

The color of number of LabVIEW front panel objects can't be modified programmatically. This is specifically the case for graph frames. There is a complicated workaround, making the frame transparent and using a decoration placed under the graph, but it is definitely far from convenient.

This idea should be regarded as a small improvement to the presentation of graphs, the most prominent UI components.

The current VISA read and write primatives do not have the ability to abort early. Under many circumstances if the timeout values are short this is not an issue but it can be an issue if a long timeout is required. The current work around is to use a short timeout value and loop continually ignoring the individual timeouts until a threshold has passed and then pass the timeout error out. This apporach requires the extra code to "monitor" the process of the communication. It also requires shift registers and associated logic to maintain the data. It would be desireable to simply set the timeout for the desired value and have a separate VISA property that can be set cause the current operation to abort.

Add a new selection, so that the application pauses if "something" is on the wire...please see the attached image!

 

Similar to that, a conditional "DBL" probe could be enhanced by adding a "NaN" option...one could realize that by inserting "Equal to ... NaN", but it would be easier to just select this "value" with a checkbox, and two conditions could be monitored at the same time ("=NaN" and "=xxx")

 

extendedconditionalstringprobe.PNG

I am still hoping that NI will bring back the Standard Report type in the future and I know that there are many others sharing my feeling. Whatever the reason for discontinuing it, there might be another or even better way to implement good looking reports internally in LabVIEW without having to buy and rely on third party vendors.

Ello,

 

Many of us have to install multiple versions of LabVIEW on a development system due to legacy projects where the benefits of transfer to newer versions of LabVIEW are outweighed by time and risk.

 

What I'd like to be able to do is have modern versions of drivers etc installed at the same time as legacy ones that are unsupported.

 

For instance, I have IMAQdx installed for LV2019 and LV2016 using VAS 19.5, which is only backwards compatible down to LV2016 (ref). I'm trying to install IMAQdx 4.2 to be able to use it as part of an LV2013 installation, but the installer will always tell me that there's no need, I've got a newer version! Unfortunately, said newer version isn't compatible with LV2013.

 

My workaround is to uninstall IMAQdx and IMAQ 19.5, install 4.2, then deal with the consequences afterwards. The other alternative would be to set up a series of VMs for different versions, but that's easier said than done in my company!