The current implementation of flattening and unflattening from XML is quite noisy and includes information unnecessary for the users. Rewriting it or including Pretty Print functionality to LabVIEW would greatly simplify loading settings, exchange of data with other languages, dynamic configurations, visualizations of complex systems, network communication etc.
Additionally the XML parsing should be implemented without requiring Windows .NET platform components, so it can be done on a real-time system. Current XML parsing functions cannot be called on RT.
Having a continuous integration system is an essential component of software development:
Continuous Integration Process
This system requires automating the building process.
The LabVIEW development environment unfortunately does not have built-in tools to achieve this easily.
But the community has supplied a few sollutions to achieve this: CLI Tool
On of the biggest hurdles that yet remain, is the fact that the application builder is inherently tied to the development environment.
This requires a valid license for the environment and all toolkits / technologies used in the source code of the product you intend to build.
My proposal would be to have a special "CI" license in which all required modules and toolkits are activated, and that would allow the development environment to launch in some sort of protected mode that prevents users from actively developping code (while still allowing scripting functions), for the sole purpose of building applications.
Many built-in functions have the growable ability. Essentially a function that accepts an array of data in scalar form, this saves the step of building an array prior to wiring a terminal. I would like to select any 1-D array on a connector pane and mark as growable. Then when the vi is used as a subvi, the icon would have the growable ability. This could have been used as for example for making a growable error handler or implementing new compound math functions. I know this is probably hard to do and might be possible with xnodes but I dont have time to learn this. It is useful for making reuasble toolkits which look more like the native G functions
Currently, the TDMS File api does not offer a way to get the TDMS file size.
Our use case is that we'd like to limit the size of the TDMS files and span them accross multiple individual files (and I've posted an idea suggestion for adding that as a native feature, too). To do this, we need to be able to monitor the TDMS file size, so that we can save/close the current file and then create the next file in the span for continued use (until we hit the size limit again).
Currently, the Third-Party Licensing and Activation Toolkit doesn't handle PPLs. This makes creating a plugin, pay-per-component architecture difficult. Handling licensing and activation of PPLs is needed as part of TPLAT or some other mechanism.
It would be helpful if the LabVIEW Python node natively supported Python dictionaries as LabVIEW Maps. This would make it simpler/easier to support a frequently use Python structure. You can work around but you have to do extra data preparation/formatting in both LabVIEW & Python. It would be nice if the node handled that converting to list of tuples and building the LabVIEW map or vice versa for us.
In one of my recent projects I had to call a custom made .NET Assembly in LabVIEW which provides several events to register for. As .NET support is generally available (within known limitations), there is but one unknown "feature" that caused big trouble to me and everybody who might want to do something similar:
#please notice that whenever I now talk about anything in .NET, I see the things from the view of C#
Let me give an example code in C# to demonstrate the implementation for use in LabVIEW:
using System; using System.Collections; using System.Collections.Generic; using System.Text
namespace SUPERSPECIALPROJECT { // delegates public delegate void myDelegate( object sender, myEventArgs e );
// the event args (plain example) public class myEventArgs : EventArgs {
// some member variable private string m_strMessage;
// the constructor myEventArgs(){}
// a public property public string Message { get{ return m_strMessage; } set{ m_strMessage = value; } } }
// the public object I want to use in LabVIEW public class myLVObject { // create the event for registration in LabVIEW public event onMessageChanged myDelegate;
/* * I don't want to write any more here, but basically the event above is * fired whenever my asynchronous process feels like it. */ } }
Okay, so now I...
- Build the .NET assembly
- Create an instance of myLVObject in LabVIEW
- Wire the class wire to the Register Event Callback and select the 'onMessageChanged' event.
- Create the callback VI and access the data of 'myEventArgs' within the property 'e', no problems.
So far so good.
However, even though my .NET object runs fine in C# (Yes, I tested it in C# first), LabVIEW does never ever run the callback VI. The reasons were hard to find and I actually had to call NI directly for this. We did some tests and I finally got a confirmation on my assumptions:
1) The asynchronous process does correctly fire the event, but for some reason the developer does not send any 'sender' (the object is just NULL). -> LabVIEW will not execute the callback VI 2) The asynchronous process does correctly fire the event, but for some reason a value of my implementation for 'eventArgs' is NULL (let's say the parameter 'm_strMessage' is NULL). -> LabVIEW will not execute the callback VI
As I have no access to the asynchronous process and have no chance that it will ever be updated for me, I wrote a wrapper that provides my own set of events that replace all null-values by empty values. (like m_strMessage will be "" instead of NULL) -> Finally LabVIEW will accept the love of my events
This behavior is confirmed by NI. The actual event is somehow compared to the callback VI, which will only be executed if the types match. NULL- Variables are not recognized and to LabVIEW it seems as a completely different data type. This will not be changed for future versions unless I get it through the Idea Exchange
The most annoying thing is, if there is any NULL variable somewhere within the scope of either sender or e, the event will fail executing in LabVIEW and LabVIEW only. I know NULL is not a very good practice, but there is no way to replace NULL if you don't have access to the sources (as in my case). The current solution by using a wrapper does work, but takes much time to implement and it has to be maintained.
Finally for anybody who kept reading so far:
I don't see any reason why this behavior could not be changed (LabVIEW does currently just do nothing) and therefore suggest two enhancements:
1) Allow NULL-Variables (auto-replace with empty variables) <-- might be a hard challenge 2) Warn me whenever a callback VI does not match the type of the connected event, as it is currently almost impossible to track properly.
The latter one might be the easiest to implement and would already cover issues with 1) partially. Anyways, we definitely need a better way to catch such issues in the future.
According to this document only 14 ideas from the idea exchange were implemented in LabView 2010.This is a fantastic start.
There are at least 100 more great ideas on the Idea Exchange that should be implemented in the next version of LabView. Keep listening to the users. Keep improving LabView in every way.
I would like to suggest just LVCompare is made available in all versions of LabVIEW.
If LVMerge was also available that would be great, but leaving in just in the Professional version would also work.
As a lone developer I use GIT even on very simple projects to give me the ability to rewind and see what changes I have made. Projects are often put down and picked up weeks later. LVCompare lets me see how far I had got. Its also very useful for picking up debugging that should have been removed. In short Software Version Control just make my life easier.
NI LabVIEW allows VIs with invalid characters such as "?" in the filename inside an LLB file as shown below:
However when it comes to building a Source Distribution / TestStand Deployment that uses this file it returns an error as shown below:
This inconsistency within LabVIEW is quite frustrating where one part allows invalid characters in the filename and another part will return an error. Since the invalid characters are allowed in VI filenames within LLB files I would suggest that the LabVIEW build tools also handle them graciously.
During the build process it could quite easily rename the file "pi40iv Can Connect Channel?.vi" to "pi40iv Can Connect Channel_.vi" and link the VIs that use it to the newly renamed file. The build tools already contain the ability to rename files by adding prefixes so something like this would not be that difficult.
While people may argue to just rename the filename within the LLB and be done with it, the fact that the LLB is a perfectly valid file in the Development Environment but causes problems when trying to do a build is a problem that should be rectified.
The LLB in question is one that is not developed by us but is part of a Pickering Driver Installation obtained from the following location:
It would be really nice is the IDE, and my program were not the same process.
Especially when dealing with 3rd party DLL's, it would really be nice if a bad pointer or misallocated buffer in a DLL didn't crash my whole development environment, but instead just took out the running program.
Using "Edit Palette Set" is cumbersome and painstaking.
Specific use case example: I create a class library that has an embedded menu file that I want to distribute as a compiled packed library (PPL) or even as a source code distribution for re use by other developers. To make the mnu available in the functions palette, you have to manually recreate the menu file to link to the versions of the functions inside the distributed functions, which is painstaking for a larger library.
It would really nice if we had the ability to generate or easily edit mnu files. In the example, a simple search and replace of the paths that the functions in the palette link to would work
The DAQmx apis allow streaming measurements to TDMS. This supports spanning multiple files (by setting the max file size for individual files in the span set), which is very useful.
We need a similar feature for files we're writing to directly (i.e. not using DAQmx) with the TDMS File functions in LabVIEW.
Note: The main reason we wanting this feature, right now, is that our files are growing quite large and when we run the TDMS Defragement function, we get out of memory errors in RT on cRIO (e.g. if we have 512MB RAM on our cRIO and the TDMS file is around the same size).
Alternatives
We're thinking to do this ourselves, however the TDMS file api does not support checking the file size from a TDMS file reference (and that's a great idea, too).
I'm not totally sure how this would be added to the TDMS file api -- maybe there could be a "TDMS Advanced Spanning" palette with options for configuring and interacting with TDMS spanning.
The Property class, which represents the property node, has a property called All Supported Properties which ideally would show all the properties supported by the class the property node is linked to.
The problem is that it doesn't. If you have nested properties which come from another class (for example, the properties for the caption which can be selected by opening the pull right menu, as seen in the top image), those properties aren't returned when you call the property, and instead you just get the property for the caption reference, as seen in the bottom image, where the ControlIndex property is shown immediately after the Caption property.
Instead, I want either this property or a new property to return all of the nested properties as well, just like you get in the UI.
This would be useful for setting properties using scripting and alternate UIs (like this one or this one, which can't work today, because they can't get the full list of properties).
If you are using TCP to communicate to a different code environment, you may want to set some of the socket options. For example, for responsive control, you will want to disable Nagle's algorithm. There is currently no obvious or easy way to do this. TCP Get Raw Net Object.vi in <vi.lib>\utility\tcp.llb will provide the raw socket ID, but you then need to call setsockopt() on your particular platform using the call library node. You can do this with the code provide here. A much better way would be adding a property node to the TCP reference that allowed you to set and query the options directly.
