LabVIEW Idea Exchange

This would be implemented on RT Targets such as cRIO or WSN controllers. The purpose would be to significantly decrease the amount of power used by a controller when it is idling. A typical application would be remote field deployements of controllers programmed as either data loggers or WSN controller node. Competing products offer much lower power consumption than a cRIO or WSN controller. If the RT controller could be put to sleep, with a watchdog timer for instance to set the awake timing power could be conserved.

At the moment the only way around this is to have a third party device applying power to the controller...

Thx.

L.

The menu ring is a handy control, but I prefer enums over plain integers for these types of control in most cases. Give us a menu ring with an enum format. (please! )

Since the Error Ring constant is read from  *--errors.txt files at LV startup and then ignored it is cubersome to add new error codes "while coding", you have to restart LV to get a refresh.

Please give us an option to re-read the contents of the errors.txt files from within LV, maybe from within the Error Ring popup dialog.

/LeifS

A lot of Front panel controls have some nice abilities to limit the input of data with optional Maximum, Minimum and Increment values with different Coercion options available on each of these.  Of course these only apply to data entered by the user but I find myself often trying to re-create this input limit through a vast number of property nodes.  It would be really convenient if the control associated with these settings had a VI Server Invoke Node available which would perform this "Data entry" check and coercion when called.  This way we can better synchronise FP and non-FP data entry behaviour of front panel controls in certain situations.

This lovely property setting would be a prime candidate for a control "Invoke Node" via VI Server!

The method could have the option to automatically update the control with the coerced value and also output the coerced value together with a boolean informing whether a coerce took place or not.

Shane.

PS Now that I've posted the inage, I realise that the old value would have to be returned also.......

Hello,

I'd like to humbly and respectfully suggest that "Internecine Avoider.vi" be rewritten or at the very least, refactored extensively.  (again)

This VI is found in "TCP Listen.vi", which is on the TCP palette.  It maintains a registry of existing listener connections and attempts to reuse them.

What's the big deal, you ask?  Well, when I'm having problems with listeners and need to figure out what's going on, sometimes I need to look into this VI.  Like a lot of NI code that I generally trust, I would ordinarily skip over this and disregard it as a possible source of problems.  The trouble is, every time I look at it I can't easily decipher the nuances of what it does, given its messiness.  Thus, though it may be perfectly functional, I don't trust it.

I realize the code could be a whole lot worse.  I also realize that someone has been in there since LabVIEW 2011 was released and has made some improvements.    Kudos to that individual for all the new free label comments.

Nonetheless, here are some factors that obfuscate this VI:

1. There is no documentation under "VI Properties".  What does it do, at a glance?  (I know the answer because I've stared at it over a few versions of LabVIEW)
2. "TCP Listen Internal List.vi" also has no documentation under "VI Properties"
3. Without nitpicking, there are some sloppy practices employed in here that don't make a lot of functional sense.
4. Deprecated "Retrieve Element" case in the internal list VI.  "Item Requested" is no longer a requested item, but the result of a search on elements.
5. "net address" is confusing and ambiguous  Couldn't this be named, "Address of Listening NIC?" (Yes, I know it's documented under LabVIEW help for the TCP listener VI)
6. "Conflict" is ambiguous.  This should be renamed to something more intuitive like, "Conflict: Multiple NICs Using Port" or something similar.
7. Un-typedef'ed clusters in the internal list VI, with deceptive ordering of elements, combined with unnamed unbundler functions.

... etc.

I got to thinking... I know it works, or at least I think it does, but couldn't this be done more simply and elegantly?

I know, I know, "If it ain't broke, don't fix it."  ... but I think it could still use some work to make it more intelligible.

Respectfully,

Mr. Jim

Parallelisation of loops is a great thing in LabView that offers a lot of possibilities and it's very easy to implement. In opposite to this debugging can drive you crazy regularly. A typical situation for me is that there are two loops in parallel whereby the first waits for user input (and handles it) and a second one cycles all the time doing some other stuff.

Assumed that the one with the user event handler needs to be debugged I place a break-point on a good place. When the execution stops there, I usually want to go step by step through the code. The problem is now the 2nd loop: because it is running in parallel the execution pointer jumps always between the two loops. I have to step through each function of both loops even that I only interested in the first one.

This becomes very annoying, confusing and time consuming if there is a lot of code in the 2nd loop, if the diagram becomes larger at all and if the highlight mode is activated.

To avoid this I suggest to show optional elements for debugging for each loop. With those elements I could decide if I only want to step through the code of the first loop while the second is executed normally (no highlighting, no single step).

Current situation:

improved functionality:

A brief digression.  I am doing some Real-Time programming with LabVIEW 2012, and decided to check out the very complete Real Time Control sample project.  As NI intended, I started modifying it to suit my particular Real-Time task.  This Project uses Network-Published Shared Variables to send "Monitoring Data" from the RT Target to the Host.  I changed the type of one of the Shared Variables from Array of Double to Array of UInt8, but noticed that on the Host UI, the output was still a Double.

This project uses a cluster of Shared Variable References, passed from the RT Target to the Host.  I decided to simply "change" the Shared Variable Reference that was returning the "wrong" type with a new Reference that I could (so I thought) bind to the redefined Shared Variable.

I spent well over an hour (more like 2-3) looking for the Shared Variable Reference (or Refnum) on the Control Palette.  One logical place for it to be would be on the Refnum sub-Palette, but it is not there!  I noticed that the reference was of type "Variable Object", so I tried to create a Control Refnum and change its Server Class to Variable Object -- can't be done.  On the I/O sub-Palette, there is a Shared Variable Control, but this is something different -- it is not a Shared Variable Reference.  Finally, I tried copying my Shared Variable to the Block Diagram and right-clicking and doing a "Create Reference", but this option does not exist.

I tried doing a search to learn how to do what I wanted to do, namely to change the Shared Variable Reference so that it "referenced" an Array of UInt8.  Naturally, because I didn't already know the Answer to my Problem, I didn't search for Shared Variable Reference (and even if I had, the information out there is scant).

Here are several recommendations to Prevent Frustration in Users Trying to Use the NI Sample Projects (with specific reference to Shared Variable References).

1)  Put a Shared Variable entry on the Refnum sub-Palette.  This is the logical place to look to create a Front Panel Refnum.

2)  Allow the user to right-click a Shared Variable on the Block Diagram and have, as an option, Create Reference.

3)  If you leave the Shared Variable Control on the I/O page, consider also putting the Shared Variable Reference there (granted, it might not belong, but it's better to be in the Wrong Place than in No Place).

4)  Put a Shared Variable Reference Control on the Shared Variable sub-Palette on the Data Communications Palette.

Note that Point 4 is almost already done, but I just didn't realize it!  You do have the option on this sub-Palette to put a "Local Variable Object Reference" on the Block Diagram (how that for an obscure description?), and if you change this to a Control, presto, you have a Shared Variable Refnum control.

So what seems to be the "solution" to my problem?  I called a colleague on the phone and we noodled this together, and came up with two "insights".  First, the existing Shared Variable Reference that was returning (on the UI Main Block Diagram) an Array of Double could be changed to return an Array of UInt8 by right-clicking, choosing Properties, then opening the right-hand Configuration tab (which I hadn't noticed).

How about creating a Reference Control specific to a chosen Shared Variable?  Put an instance of the Shared Variable on the Block Diagram, right-click, and select "Replace with Programmatic Access" (also not so intuitive!).  This changes the Shared Variable into a Shared Variable Reference Constant, so if you want a Control, just right-click and "Change to Control".  You also will need to delete the Read Variable function that gets put on the Block Diagram.

It really doesn't need to be this difficult, nor this obscure, particularly if it involves a Sample Project!

BS

I have some VME hardware that uses A16 addressing only, so I can communicate with them using VXI, but they do not support VISA at all.  After some time spent conversing with NI support, it appears that VXI has been abandoned, and all low-level VME register access through the NI VME-MXI-2 controller card must be done through VISA now.  I have been able to add VXIin.vi and VXIout.vi (from the old VXI libraries in NI-VXI 3.6) to the latest version of NI-VXI in LabVIEW 32-bit to get the hardware working through VXI communication.  However, these VXI vi's were 32-bit only, and never updated to 64-bit, so I am stuck running LabVIEW 32-bit on my 64-bit OS.  Updating these vi's to 64-bit would be greatly appreciated.

Thanks,

Rich

For development purpose I define in a "IMAQ image control" (typdef 'IMAQ Image.ctl) a default image.

The VI with a image as default value is very huge and not usable in a executable.

After development i would be useful if you could delete the default Value of the "IMAQ image control" by mouse as on array elements ->empty Array.

For some applications I would like to enter an update rate for a while loop with a better than 1 ms resolution (eg 15.4 ms). From one iteration to the next the update period doesn't need to be sub ms accurate. Over a longer period however the difference between 15.4 and 15 ms adds up.

It would be very nice if the "Wait Until Next ms Multiple" would accept a DBL at the ms input and control the update period on average with sub ms accuracy.

I often want to see if a while or for loop is running by watching the loop iterator. Now I have to stop the program, wire the loop iterator to the border of the loop, add a probe to the wire and run the program.

It would be great that I could right click the loop iterator and add a probe while a program is running.

I would like to use this pattern for launching an asynchronous VI:

The specific use case here is to run a specific subVI, but not have to wait for the subVI to complete (i.e. to launch a daemon-like VI).

There are a few advantages to this method:

1) The Static VI reference makes it very easy to open the VI that is being "launched" and make changes.

2) If I change the connector pane of the Asynch VI, the Asynchronous Call By Reference Node updates or indicates that I broke something (like a regular subVI would).
3) The Asynch VI is automatically included in deployed code (exe's, TestStand deployments), because of the Static VI Ref.

The main problem I have is that I can't determine at run time if the VI is already running or not.  That's because the Static VI Reference causes the Asych VI to be "Reserved for Execution" when my launcher VI runs, and always report "Running" for the Execution State.  In the case structure above, I can't take meaningful action based on the ExecState (like don't run if already running), because the returned value is always running.

This idea proposes that the Execution State property (or some new similar property) be expanded to truly tell us whether a VI is actually running or not (regardless of whether it is a subVI, or reserved for execution somewhere).  Since the "Run" button is capable of showing this difference, there ought to be a way to programmatically access that state information.

Hi,

I'm struggling with finding out the proper case in my case structure. It would be nice if the cases could be sorted automatically. Even better would be if we could change the sorting style (asc or desc).

Additional feature could be that the list of cases presented below should react for typing something like IntelliSense. For example, having the list of cases open as on the screen shoot below, if I type first few letters of the case name it should dynamically, (while I'm typing) go to the first case matched. 

Current problem: unsorted long lists are difficult to search

One of the fundamental idioms in LabVIEW is "never use a local variable when wiring directly from/to the control will suffice."  As many of us know, local variables break the dataflow paradigm and should only be used in cases that necessitates them.

No doubt there is much value to using references to front panel controls in architectures such as a QSM, however, I felt like I was commiting sacrilege every time I was forced to wire these references from local variable-like reference nodes while leave dangling controls hanging about. 

Every control has a reference to it under the hood, so why not have the ability to show a reference terminal on the control itself; this way we can start our reference wiring straight from the control itself. 

 Control Values

Control References

I suggest we show/hide the reference terminal using the same method Shared Variables show/hide the timestamp terminal

add an "output" to the condition   (sorry for my bad english)

This would avoid overloading the Diagram

like this :

Get contents of all XML Node Types:

As a beginner at XML parsing, it would be great if LabVIEW had a VI (like Get Node Text Content) but for every node type (it would get the contents, whatever they may be). 

All node types stated here:

http://www.w3schools.com/dom/dom_nodetype.asp

are possible and may require a different set of property/invoke nodes (some have children, some don't, some have values, some don't... and so on).

Inputs: Node handle

Outputs: Raw node contents (whatever XML is contained within the tags of the Node handle), Value (where applicable), Name (where applicable)

Write general string to XML node type:

It would also be great if there was a VI (or set of VI's) that could take an input (as a string) convert it to the w3 conformant XML.  It's important to use the w3 definition, rather than LabVIEW XML for external compatibility.

Inputs: Node handle, Node Type

Outputs: XML string of Node Type

The context menu for a file in the project window always contains the entry "properties" - but the dialog that stays behind is different between LabView-Files and non-LabView-Files. e.g. for a VI the VI property dialog opens, for a TXT-file the windows file-property opens. With other words: I can't open the windows file-property-dialog for LabView files.

I would suggest to have an menu entry "file properties" that opens always the windows file-property dialog. The current "property" entry can disappear for non-LabView files.

Remark: I'm using LV2011SP1