LabVIEW Idea Exchange

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

Add an "Explain Error" pop-up menu on the conditional error probe.

The Generic Probe has this, why not the Conditional Probe?

 

Generic Probe:

10-9-2009 5-24-12 PM.png

 

Conditional Probe: 

 

10-9-2009 5-20-20 PM.png 

Message Edited by Michael Aivaliotis on 10-09-2009 05:27 PM

I tried to use In Range And Coerce with a Waveform.

 

Unfortunatly this is not possible so I came up with the following alternative:

CoerceWaveform.png

 

Please make the following code possible:

CoerceWaveform2.png

For as long as I've been using LabVIEW, I've often turned to the LabVIEW Help file (which is a compiled HTML file) and found very little help.  I'll search for something simple like "For Loop" and receive 500 (literally, try it for yourself) possible topics, including the Cohen-Coon Autotuning Method, Control in NI-DAQmx, Limit Specification VI, and so on.  These have nothing to do with For Loops.

 

I'm proposing that the LabVIEW Help be turned into something that is ACTUALLY helpful.  I'm not sure about the best way to do this.  I think that it should still be portable and shouldn't require any Internet access to use (as lots of us cannot access the Internet on our development machines).  I would really enjoy a tool that would allow me to search for something like "For Loop" and receive like 5 topics that all have to do with using a For Loop in LabVIEW.

Please add to the right-click Cluster popup menu a Remove Cluster item analogous to a tab control's Remove Tab Control removes the parent container and leaves the contents as-is.

Today, when you create a case structure and wire a string to it, the case structure becomes case sensitive. This may have been relevant in the 1970s, when every bit was important, but these days I'm guessing that in at least 95% of the cases the structure should be case insensitive, although most people are probably not even aware that you can change it.

 

So, why not make the structure default to being case insensitive instead of case sensitive?

 

Actually, I would possibly even suggest removing the case sensitive option altogether, but this is probably required for some things and would break existing code which relies on this.

Message Edited by tst on 20.04.2010 04:43 PM

CVI has this feature, almost every other UI library has it, too.

Only LabVIEW is missing the simple option to limit the number of characters that can be entered into a string control.

 

I know, it is possible to do this programmatically. But this is always a piece of extra effort I have to undertake, while the solution never looks really satisfactory.

Usually all I can do is react to the value change event of a control and cut what's too much. But this means the user sees some flickering, since the character is first drawn and the corrected version is drawn at a later time.

 

Side notes on how I think this should be integrated:

This should be an additional property for all string controls. For existing controls from older versions, the value should be set to it's default (-1), which means unlimited.

If activated, this feature should also cut the strings in VI input terminals to avoid "special behaviours" in this case.

 

If code is running and one happens to leave a modal VI open, or opens a modal VI in the middle of a running piece of code, then the LabVIEW environment freezes-up and dis-allows any interaction with the code. It will be great to have a set of Key Strokes to re-set the code if this happens. The only way that I know of now is to hit [ALT + CTL + DEL] and killing the LabVIEW process. This ends up loosing unsaved work and requires a restart of LabVIEW.

 

Regards

 

Anthony L.

Really, athe end of the building process it would be nice to know how long the building process lasted.

 

One of the benefit would be to make build duration comparison between different LabVIEW versions much easier 😮

 

Clipboard01.jpg

The VISA test panel is a very valuable tool for troubleshooting instrument connectivity issues.

 

This used to be included with the VISA runtime, or at least with any installer that also included the VISA runtime.

 

Now I have to separately download and install the FULL VISA just to get this valuable tool. 

 

That makes installing a LabVIEW executable a multistep process as now I have to run two different installers. 

 

NI-MAX and the VISA test panel should ALWAYS BE included in any installer that includes the VISA runtime.

How many splitter bars does this VI have?

 

 

 

The answer is three, but they might not be where you think:

 

 

It would be useful if LV showed the splitter bars more clearly in edit mode. Switching to run mode would display them "correctly".

 

 

 

This idea is similar to Show hidden controls as "ghosts" in edit mode and the same basic concept can be extended further. If anyone has anything else which is difficult to see and can be shown more clearly in edit mode, why not add it as a comment?

I'm looking at a clone. I don't see why I would have to ctrl-M to get an editable version to do such things as:

 

- get the contextual menu up on the VI's icon to 'find all instances'

 

- get help on a VI that's on the clone's block diagram

 

- open or find all instances of a typedef via its contextual menu (the typedef being on the clone's front panel or back panel)

Clipboard01.png

 

I often get this dialog when a class is locked because a VI is still in use by some running process. It might be a reentrant process that for some reason didn't shut down as expected, but in a system with 3000 VIs and lots of asynchronous processes it can be very hard to guess what code is still running. And this dialog doesn't give much information. It would be great if this dialog could show exactly which VI (with full information of what reentrant copy of the VI it is) is still using the class/VI. Even better if you could click on the filename in the dialog to open the VI.

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

As already partially mentioned in a very old discussion here, the integer display formats should have more typical defaults:

 

  • If I change an integer to hexadecimal, octal, or binary format, I want it padded with zeroes on the left and the default number of digits corresponding to the data type (e.g. U8: 8 digits for binary (%08b) and 2 digits for hex (%02x), U32: 32 digits for binary (%032b), etc. ).

 

These formats should appear whenever I switch formats from decimal and I can immediately change them to anything else if desired. If the current format is not decimal and is at the default for the current datatype, the format should adapt (e.g. more or less digits shown) if the datatype (e.g. U8>>I32) is changed.

 

structure_merger.PNGEvery now and then I (or others) have two case or event structures that I would like to merge, either completely or just copy some cases from one to the other. If we are talking about one or a couple of cases, doing it by creating empty cases and copying the code from one structure to the other as is the option today is fine. If the number is much higher this gets quickly tedious, and we have to come up with alternative solutions.

 

(Making a subVI of the two and add another case structure around them, as described in the discussion linked to above, is one -  but that changes the layout and adds another selection to the logic).

 

So how could it be handled by the IDE instead and made much easier?
A case merger function.

Here are a few quickideas on how to implement it (but any similar solution would be better than none);

 

  1.  Copy-Paste-Merger: Selecting the frame of structure 1, copying it, selecting frame of structure 2 and pasting will bring up a merge dialog with the following options:

    a) Replace structure?
    b) Merge structures (all cases)?
    c) Merge selected case only into structure?

    Now if the user selects to merge the whole or just the top/selected part of the structures (b or c) the function has to handle overlapping cases (just like the OS does when copying into a folder with existing content) by asking the user whether to keep the old ones, replace with the new ones or leave them as non-unique values (or add an index to the value) for the user to tidy up manually afterwards.

  2. Drag and drop merger; identical to the previous suggestion - but instead of copy/paste the transaction is initiated by dragging structure 2 over structure 1 and e.g. holding it with an edge aligned when dropping to indicate that it is not intended to go *into* the other structure.

  3. A merge option that can be called from the menu or contextual menus on case/event structures. The advantage of this would be the ability to add more complex mergers where you would want to pick frames x, y and z from structure 1 to merge with structure(s) 2 etc... This option could alternatively be combined with the other two and used as the dialog when those are initiated.

This idea is an extension of the idea given here How about a Front Panel Cleanup?. We could have a more generic front panel clean up which doesn’t really worry about the connector pane patterns (and if needed automatically connects the connector pane as well)
Here is the idea->
Often while writing a VI we create controls and indicators from the block diagram itself rather than going to the FP and creating it. Also we copy Control and Indicator terminals from other VIs and type defs and directly drop it on the block diagram than the FP because BD is what we are usually working on. Once BD is complete we look at the FP just to make sure everything’s visible and is in a good shape. Often we find that many controls and indicators are missing from the view and are badly organized. It is painful to search for controls and move them into view. Instead an FP cleanup could put things into the visible space and organize them in a simple way (controls to the left, indicators to the right, similar controls and indicators on the same level, error cluster in the bottom etc). For most cases this might be sufficient. If not it could be used as a starting point to organize your FP. Also at the same time we could automatically connect these items to the connector pane as well. If you already have organized some items on your FP and you don’t want that to be disturbed, you could select such objects and exclude it from your FP clean up.
Example->
Let’s say you are working on a block diagram creating controls and copying some from other VIs.

working area.JPG

Now you look at the front panel and see all the controls and indicators scattered.

before 1.JPG

Also many of them are not even visible in the FP area.

before 2.JPG

Simple FP clean up with connector pane connection will put it into this state.

after 1.JPG

Note the connector pane as well. The user can either use the VI in its current state or use it as a starting point to organize his FP.

As you can read in the link below the licence manager uses the MAC addresses of a computer to create computer ID used for the activation process.

The trouble is that when you use a NI PCIe 8235 (Quad-Port GigE Vision Frame Grabber) you are adding 4 Ethernet ports to you computer and any change to any of these ports (even a fix IP change of one of the ports) will change the computer ID and therefore you will need to re-activate all your NI products... As day to day users we simply cannot work that way.

 

The knowledge base article below explains that in such cases we can get the hard drive serial number, send it to NI and they'll give us a computer ID based on that HDD serial instead of the computer ID given by the licence manager and we can then use it for the activation process.

 

The point of this idea is to ask NI to improve the licence manager so we don't have to go through this issues, I think the licence manager should inform the user about what the computer ID is based on and tell him about the options (MAC address or HDD serial) and let him choose between the 2.

 

How Can I Change the Hardware Used for Activation of NI Software? 

 

PS :

and now that we're talking about improving that damn licence manager, you can refactor it to include other ideas such as :

Smartphone application to activate NI Software

Add a QR Code (2D Bar Code) Option To NI Product Activation Dialog

 

[admin edit]

I am copying the workaround posted by crossrulz in the comments to benefit users having these issues who find this idea:
"Here is a work around if you want to play around in the Windows registry:

In "Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\National Instruments\License Manager" add a string value named "DiskOnly" and set it to "true".  The license manager will now only use the HDD serial number."

When designing a application, I sometime find that I am not happy with the name I choose for a class after I have already integrated the class into my project.

I also often use the class name for the label on in/out terminals and block diagram constants of the class.

The problem arises when I change the name of the class from within the project.  If I then go inspect the code, I find that the labels still have the old class name.

For example, if I rename the class from 'My original class name.lvclass' to 'My new class name.lvclass' I still see this on the block diagrams:

 

class rename idea 1.jpg

 

But what I want to see is this:

 

class rename idea 2.jpg

 

So, I propose a rule.  If a control or constant of a class has its label visible and that label (or part of that label) matches the original name of the class on disk (with or without the .lvclass extension), when the class is renamed in the project, the label on the control or constant is also changed to reflect the new name.

The reason I say 'or part of the label' is if you have added a prefix or suffix (like 'in' or 'out') to the label, it would still get updated.

 

I also think that this should apply to labels that include the '.lvclass' and ones that do not, as I often will use the class name without the extension when labeling classes.

 

I am happy to accept that this correction would only apply to code within the project where the class rename happens.  But it would be a bonus if there was a menu option to rerun the cleanup from a different project that might use the same renamed class.

 

Thanks in advance for the Kudos!

I think it would be very nice to add these. A common task is to get object position/sizing pixel perfect. Adding these buttons would help tremendously with that, there is plenty of space for them, and I feel like it would be a minor developmental effort. Upvote if you like it, thanks for reading 😀

 

FireFistRedhawk_0-1638369163977.png

 

The Match Regular Expression is worth it's weight in gold, once you get used to it. There is some functionality missing though:

 

1) The begin\end positions of the capturing groups are not available. These positions can be more useful than the matching strings.

2) It's unnecessary slow when the string results are not needed.

3) The results are output terminals, making it hard to adapt to dynamic inputs. A results array is sometimes more convenient. For example a pattern is entered in a GUI.

 

I use the attached VI (based on the same API) a lot, to bypass these limitations. I think it would be useful in the LabVIEW palette, under String>Advanced String Functions.

Match Regular Expression (VI Version).png