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.
The output from flatten from XML is not as elegant as it could be. A big advantage of XML is that it is both human and machine readable, but flatten to XML seems to really neglect the human aspect, and can be a bit akward to process.
Here is the output from a simple structure using .net serialization:
Its still not as elegant as the .net result, but I think it looks better than the original. This may seem like a trivial issue with the small XML files I presented, but when you are storing much larger data structures in XML it starts to become a big mess.
I'm working on large AF projects and I want to be able to pack my actors into lvlibps as there are lots of benefits of using PPLs. However, I'm a bit uneasy about distributing the PPLs with the executable because it's possible to reuse the public methods in a PPL. (The software I write is mostly licensable, but it would still be possible for competitor companies to reuse the public APIs)
What I would like is a way of securing/encrypting PPLs when distributing the executable.
I really like using VIMs; however, I have been having a lot of issues when saving for previous versions / VIM based bugs.
What I would like is a right-click (under the advanced tag) to convert VIM to VI copy (which you could then save) and a 'tools>Advanced>replace all VIM instances in the project' tool.
I attempted to make this myself, but it turns out the 'Replace' scripting method doesn't work with VIMs and I don't really want to go down the route of deleting, placing, rewiring.
So either, could I suggest creating the tool, or providing the scripting functions for us to create the tool.
NB: This is the proof of concept I was trying out to change VIMs to VIs:
When you want to find out where exactly a control is located on a computer screen (for some dark reason), there is a method for Panes called 'Convert Pane coordinates to Panel coordinates'.
However there is no easy way to get the owning pane of a control!
The propery 'Owner' of a control always returns the actual VI, not the pane.
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.
One upon a time there was LabVIEW 5.x and MS Excel...
At that time MS Excel (97 or 2000) could be controlled through ActiveX and some examples in LabVIEW 5.x where showing how to do that.
Each NI partner or LabVIEW user who wanted to control Excel by LabVIEW had to imagine how to save the necessary ActiveX references like Excel_Application or Excel_Worksheet.
Then LabVIEW Report Generation Toolkit 1.0 for MS Office was born. Let's call him RGT
It was wonderful !
LabVIEW 6.x and RGT gave us a lot of functions and a new framework (template) for building our own functions.
The GOOP approach in RGT was including the access of many ActiveX references and parameters through one single reference : the magical "Report Refnum".
Instead of maintaining our old functions, we used RGT and transfered our custom functions to this new environment.
Example of Excel Save As function :
As you can see, it was very easy to get the ActiveX reference and modify them (unbundle / bundle).
Until LabVIEW 8.5.1 and RGT 1.1.2, the weather was nice is this area...
-----
Then came the Objet programming in LabVIEW 8.0 and NI decided to rewrite RGT with this technology in RGT 1.1.3.
RGT 1.1.3 which came with LabVIEW 8.6 was catastrophic in terms of compatibility.
You get a big headhache when trying to build an executable which used RGT.
Some of our custom functions where broken. There was no way to repair them.
RGT 1.1.4 soon replaced RGT 1.1.3 and gave the possibility to get the ActiveX references from the Excel class by adding the "Get ActiveX Reference" to the class.
Most of our custom functions could be repaired but not all of them since the "Set ActiveX Reference" function was not added.
Until now, some of our projets are locked in RGT 1.1.2 and cannot upgrade to LabVIEW 8.6. (or above) because of this missing function.
Mr Eagle Man,
Please add the "Set ActiveX Reference" in LabVIEW RGT 2011.
In Visual Studio you have XML Schema tools etc. It is a breeze to e.g. populate a drop down menu based on XML from a web service, and my first thought when I see it in action is - why do we not have this at our fingertips in LabVIEW already? LabVIEW could have made it simple to create schemas, generate flexible XML etc. You could have wizards that helped you, and cluster to xml conversion like in EasyXML from JKI - and it should all feel fully integrated (toolkits are OK, but this really needs to have native support).
I am currently developing a web service in LabVIEW and the first thing I had to do was to abandon the few in-built XML functions and write my own serialization code (using terminal mode for the web service gave you XML without proper headers, and the in-built flatten to XML outputs XML is impractical in use). Once I have serialized a text table e.g. and published it - using that table feels incredibly easy in Visual Studio (add data source-> input web address etc.) , it would be much more difficult to do the same in LV.
I think NI should make a big leap in the use of web technology. The RESTful web service functionality was a great addition, but the doumentation is non-existing, and we should have come much further by now. I know there are some cool experiments going on with web based GUI editors, but LabVIEW 2010 was just released with very little news on this front so forgive me if I rant a bit...
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".
This may not technically be a standard LabVIEW Idea, but it is an idea nonetheless and there is no where else to post this idea in the Idea Exchange Forum and I want get other peoples feedback.
I would like to suggest that sending packages (.ogp, .vip, .vipc files) to NI Support is an acceptable way to submit code for reasons relating to code (support, issues, review help, CARs).
I have had problems sending code and then sending all dependencies as well, along with instructions on where to install etc... (for example here) that was solved once I was able to convince my support AE to install VIPM. It also saved me a lot of time (other I had to rebuild code in order to send it as well etc...)
(IMHO) I think this Idea would compliment NI moves towards establishing it's LabVIEW Compatibility Program (which I am assuming VIPM and OpenG will be covered under)
Additionally there seems to be great acceptance by NI to packages already whereby I have seen NI code in documents/white-papers posted as packages.
Thanks to Christian L and Laura F these files types are now compatible with the new NI Forums.
Here are some of my notes on this Idea:
VIPM Community Edition would have to be installed internally (but it is free so there would be no cost)
I am not looking for NI to support VIPM itself (unless it is covered under the Product Partner Program?) only that I can send a package to NI Support and they will know what to do with it and be able to install it
OpenG would also be required to be installed as well (after all it is the LabVIEW main/only? Open Source movement) (this is free too).
That way I would not have to send large dependencies files (only include my internal package), and then email size would not normally be an issue (although I have used NIs FTP successfully in the past due to large files) but email is nicer.
All this would lead to a more streamlined approach to Support for those developers who rely on packages
This is something that started as a way to get data back from Actors in non-actor code (for example, web services). I've never cared for the blocking nature of Reply Msgs and the only other built-in option for getting back data is to make everything an Actor, which is not always an option. Promises solve both of those issues.
The basic idea is an enforced single-writer, many-reader cross thread datatype. In the current implementation, they are not much more than a locked-down, single element queue but you can actually do some pretty cool stuff with just that.
In the message sender, we create the promise and return it. The idea here is that the Actor owns the promise and will fulfill it. This gives us very low coupling for free.
Wait on Promise will wait for the Promise to be fulfilled. It is a malleable VI so that a Default Value (for timeout) and Type can be wired. Using the timeout lets us do other things while waiting for data.
Inside the Actor, we can set the value with Fulfill Promise. Remember, once the Promise is set, that's it, no changing it again. In fact, Fulfill Promise will error out if called twice on the same promise.
Something else really cool we can do is fulfill a promise with another promise. This may seem pedantic at first but it can help keep your code cohesive by passing the responsibility of fulfilling a Promise to another process. For example, if you have a message broker that just forwards a message, you can have the message broker fulfill it's promise to the caller with a promise from the callee.
We can also reject a promise with an error message that will be returned by any Wait on Promise that tries to read it. Rejecting a promise does fulfill the promise so you still cannot set the value later and you cannot reject a promise again.
Finally, we have Destroy Promise. It does exactly what it says on the tin.
I'd love to hit some more of the design points from https://promisesaplus.com/ (mainly adding Then callbacks) but I figure it's at a pretty good spot to share and get some feedback. I'd also like to try to figure out network communication at some point but that's probably a ways away (without some help anyway ).
It would help to have an option to ignore Bad VIs errors when calling a mass compile via LabVIEWCLI. This makes the CLI MassCompile unusable for deploying code with NI Package Manager that has API Tree VI. It would help to have an option to ignore those errors so that NI Package custom execute could run successfully. I would think it could be defined as optional argument. My suggestion for the argument is -IgnoreBadVIs true|false with a default of false.
To statically use a packed library as a dependency, you need to add the library to the LabVIEW project. After that's done, all the callers link to the packed library. If you're strictly a library user, then whenever you need a library update you simply ask the developer for one.
But what happens if you're a packed library user and developer of the same library. You can't use a packed library as a static dependency until you build it and replace the lvlib with the lvlibp...but you can't develop the packed library after it's been built and replaced in the project.
If you're a user and developer, it makes sense (to me) to maintain two separate projects. One manages the packed library resource, one manages the application.
What if there were a way to revert the packed library to the LabVIEW library from the same project? You could use the spiral development model and simply switch between the two types of libraries during development. You could also (and this IMHO is the most important part) incrementally deploy and test the project. If you're strictly a packed library developer, hopefully you're incrementally testing anyway.
My final pain point with the packed library is with respect to upgrading the application. Similar to above, if you're strictly a user, you pray the developer is still in business and ask nicely for an upgrade. If you're a user and developer, and you didn't maintain two projects, you might think to replace each static packed library subVI in the application with the original source and then rebuild the lvlibp. Or you might think to create a new project that includes the lvlib and rebuild the lvlibp yourself. I haven't tried it, but I hope that you can replace the original lvlibp with the lvlibp from a new project (not the one that created the original lvlibp).
This leads me to a best-practice for lvlibp: always use them as dynamic dependencies. That way, you can maintain and develop the packed library in the same project that uses the packed library. You'll simply reference the resources differently.
Even if you don't kudo this idea, I'm very interested to hear your feedback and experiences with the lvlibp.
LabVIEW currently allows users to execute a MATLAB script inside the "MATLAB Script" structure, which lets you add inputs/outputs to the edge, set datatypes, and then type your MATLAB code in the central box.
If you already have a MATLAB script, you can use the right-click menu to "Import" (and conversely, you can test a script in LabVIEW and then Export it, if you wanted).
However, you cannot link to a script by path. Importing simply copy-pastes the content into the Script node. This behaviour, whilst probably useful in some cases (avoid future changes to the .m file breaking your nicely tested LabVIEW code) is different to most other nodes I can think of (Call Library Function Node, Python Node, .NET methods, ...).
Please add an option to pass a path to a "myFunction.m" file to the MATLAB execution system rather than copying the contents of a .m file into the structure's box.
(As a workaround, I believe this could be accomplished by running the MATLAB interpreter via command line and using the System Exec node, but that would require various path -> command line string parsing operations, and perhaps complicate cleanup of VIs using MATLAB.)
Currently when binding a .Net Constructor node to a private assembly the vi saves the absolute path to the assembly. This behavior causes a lot of pain when multiple developers working on the same project have the source code repository mapped to different local directories. Every time I load a project I go through several iterations of Labview/.Net searching for the "missing" assemblies. Depending on what I have on my disk at the moment, oftentimes it will bind to a dll that's in a completely different project.** Trying to find a workaround for those vendors who refuse to put their assemblies in the GAC has been problematic.
Note I'm not asking for a path input to the .Net Constructor node. I just want the option for the path to be stored internally as a relative path rather than an absolute path.
**This is a little odd given private assemblies aren't supposed to be loadable outside of the given .Net AppDomain. I guess there's not a 1:1 correlation between Labview app domain and .Net AppDomain?
In LabVIEW 2009 one could right-click on a VI, for instance, in the project Files view and select a Delete from Files option. (It didn't work perfectly--in particular, LabVIEW didn't always delete folders from disk, but it usually did work for individual VIs.) NI removed this option in 2010, leaving the developer with the task of deleting files manually through the OS files view. (This isn't the end of the world, of course, if a developer doesn't use integrated version control--and we don't currently but only because LabVIEW does not properly support integration with Subversion--but it is a significant inconvenience.) This option ought to be present once more.
In particular, this function is absolutely required if LabVIEW makes a claim to provide integrated support of version control. On that note, the current client (Pusk Ok SVN) LabVIEW supports for what is probably the most popular version control provider (Subversion) among its customers does not even claim to support file renaming or deletion (http://www.pushok.com/soft_svn.php), while a third party plug-in (http://jkisoft.com/tortoisesvn-tool/docs/) claims to support this behavior only for VIs and Controls (not, for example, LabVIEW class files).
).