LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Asynchronous Value Property Node

It is my understanding that writing to the Value property of a Property Node is slow because it uses the UI thread and blocks until the control graphic is updated with the new value. However, one of Dr. Damien's threads (link goes to thead) states that the Control Value.Set property for VIs is asynchronous, meaning that they don't block on the front panel update, and so should be faster than the standard Value property. However, this method is not so desirable since it is dependent on knowing the control's label.

So the question came up: why not have a Value property that is asynchonous?

View All (5)

This ties into a recent post I made on the NI Forum HERE.

I have already run into this problem a few times.

Somewhere in my code I have a process returning an object of a particular class which does not have the exact same type as a dynamic dispatch input. My post above shows a workaround for this (which, if it wasn't so horrible it'd be funny).

I've run into similar problems where the object is being passed via Queue or Event where I have to pass the Objects as a parent class to enable portability but where I KNOW the only source of the data is a VI sending an object of EXACTLY THE SAME TYPE as the dynamic dispatch input.

A normal "to more specific class" does not work presumably because the resulting object COULD be a further sibling of the required object, thus breaking any dynamic dispatch tables.

Up to now I've had to write a class member to take the existing object and another object of type parent and make a cast and update the values manually which is really annoying because it requires each and every child class to implement this (and make use of the parent function).

So what I'd like is a function to allow an EXACT cast of an LVOOP object so that I can still satisfy the Dynamic Dispatch requirements without having to have a piece of code for each and every child class created. If the Object classes don't match EXACTLY, return an error and the contents of the object used for the cast.

Shane.

NXG home edition

The built-in mouse wheel support for numeric controls is very convenient, as it allows comfortable tuning of values using the mouse wheel. But it has a potentially dangerous flaw: the default mode is "On Key Focus", which means that when you click inside the control, you can change its value by scrolling. But when they move the mouse somewhere else in the window and scroll (e.g. in order to zoom a graph), the focus stays in the numeric control, and you unintentionally change the value of the numeric control. This behavior has the potential to damage our hardware, as we are controlling high voltages and pressures using numeric controls.

Setting the Built-In Mouse Wheel Support property to "On Hover" keeps the values from changing when the mouse cursor is not above the control. But unfortunately it also changes the value when the control does not have the key focus, leading to another source of unintentional value changes.

So my suggestion is: If you add the option "On Hover AND Key Focus" to the Built-In Mouse Wheel Support property, accidental changes of values by scrolling could be prevented effectively.

View All (2)

When developing new VIs f the procedure is usually the following:

1. right-click class or desired location, new VI (static or dynamic dispatch template etc.)

2. Implement functionallity

3. Edit VI icon for easier recognition

4. Save VI

The problem here is that usually the icon allready contains the ideal name for the VI which means I am typing the name of the VI twice, once when editing the the icon and once when saving.

Would it not reduce the development-time by suggesting the name entered in the VI icon editing procedure as the user attempts to save the VI?

I'm currently expanding a large SA with 270 classes and on good days I implement 20-30 VIs and would find it nice if I were not forced to type the name twice.

Interested what experienced LV-users think of this suggestion!?

The idea came in this discussion -----> http://forums.ni.com/t5/Machine-Vision/Machine-Vision-quot-Stacked-Sequence-Structure-quot/m-p/2316470#M37848

and of this other idea. ------> http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Rewrite-MODBUS-library/idi-p/2390182

The most examples related with artificial vision or machine vision, have excessive use of the "Stacked Sequence Structure". This is a contradiction, since in the courses, trainings and some discussions in the forums, they always recommend that work with this structure is minimal. The examples, would need to be rewritten.

Here's an example that is in the help.

View All (2)

View All (3)

Taskbar of opened VI

Most of the time I have quite a lot VIs (Blockdiagrams and Frontpanels) opened. Therefore my Windows Taskbar is full of files and it is very annoying to quickly swap between them since they are not identified via their names, only as 'Frontpanel ...' or 'Blockdiagra...'.

Most classic programming IDEs keep track of opened files using a taskbar (see picture)

It would also be nice to sort the opened VIs between Block and Frontpanel.

Fixed examples are: Exclipse, Netbeans, Visual Studio Code

Dynamic taskbar (can be positioned anywhere on screen as overlay): Gimp

View All (3)

After another case of this happening, I did a search, and while I found a lot of suggestions about auto-grow with regards to adding new controls via the BD "Create xxx" menu and some about adding new controls into a Tab control on the FP, I'm surprised that I didn't see any comments/suggestions about how adding a control to the FP can cause an auto-grow oops since you can't really control where the new Terminal is added to the BD.

This is a bit of a frustration for me, I'll have written part the skeleton of my code, my structures in place and sized how I want them. I then swap to the FP to start adding more specific controls, I select the controls I want on the FP palette, drop them, swap to the BD and everything is messed up because some of the controls decided they were part of various BD structures and thus resized things. This isn't just auto-grow, I've had a case where the control was dropped into a case frame and while working with another control, the visible frame was changed, and I 'lost' the control terminal. I was able to find it by swapping to the FP and using 'find terminal' but was still a pain and a bother.

My suggestion is: New terminals added via the front panel are not added to any sub-diagrams in the BP, instead of semi-mimicking their location relative to the FP, just place them near the desired location that isn't already taken up. This way, the only way a terminal is added to a sub-diagram is when the user decides to add it to the sub-diagram.

View All (3)

Different size options for VI's

When placing Icon Text inside a frame in the Icon Editor, there appears to be a rule that the text region is between the lowest two horizontal lines. I'm trying to design an icon with a two-line-width frame, with a lot of empty space in the middle, but this (deduced) rule stymies my efforts. I'd like to suggest that the algorithm be changed to place the Icon Text inside the largest blank space available.

Here is an illustration of the problem. All these images are a one-pixel Frame and a single line of text. In the first image, a single additional line is at the top, while in the second image, a single line is at the bottom. The final image pretty much precludes designing a Template with a two-pixel bottom border, something I'd very much like to do.

Bob "Frustrated" Schor

View All (2)

The "Excel Set Cell Color and Border.vi" (Report Generation Toolkit) sets the background color to white by default. The default value should be "transparent". Unfortunately there's an error in the VI, so "transparent" doesn't work. That's because Excel and LabVIEW use different numbers for transparency. LabVIEW: 16777216, Excel: -4142. A case structure solves the problem (see attached file).

Philipp

View All (2)

Regular expressions in LabVIEW supports parentheses for partial matches, but this fails if your partial match is a set of operators.

Let's say I want to match "XYZ_Level" or "Level", where XYZ can be any number of characters including an empty string, the underscore must be there if XYZ is different from an empty string. These strings are valid candidates for instance:

"Level"

"_Level"

"a_Level"

"much:more_Level"

These aren't:

"aLevel"

"abc_defLevel"

I'd construct a regular expression as input to the Match Pattern primitive like this then: "(.*_)?Level", but this fails matching any of the good examples above. I think the parentheses fail to parse correctly when they contain operators? I have also tried specifying a partial match using the pipe character, like this: "(.*_|)Level", but this won't work either, probably because I need something on the right hand side of the pipe to tell the regex parser that the alternative is an empty string. An empty string is usually denoted by the epsilon character in regular expressions, but LabVIEW doesn't recognize that.

So, (unless I'm mistaken) I'd suggest LabVIEW to support parenthese in regular expressions as means of grouping anything including operators, not only substrings.

Cheers,

Steen

LabVIEW Idea Exchange

Asynchronous Value Property Node

VI Hierarchy - Make 'Group Libraries' work for classes too

Give us some way of FORCING a specific LVOOP cast

NXG home edition

Built-In Mouse Wheel Support: On Hover AND Key Focus

Make Save As always available on project/library items

Faster VI development by suggesting VI name as entered in icon when saving the new VI

The examples related with artificial vision, should be rewritten. ( Stacked Sequence Structure).

Get rid of the "Bell" when opening the icon editor from the block diagram window

Vision Assistant Script File to open vision assistant directly.

Taskbar of opened VI

Inline possible on 'Database Variant To Data' for malleable VIs

New Controls added to FP should not be added to sub-diagrams in the BD.

Different size options for VI's

Change placement rule for Icon Text in Icon Editor

New in-place element structure option - class property node read/write - to ensure access to parent node private data is done in-place

Refurbish examples that are shipped with LabVIEW

Delete a item ( cDAQ device ) in MAX

Error in "Excel Set Cell Color and Border.vi" (Report Generation Toolkit)

Regular expression should support grouping by parentheses as well as the empty string constant