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 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.
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.
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).
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.
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.
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 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).
We have developed an external DLL that is called from LabVIEW using CLFN. I have noticed a weird behavior regarding DLL detaching (unloading).
Scenario 1 I have 2 VIs calling the DLL. I run them and then close all of them. In this case, the DLL is detached when the last VI is closed.
Scenario 2 However, if I create project containing the same VIs as in scenario 1, when I close all the VIs after running them, the DLL stays loaded until I close the project.
This behaviour does not seem correct. I think LabVIEW should behave the same in both cases.
What do you think?
Sara
[admin edit: I changed the idea title per user request. The original title was "DLL shouldn't stay loaded when all the VIs calling it are closed".
I discovered the above thread while looking for a solution and I got very disappointed that the discussion in that thread did not lead anywhere...
Rob actually said it all; I can only second him here as my problem is basically the same. Nevertheless, I'm putting it out here for reader's convenience.
In my practice, I often need to create a LabVIEW standard report (for printing on paper) which would contain, among other things, one or more tables. The tables must have columns of different width. Some columns need to be just a few characters wide, while some other columns have to be quite wide. For example, a table of chemical compounds would contain a Sequential number and a Compound ID, and a few other columns. The first column needs to be three characters wide maximum, while the Compound ID has to be much wider (say, 30 characters wide). There is no way I can use the standard LabVIEW "Append Table To Report.vi", since it sets all the table columns to be of equal width. In the past (LabVIEW 7) I was able to do this by modifying the "Append Table To Report.vi" and its subVIs so that the VI would take an array of column widths instead of a single scalar value. It became quite difficult to achieve since NI reworked the Report Generation Toolkit... I ended up importing and using the old toolkit - now with LabVIEW 2010 and 2011, which is obviously not the best solution.
I'm surprised that this issue apparently did not draw more attention so far, since IMHO it's been a glaring deficiency of the Report Generation Toolkit for some time now. Why the Report Generation Toolkit was designed with the assumption that columns in tables can only be of equal width is just beyond my understanding... Generating printed reports with tables is a quite common task, and most of real-world tables have columns of different width - just take a look at a few tables in books, magazines, manuals... A table with columns of equal length is quite a special case of more generic form, and can be easily obtained if needed by specifying the same width for all columns in the table.
Please make the "column width" input of the "NI_report.lvclass:Append Table to Report.vi" an array... To provide backwards compatibility, the VI can be made polymorphic (I hope), so that either an array or a scalar could be used.
