LabVIEW Idea Exchange

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

Adding Custom Controls to the front panel of your VI can really make it look better. Creating new Custom Controls, however, can consume quite some time. It would really help to have a repository of Custom Controls online from which you could download the ones you need as well as upload Custom Controls you didn't find and had to create yourself. 

The first idea is about huge stacked shift registers, it's often not very nice to have a huge amount of stacked shift registers if you only want to use the last element because it makes your block diagram look more complicated as necessary. Here another representation could help, perhaps one where you can adjust the element you want to have and this one is the only one you will see. Or you hide all other elements and just the element you want to have is visible with its number in the rectangle. I think there are many ways, my example here is just a very quick and dirty drafts, I'm sure NI would build something that looks much better.

 

The second idea is about the problem that shift registers have to be "docked" to the borders of your loop. If you have a really huge loop that means that you have many wires all the way through your loop that may cause many crossing lines. That will make your block diagram look very confusing.

Because of this problem I suggest a type of shift register that don't has to be docked at the borders of your loop but works like a normal shift register. A feedback node couldn't do this job because of a bunch of reasons and even the idea to work with a lot of local variables isn't very practicable.

When implementing this idea there are two problems, the first is that you don't know if your feedback node is the one that would be on the right side of your loop for your incoming data or the other one for your outgoing data. This can be solved by a little arrow or something like this that shows the type of the node. The second problem will be that you don't know what's the right node for your shift register you want to use at the moment if you have many of them. This can easily be solved if your shift registers would get label names.

 

Once more for these nasty drafts but I wanted to show a example of the problems. If you like these ideas be sure that the implementation by NI would be very nice and look much more great, so please don't be put off by my little drafts.

 

 

 

Numeric indicator by default has the display format of Significant digits set to 6 digits. It will be great to have a property or way to programatically set the display format - Precision type to digits of  precision. Currently property node works in edit mode only. This feature will help display more digits.

 

 

A customer was recently trying to use a change in the SRQ serial line to trigger another process within his code.  After much searching he was able to find out which class and property to specify on his property node for him to access the SRQ information.

 

However, he couldn't find this functionality using the search palette.  Yes, he could have started with the propty node, chosen the correct class, and moved forward to find the correct property.  He could only work backwards using many LV help articles to find out which menus to choose. 

 

I propose that we add Classes and Properties as two more tabs in addition to Functions and Controls (below).  This will help customers quickly find properties rather than having to troll through help articles. It could save people much time searching for the correct class and property in menu after menu.

 

 

ImproveSearchPalette.jpgSmiley Very Happy

The DSM is a fantastic tool for Viewing NSV's and Citadel historical trace data.  Why not allow it to also work with TDMS data too?

I think along the way a LV version of the Hypertrend control that works with TDMS would be a nice first step.  It turns out the TDMS is

a very high performance data store that can handle simultaneous reading and writing at high speeds.  So we can use it as a real time buffer

to accept DAQmx data and at the same time allow a TDMS version of the DSM to handle all of the real-time and historical charting.

How about copy, paste options in right click menu for selected component on the front panel or block diagram.

 

The options are available in the Edit menu but will be great to be able to right click and copy/paste on the front panel and block diagram. This will align LabVIEW with commony available options in other applications.

 

- Ashish

As a newbie to LabVIEW (don't hold it against me, we all have to start somewhere) Smiley Indifferent I get frustrated by having to search for items created on the front panel that get dropped in an almost random position on the block diagram and visa versa.

 

How about having a fishing basket anchored somewhere on the screen for both front panel and block diagram when any new and unused items are kept together until required.  As you create something on the front panel it gets automatically put in the basket so you can find it easily.  The same would work when you create something on the block diagram it would be placed in the front panel basket so it's easy to find rather than having to wonder where it is.  The more complex the layout the more difficult it becomes to find randomly placed items. I know that there are a few ideas posted that relate to improved placement of items and I support them all but having unused/new items in the same area so they can be found and quickly placed would be a great help for me and I suspect others also.  If the fishing basket could be dragged around the screen and then left anchored you could drag it around and place it where you are intending to do your next bit of coding and as you progress in your project all the items created will by definition be where you want them most. This also has the added advantage of focusing your attention on items that still require using or placing.

Hi all,

 

This is Rutsu Kenmoku from NIJ AE. 

I got few feedbacks from my customer about LabVIEW help and I would like to share the idea with you here. 

 

In LabVIEW help, there are explanations on each terminals and for some VIs, it has equations but it would be a lot easier to understand if there were flow charts or timing charts.

 

My customer gave me a feedback on Timing loop and he told me that it  would be easier to understand if there were diagrams to explain the action.

 

I hope it helps to improve LabVIEW help.

 

Regards

 

Rutsu Kenmoku

NIJ AE

 

Currently you cannot edit the XControl components (facade VI, Init VI etc)  if the XControl is in use in another VI in memory. However during development I always want to be able to make a change to my XControl and then test it out.  This involves deleting the XControl from the test VI, making changes, re-adding the XControl, and then rewiring it to anything it's connected to.  

 

xcontrollock.png

 

I understand that the XControl is always running so it needs to be compiled in order to view on the front panel.  However it would be nice if there were some easier way of "stopping" or "disconnecting" an XControl so that it can be edited easier.  I don't know the best implementation of this idea, but I urge any XControl users to comment with their thoughts.  

Common use case for Event Structure is to create a User Interface. 

 

I would really like to see an Add Event Case called "First Run" under the Application category, as shown in the attachment.

 

- Makes it trivial to set up first run options/settings

 

- Executes before the timout begins counting

 

- Requires no elaborate code outside the event structure (usually messes up the code window a bit,) no code to generate pre-event triggers leading into the structure, no special handling of timouts using shift registers (all alternative methods.)

 

- Makes a clean place to always see what happens when the code first kicks off.  

At present, we can add users and permissions to NI auth in the system web server, but we cannot add groups.

groups.png

There is no particular reason for this, as the help clearly implies that there should be a way to add groups:

feedback.png

If you ever want to add users that have more than four sets of permissions, you will start having to manually adjust those settings, which shouldn't be the case. We should be able to add groups, to prevent just this issue.

 

Hello,

 

currently, the Select Inspection state [View complete inspection setup-> setup-> select inspection] in Vison Builder for Automated Inspection allows the decision only by numeric or string values.

 

Therefore if the user wants to only use a few lines/bits, not the whole byte, they need to use LabVIEW step.

 

If there was a way to mask the input byte or to make the input only from a line/lines it would eliminate the need to use LabVIEW step tp achieve this behavior.

 

[idea thanks to a customer's request]

Thanks for your opinions!

Zenon

I'd like to see an optional special case (a "pseudo-event") added to the event structure called the 'All Events' case. The 'All Events' case would include code that was executed before each event. Events would be handled as they are now (normal and filter events) except that if the 'All Events' case existed, an instance of the 'All Events" event would be inserted before every event dispatched. (I'm gonna call it the AE from now on...)

 

In essence it would be a way to execute code before each and  every event that is handled by the user - including filter events. An instance of the AE event would be created and queued into the event chain each time an event occurred - before that event was enqueued. The data passed in to the AE case would be the name of the event that the AE event was generated for in addition to the data passed to that event. 

 

A new property, "Add All Events case'" could be added right before "Add event case" in the events sturcture right-click context menu. Only one AE case could be added to an event structure, and it would always appear first in the event order. Adding an AE event would be optional.

 

The primary purpose of this for me would be to facilitate event logging. We leave an execution trace of our code in an HTML report so that when errors occur we can determine how we got there. With the 'All Events' functionality, instead of having to place logging code in every event case, I could just put it in the AE case, put logging code there, and an instance of that event would be created before every 'normal' event to log the normal event before it was handled. Since the data that the AE event receives is the same as the event that will follows, plus that event's name, logging is a snap.

 

The AE case should be inserted in the event queue as a filter event. As a filter event, the AE case would allow event discard functionality so that even filter events could be discarded before they are called.

 

Implementing the AE case as a filter event has the side-effect that it would make the development of more complicated state machines based on the event mechanism easier because you could enable or disable entire groups of events by using the event discard functionality in the 'All Events' case, in essence turning on and off entire portions of your state machine.

 

Note that two AE events could actually execute back-to-back - if the first AE event discarded the event it preceded.

Based on customer use, there was a "print options" available in Executables back in LabVIEW 7.1, but that is no longer available in 2010.

 

This feature is available in a VI as shown here:

PrintOptions2010.png

 

In executables, there is not a Tools>>Options to select Printing features such as not printing in grayscale.  Can this feature be added back into the Application Builder?

 

Executable.png

 

Thanks!

 

Download All

Hi

 

The customer want to show our 3D graph in rectangular. Which is base on 1 axis's scale.
For example, below graph's Z axis is -5 to 1, but we see it's same length as Y axis from -5 to 5.
So they want  Y axis length stay the same, but Z axis is shorter.  Which the result can be a rectangle 3D cube.

 

 

graph

 

best regards,

Steve

Currently, the "equal to 0" and "not equal to 0" VIs provide a clean way to check whether a number (or array of numbers) is 0, but I often find myself wanting the same thing for other data types.  This VI should adapt to other types which have an obvious "nothing" value, such as:

 

1.png

String - ""

Path - <not a path>

Boolean - false

Refnum - <not a reference>

etc...

I have built this simple VI below to read a string from a text file and then convert it into boolean array. I suggest to have a VI that reads the content of a file as boolean array. This functionality would be beneficial for people who have to deal with for example large arrays of sensors. You think of a special addressing pattern, you write it in a text file and you could read it in with one simple VI and then you can transfer the read boolean array directly to the digital output of your device.

I would like to see an external input to the Sample Compression Express VI to allow a new "reduction factor" On-the-fly. If it's there I can't find it and I was surprised to see no earlier requests in my search. And/Or I would like the data bursts from the DAQ assistant express vi to (optionally) automatically compress the data to 1 point per acquisition group.

Right click on a constant on the block diagram and have an option to "create type def".  Automatically creates a (strict) type def with the name of the constants label.

 

Also - double click type defs to open them for editiing.  Similar to double clicking a subvi to open it.

Drag and Drop for the tree control is missing the ability to detect if a source is being dropped on a target as a child or as a sibling.

 

Thus if the built in drag and drop functionality is overridden there is no way to know if the user is trying to insert the source node in-between the target node & its sibling (if there is one), or if the user is trying to make the source node a child of the target node.

 

One Suggestion is to add a terminal in the event structure that tells you if the user is trying to insert the node or trying to drop the node as child of the target.

 

Adding this functionality to the Drop Over, Drop, and possibly Drag Ended events would be helpful as I currently have to burry this functionality in a right click menu.