LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

I know hyperlinks in free labels have been implemented in LabVIEW 2015 and that the idea has been marked as implemented:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Hyperlink-in-Floating-Comments/idi-p/986485

Kudos to that and I love it.

However, there was another idea:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Documantation-links-on-block-diagrams/idi-p/3104999

that was closed as a duplicate of the hyperlink in free labels, except there is a small difference in the second idea that was not really implemented. The hyperlinks do not let us insert links relative to the project, the poster of the Documentation links on block diagrams even says: "The risk would be moving the document and the link becomes invalid. This risk could be minimized by placing a documentation folder in your labview project."

So this new idea is to let us either use relative paths on the hyperlinks on the free labels: i.e. file:///C:/ProgramData or use environment variables such as %userprofile%, %programdata%, etc. For example, file:///%userprofile%/documents. This would make it possible to put links to documents in our machine that will be in a different path than the rest of the team working on the project. The documentation might be relative to the project file, but might not be exactly in the same location in each machine due to differences such as %userprofile% = C:\users\<user name> where <user name> will be different for each team member.

Probe terminal

During implementation of code, the algorithm and its implementation has to be tested and debugged in most cases many times. For debugging, probes are a very useful tool. But probes can only be created on existing wires.

If, for any reason, the developer wants to probe values which are not on a wire already (e.g. iterator of a loop), he has to create an indicator (or tunnel) in order to have a wire. Once the debugging is done, the terminal/tunnel and the wire should be deleted.

I find it would be much easier, if i could right-click the data output and select Create >> Debug Terminal. This terminal is part of the code, but once i close the probe, the items created by this option (terminal and wire with probe on it) are removed automatically.

Norbert

PS: I know that there was a suggestion specifically for the iterator of a loop. I understand the reason why it was declined, but i find that using VI Scripting, the above mentioned functionality could be provided. As i WANT to have the information of that wire during debugging, i require that terminal/wire in any case. Using some automated tool would ease the debugging process with the hope to decrease time required to identify the software anomaly.

View All (1)

Sometimes you might have a cluster constant, indicator or control on the block diagram or front panel without the labels shown. When you have a large cluster it's not immediately obvious which element you're editing/changing.

When you hover over a SubVI, the connector flashes on the Context Help window and eventually a tooltip appears on the block diagram under the mouse cursor as shown below:

I propose that, just like when you hover over an input/output of a SubVI it does the same to show the element name on clusters on the front panel / block diagram, as follows:

I know it's not the most exciting of suggestions but I think it would be good for usability.

View All (1)

Hi,

my suggestion is to make it optional within the eventstructure to execute code on each event, before the event specific code will be executed, like follows:

Please see the following example for a better understanding of my suggestion:

This option would make it possible to execute common code which is needed on every or almost every event, or to execute common code e.g. on any userevent. A filter option would be neede here to be able to filter events on which the common code should not be executed, e.g. to only use this option on userevents.

With best regards

View All (1)

Cluster elements bundled in cluster.

When you create a reference to a cluster, the "Controls[]" property returns an array of all the control elements in the cluster.

I suggest a mechanism for returning a cluster of references, with the name of each reference matching the name of the control in the orginal cluster, and maintaining order.

This is necessarily a strict type and only determinable at edit, since you couldn't predetermine at runtime what the elements were. Passing in the incorrect cluster reference type, you'd return an error.

Granted it's only a shortcut for bundling it all up ourselves, and there are caveats and gotchas that will go along with it, but it seems natural to be able to use a reference at edit time and be able to extract references to the elements by name. Does it screw everything up if the original cluster is changed? Perhaps, but it would anyway using the array.

View All (2)

Hi Guys!

My idea is quite simple. What I would like to do is to use DAQmx Read and Write to accept a DVR as input so that I can read/write data directly to memory. This would be really appriciated if it could be applied on a TDMS read/write also (i know that there is a feature like this in TDMS now but it is only applicable on external dvrs).

Pros: Everything

Cons: None

🙂

Sincerely,

Andreas

View All (1)

When you are working with typedefs and classes in LabVIEW, context help can be very useful to sumarize everything that is contained in the class. This list can get very long if the class gets complicated, and has other references to other classes. If you want to know the full path to one of these typedefs, or you want to look at the class library, it would be nice it you could click on the filename and it would open that item in another window.

Otherwise you have to do some looking around to figure out what exact typedef or class the VI is referring to.

View All (3)

Currently all classes in the project explorer are the same blue color:

But it is possible to change classes color on the block diagram, both wires and objects in the following window:

It would be nice if you could change the color of the classes in the Project Explorer to easily differentiate between different classes, for example

The second class from the top has been changed to differentiate it. This would be nice when I have a lot of classes in my projects.

View All (6)

View All (2)

Silver Scale Legend

Provide a selectable Name Format for the Disabled Property Node Constant. I understand making the constant an enumerator to provide code documentation. It would be nice to select the Initials by Function to save wiring diagram space (see below).

Do you ever disable controls, I do it all the time and I’m sure you’ve done this.

I created a VI to do just that and save wiring diagram space.

I’ve attached this VI and a Polymorphic VI version of the Disabled Property Node Constant. Use this Polymorphic VI to substitute the property node constant with an initial by function icon. This will reduce block diagram space while still providing limited code documentation. Select between polymorphic instances E) Enabled, D) Disabled and G) Disabled and Grayed Out, by function just as you would the constant.

Download All

The Close Reference –VI could be integrated into the Property Node ore the invoke node.

I would recommend that the reference output could be activated or deactivated.

A deactivated reference output

would change its appearance
would close the reference immediately after a the call.

An activated reference

should require a connected wire on its output. Otherwise an error should be indicated (somehow).

My comments

An integrated Close Reference –Function would simplify the code and improve the readability.
The output should be changeable in the context menu / pop-up menu of the Property Node.
The default state needs to be discussed. I would recommend to close it by default. Sometimes it is not necessary to close the reference – it would lead to a void operation --> so what? Sometimes it is required to close it later. I think in this case you would find it out after the first run of your vi.
Usually it would not mater if somebody would let some references open. LabVIEW closes open references finally. But if an application should run for several days, left open references could lead to problems. Because of this I think that it is better to close to often than left some references open.
I am not sure how LabVIEW should react if an activated reference output would not be connected. I would recommend to indicate an error. In my opinion this would be an additional new feature to LabVIEW. LabVIEW does check inputs only. But this is another problem to discus.
Perhaps there are other places / VIs to implement an auto-close reference output.

View All (6)

Curently, when we use the Open VI Reference node, there is a numeric "options" input for specifying how to open the reference. For example, 0x01 for "record modifications", 0x02 for "open templates for editing", and so on.

To my best knowledge, the theory here is that is makes it "easy" to combine options, e.g. 0x03 to "record modifications" and "open templates for editing". The problem I have with this method is that 90% of the time I cannot remember the number to go with the option(s) that I want - I end up opening Context Help->Detailed Help, etc.

An alternative way would be to copy the VISA Flush Buffer node: use a ring control for each of this input. that way you could just select the "record modifications" option, or, if you need multiple options, combine them with a OR or compound logic node (or even, take an array of these options as the input, allowing 0 or more options to be select). This to be would be much easier as we wouldnt have to keep on going to the context help.

Let's make it happen! 🙂

Shaun

View All (1)

View All (3)

Maybe it already is but i couldn't find it. If it is then perhaps someone would let me know. if it isn't, as I suspect, here's my idea.

When debugging a program that manipulated a lot of U8's recently I became exasperated by the fact that the probe view window would only display the values of say an array of U8's as a list of decimal numbers. The documentation for the algorithm I was implementing was written entirely in Hex with lots of tables of expected 64-bit numbers printed as Hex strings. Checking between the displayed decimal values and the Hex tables was really tedious and confusing. In the end I gave up using the probe window and created new indicators set to hex. This required quite a bit of reorganisation of the code, which would have been avoidable if the probe window allowed radix changes. This would ideally be on a pre probe basis since some probes will need to be in decimal perhaps whilst others are in hex or binary or whatever.

An option to display an array of booleans as as a hex or other number would have been helpful too.

View All (3)

LabVIEW Idea Exchange

Documentation links on block diagrams to use relative paths or environment variables

Probe terminal

Cluster should show tooltip or highlight in context help with element name on mouse over

Eventstructure with common code option

Cluster elements bundled in cluster.

Data Value Reference (DVR) implementation in DAQmx and TDMS

Block Diagram - decorations - line with double arrow

Resizing array on Frontpanel, show size at mouse position

Link to typedefs and classes in Context Help

Filter option to "hide" controls/indicators that already have a case in Event Structure

Change the color of different classes in the project explorer

Make Project Reorg a Snap! Relocate rather than Display Error when Adding Files to Project

Disconnect all missing typedef.

Silver Scale Legend

Property Node Disabled Constant Reshape

Duplicating True or False case should not (always) create new blank case

Integrate Close Reference into the Property Node

Replace Numeric "options" with Ring on "Open VI Reference"

VI Analyzer Check for Equality of DBL

Radix to be selectable in Probe View Window