By using the VI-server reference "pane" > you will obtain a array which contains a reference for each used element. This VI-server reference can be wired in any sub-VI, to check for example the state (value) of a element. Into the respective sub-VI the array function "Array Index" can be used to check the value of the element. Everything will work fine, until you put another element into your frontpanel. At this point, LabView change the order of the reference array. Now the user wish to have a function, to edit the reference number of each element (like "Change order of elements in cluster"). The problem remains, even if the new element will be deleted.
I have searched but couldn't find any idea about that. At block diagram, if we ctrl+drag any variable Labview creates a new copy of the same object but when we ctrl+drag any terminal it creates a new object (terminal). I rarely create a copy of the terminal from block diagram. Sometimes if the code is really huge and you put a terminal inside the code without being noticed when you drag that code it becomes hard to clear new terminals. I think it would be better if Labview creates the local variables of the dragged terminals. Front panel action and ctrl+C - ctrl+V should stay same.
Currently the IMAQ (Vision) display windows maintain a separate event queue which can only be accessed by polling for new events. This should be integrated into the LabVIEW event handling so that all IMAQ events (e.g. Click Event, Draw Event, Move Event, etc) can be event sources for the Event Structure.
If you have a log graph that has a range from 10 to 1000 there is only one label (100) between the min and max.
I have found this to be confusing for the end user since the minor increments change from 10 to 100, having labels would clarify the data for them.
During LabVIEW Development was a PXI Real-Time System connected (LAN) next to my Laptop and process Build/Deployment was no problem.
Now the RT has been shipped far away to customer site and i have no longer access to that network.
So I need an other way to distribute and
here is my IDEA #1: (below is another IDEA #2)
FACT : Most of all customers have no knowledge about "How to find the Real-Time System and update the Application on it".
So the new item will built an "Offline Installer.exe" and will run on any customer PC to a full automated update job automatically.
- create a detailed installation report which can be stored and send back to the developer.
- In case of the Real-Time System isn't connected to any LAN, the customer could use the "Offline Installer.exe" to prepare an USB-Stick which has to be plugged into the Real-Time System. Then a reboot will launch the full automated application update process. (the "RT LEDs" will give feedback when the process is finished)
I tried also another way but without success:
Step 1: Add a ZIP File into the Project Explorer : "My Zip File"
Step 2 : Configure the "My Zip File" => Add "My Real-Time Application"
Step 3 : Build "My Zip File"...but the Result was bad :
But anyway, if the would be successful there are a lot of more steps needed:
- sending the ZIP to the customer
- unpack ZIP
- find Real-Time System at customers network
- a FTP tool is needed to update the system.
- There is no way to stop the running Application (from a PC without NI-Software)
The update with "ZIP" is far away from a comfortable solution.
If the Real-Time System has a running webserver (the thing which is using Silverlight),
then the application could be updated by using a webbrowser.
So, first we have to update the webserver on the Real-Time System (as difficult as updating the application)
Almost always when I use enums in a case structure I want them sorted. As I change and add elements to a type def enum I have to go through my case structure(s) and sort them manually. Why not have case structures auto-sort enums unless an different order is specified?
When creating large state machines or using structures that have a lot of code in them, we come to a situation where the structure becomes incrementally larger as we develop. A structure can easily expand with small actions, however, if we later want to shrink the structure it is not so easy, especially with case structures.
I'd like to have a way to lock a structure in place so that it is impossible to expand it unless it is unlocked. That way it will help keep the code neater and also force the use of subvis in places where there is a lot of code. An option on the context menu would work.
Another option would be to lock the structure such that code could not expand it, only by intentionally clicking on the edge of the structure and resizing it could.
Right on the heels or Darren's idea, here's a related issue along the same lines that has bugged me for years. I think the same arguments (and more!) apply here also.
When opening the front panel of an express VI, I suggest to get rid of that warning dialog shown here.
The warning is wrong, because I can just go to the main VI and press "undo" to get the old configuration dialog back, including all customized values. This is not a dangerous one-way operation as one might think from the wording of that dialog!
At the same time maybe the right-click menu should be clarified. Instead of the innocent "open front panel", it should read "convert to regular VI" or similar, because that's what it mostly does. Opening the front panel after conversion is just an additional convenience.
It would be nice when Folder Auto-populating will populate VIs to LV Class (.lvclass) and to LV library (.lvlib).
When we use Folder Auto-populating in projects then project hierarchy match disk hierarchy. It would be great when class and lvlibrary hierarchy match too.
The Labview Web Services should support digest access authentication (RFC 2617) in stead of NI's own inventions NI Auth and NI API Key (the latter is broken in 10.0f2). Digest access authentication is becoming a standard and is intended to replace basic access authentication since it doesn't send passwords in plain text over the web. It is very useful for cases where HTTPS cannot be used, for example for performance or legal reasons.
Digest access authentication does not require Silverlight at the client side like NI Auth does - it requires only a recent browser. In this way the choice of HTTP clients is much less restricted and for example a cell phone can be used too.
It shouldn't be that difficult for NI to get this done, the webserver behind it already supports it. Of course the Labview HTTP Client should also support digest authentication.
I will write this off to my **bleep** retentive personality, but what about an option that would allow wires to enter/exit structures from the left and right sides of the structure only? The left would be enter / the right exit. When the source of the wire is not visible, and the entry/exit point of the wire is on the top or bottom of the structure, I sometimes find it hard to see the data flow direction.
During the course of development, I often find myself hiding the labels of controls and indicators. During the construction of the block diagram, I inevitably find myself needing to know the name of a control or indicator. This means that I have to either show the label on the front panel or double click the control/indicator to find it on the block diagram, thereby loosing my place in the block diagram. I propose (an optional) tooltip that would appear when the mouse is hovered over a control or indicator that simply shows the name of the control/indicator. This functionality would only make sense during non-execution of the VI.
The prevalence of systems with more than one display suggests the addition of a "monitor" input to the unused terminal on the connector of the File Dialog function. This U16 input should allow developers to specify a display using the VI Front Panel Window:Monitor property. In addition, this function should appear on the Advanced File Functions subpalette. The File Dialog express VI should be promoted to the File I/O palette.
We update software often. Sometimes we need to know which version and build a customer is using.
My executable should be able to fetch that number when it starts up and add it to the Help/About... menu item or display it at the top of the Panel.
When building a LabVIEW executable, the build system knows that version/build number.
Let it format those numbers into a string and write it out to a dedicated textfile or add it to the .INI file.
Then when my executable runs, it can fetch and expose that number as needed.
When building strings from many sources using the "concatenate strings" vi it very quickly becomes confusing and unreadable. The vi is very small, the inputs are very small, the wires are very close together and require many crossings. It would be very useful if right click on this vi would bring up an "expanded size" option that would double the size of the input terminals. Another right-click option that would be useful would be to rotate the vi 90 degrees so that the inputs are on the top. This way you could arrange your inputs from left to right in the order that you with them to be concatenated, and then wire them to the vi without needing to cross wires.
When dragging a snippet onto the block diagram, its code should remain selected so we can immediately drag (or use the arrow keys to move) it to a better location.
Currently, the new code is not selected and it is nearly impossible to separate it from the existing code, for example if a complicated snippet is dropped on an already complicated block diagram.
(Not everybody has a gigantic screen to resize the existing BD for plenty of whitespace. I also often only have a small strip of the BD showing, with the explorer window containing the "droppee" on top. Dragging the snippet to the BD invariable ends in a complete mess.)
In most every text-based programming language there are built-in functions to convert a character to its decimal ASCII code and a decimal ASCII code value to its associated character. In BASIC, for example, ASC(character) does the former and CHR$(code) does the latter. In LabView you have to implement these functions yourself from scratch with a CASE structure. If you want to do the whole 7-bit character set you need 128 cases. This is a waste of time! Since many instruments use single ASCII charcters as their commands why not include such functions in LabView?
The thumb tack in the palette is handy. But it disappears when we right click a node to find the corresponding palette.
So there has to be extra steps when I want to find more relevant nodes. What I really want is adding the thumb tack to it as in the normal palette, like: