Rolf Kalbermatter

As I said, they may be working for your situation. But plugins tend to be a problem sooner or later. You can't usually just include your own VIs as the vi.lib directory is not present in an application. So you need the entire hierarchy but then you can't use any standard LabVIEW function that exists or uses a VI inside an lvlib or lvclass. With many of the LabVIEW VI libraries being turned into lvlibs recently, this is a serious problem.

One more advice: Don't use LLBs in your code development. It may be ok to do so for the final executable where you want to have certain libraries as container in an external file as some sort of plugin, but more likely you will want to use packed libraries for that anyways. The LLB fails badly for such solutions as soon as any of your dependent VIs are part of an lvlib or lvclass since LLBs can not contain these files so the VI inside an LLB is then broken as it misses its lvlib or lvclass file. Learned this the hard way when upgrading an older application that used LLBs as plugin. Suddenly most of the plugins were broken. Turned out that it failed as soon as a plugin called an AAL function as these got lvlibed in newer versions.

I know it was Michaels post and it wasn't really directly towards you. I fully agree that Release when Ready is the more accurate term in this. And Ready can mean a lot of things as you allude to. For a consumer application it can mean the application doesn't crash if started and used normally. For a mission critical system it really means, we have tested everything we could think of and then some more and could not find anything wrong with it and every engineer working on the changes has evaluated every effect that change could have as far as humanly possible. And ideally there was a real field test on some small scale to actually test the real world interactions too. A release manager can help manage that, but in many cases is just another person in a shorter or longer list of people who exists to dilute the responsibilities if something goes wrong.

A release manager wouldn't necessarily help. But the whole process of upgrading software certainly needs to be adjusted to the possible impact when something fails. Release small and often isn't the fix for this either. Even the smallest bug can cause such a mishap. And releasing small and often does increase that chance rather than decrease it. It also makes rigorous testing even more unlikely.

It doesn't!

It does depend a bit on the system you are working on. If it is the traffic control system of the National Railway company your better make sure that you don't add a fix that adds some regression in some seemingly unrelated area or you are likely to have been in the job for good. Our Dutch railway support organization just managed to create a country wide chaos this week when they installed a new version of the software in the system over the weekend which was supposed to fix something (or why wouldn't they even change the software?). Monday, the control system for the signals in the most important railway station of the country decided to shut down leaving the whole station virtually inaccessible for every train, causing a chaos over the whole country and beyond. The comment the next day in the newspapers was in the line of: We are very sorry, but we saw that already coming on Sunday after we installed the update! I'm sure the new software passed all regression tests they have (I can't believe they wouldn't do that for such a system ) but somewhere somehow something fell through the cracks that when it was stress tested on Monday morning in the commuter traffic, simply failed.

For Windows RT yes, for Raspberry PI running Linux not necessarily. NI Linux RT is already ARM based. There might be problems since the NI Linux RT devices use an ARMv7A based chip while the Broadcom on the Raspberry Pi uses an ARMv6, but the CPU on the new model 2 also seems to support ARMv7. So even that might be working. The only two problems about this are: 1) It's going to be quite a bit of work to port the NI Linux RT sources to run spotless on the Raspberry Pi 2. 2) It's pretty unclear about the licensing implications for the LabVIEW RT parts. While the NI Linux RT kernel is fully open under the GNU license, which makes it fully legal to take it and make it run anywhere you want, this can't be said about the LabVIEW runtime on those targets and of course the many drivers such as DAQmx, NI VISA, NI RIO etc. Especially the RIO and VISA drivers are absolutely mandatory to make the LabVIEW runtime even work on a target and for the seamless integration into the LabVIEW development system.

Actually the 64 Windows version is not the real problem. Haven't tested all but it compiles. What is the challenge is the various Linux variants at the moment.

You're doing yourself injustice. LAVA was anyhow created before the certification program, but that put aside, you don't need a CLA to be recognized as capable of architecting a solution. I'm not sure you read the thread on the German board but the poster definitely has greater problems than just being able to use the less than well architected driver. A basic LabVIEW course or at least working through a few tutorials would help a lot. I can't bring up the patience Gerd so dutifully demonstrates in that thread.

All NI email addresses are normally the <firstname>.<lastname>@ni.com. That should be correct enough to add to the sign up page for the Beta.

Crosspost from the German LabVIEW forum which has already a lengthy support thread about that. Asking here the same question is not likely to give you more information than what you already got, except possibly information that is so Advanced in content that it won't help . LAVA = LabVIEW for Advanced Virtual Architects

That might be a somewhat to categorical statement . Windows 10 is supposed to bring the worlds of Windows Desktop, Windows RT and Windows Phone even closer together, although I still have to see that happening. As such there is at least for the Phone and RT variant a possibility to run on ARM. However I wonder how licensing will work with typical Windows license costs many times the price of the Pi hardware. Of course the extra complication here is that LabVIEW for Windows is strictly x86/x64 so that won't help. You have a much higher chance to get the NI Linux RT kernel working on a Pi since it already supports Linux, so porting the NI Linux RT source tree to support the Pi hardware is "just" a smart pick and combine from the NI Linux RT sources and the Linux for RasPi sources.

LabVIEW does not expose an interface that would allow to load .Net assemblies dynamically. It is actually even so that any .Net assembly that was at some point loaded, will be kept loaded which can be troublesome if you want to debug a self written assembly and try to replace the previous assembly with a new one without restarting LabVIEW. Therefore your best bet is to create a .Net wrapper assembly that implements your plugin interface with one additional method Initialize() or similar that takes a path to the actual .Net assembly and object instantiation you want to use. Then load that assembly in that method and instantiate the object interface you want and store the object pointer in a private variable. All the other methods and property accessors of your wrapper simply forward their call to the actual implementation in the initialized assembly object.

Ohh, man. Now I know again why I didn't use the DOM Parser. This is insane and goes against all and every LabVIEW convention about destroying refnums. But there are other things in that API that make proper resource handling difficult to do.

Right!

There is no general agreed method to close a process from another process. If it is a GUI application, sending it a WM_CLOSE message might work but for some applications just as likely might prompt with a dialog if you really want to close. Command line apps expect a ctrl-C to terminate prematurely but might disable the ctrl-C console handler for whatever obscure reason. The only way that will (almost) always work is to try to kill the process. Almost, because if the process is stuck in some call to kernel mode code it may never receive the kill signal.

I'm aware of it. Figured that trying couldn't hurt, but can only discourage such attempts! And yes it's pretty upsetting and bad for the health although not everyone may develop ulcer from it.

If you send me a nice modern Mac I might be able to work on that. My experiments with a MacOSX installation under Virtual Box were pretty abdominal.

It's called inheritance. Node is a more generic object type than Document but a Document is also a Node. Node does not have the same properties that a document has. The node output of the Get First Matched Node.vi is the same refnum as the input, but since the VI uses a more generic Node refnum, LabVIEW silently coerces the Document refnum into a Node. Principially you could Typecast the Node refnum back into a Document refnum, but that is not really necessary here since you have the Document refnum already available in the VI. Also it is not a safe thing to do unless you know specifically that your Node is a document (only really valid for the root node). So what to do here? Close the Document refnum as soon as you don't need it anymore. The Node refnum out from Get First Matched Node.vi is NOT a different refnum but really the coerced Document refnum you pass into the VI.

You could write for each its own VI library and then dynamically load whatever .Net DLL interface you want to have at the moment through VI server or even more elegantly LVOOP dynamic dispatch.

Definitely have to echo that. If VISA doesn't work for your case only a very complex OOP architecture that will take you years to develop, would!

I'm not going to make any promises here. But I'm working on it and tackled one more problem this weekend. As it seems it is now mostly some more testing for the Linux/VxWorks version and then wrapping everything up in an OpenG package. I might post a prerelease package here for testing and review and certainly will need some assistance in getting the final package uploaded to the VI network somehow.

I have been slowly working to add a few new features to the lvZIP library and also make it Windows 64 bit compatible as well as support for additional RT targets. It's not quite finished yet, especially the support for UTF8 encoding of file names on non-Windows systems proofs tricky to make it work with the LabVIEW multibyte encoding, which can or can not be UTF8 on Linux systems depending on the system configuration. As soon as I get that working I plan to release a new package with support for Windows, Linux and NI RT targets. Sorry no Mac at this time, maybe I manage to get hold of a Mac at some point but that has low priority for me at the moment.

TCP_NODELAY doesn't change anything about the underlaying TCP/IP protocol. It disables a feature of the socket that prevents the connection to cause to send a new Ethernet packet for every little data blurb a program might cause. Since the Ethernet TCP/IP protocol consists of multiple layered data packets each with its own header, an application trying to send a message byte by byte would badly congest the network if the Naggle algorithme wasn't there. And that is not an academic idea. The Naggle algorithme wasn't added because of an academic idea that presented a problem that didn't exist for real! But that algorithme is a limiting factor for command-response protocols that want to have more than 2-3 roundtrips per second. Now you can argue that such a protocol is actually very unsuited for the realities for interconnected internet, where the response time as reported by a simple ping easily can be in the 100ds of milliseconds. But if you want to do communication on a local network it can be helpful to be able to disable the Naggle algorithme. As to if UDP would help: I don't think so. UDP hasn't even a concept of acknowledgement of transmitted data. So it is even more according to the principle: blast it out and forget and don't ever care about who received it, and if any. The socket interface itself has traditionally no way to check the actual status of the network cable. Under Unix flavors there are some extensions available that allow to get the status of an interface node through the socket interface (but not through the actual socket of a connection). And those extensions can be quite different between Unix flavors and even between distributions of Linux alone. Under Windows this has to be done using the iphlp.dll, Winsock doesn't expose an API to query the interface nodes but only inplements the normal Berkeley socket API to handle connections/sockets.

TCP/IP was specifically designed to be robust. This means that the protocol can handle disruptions of a connection and retransmission of data over the same connection or even an alternative connection route. So what you see is not a bug but you simply have different expectations than what is the reality. TCP/IP eventually has timeouts that will terminate a connection, if after some amount of retransmissions no ack or sync was received, but those timeouts are in the range of 10s of seconds. Once the connection has been put in one of the FIN_WAIT, CLOSE_WAIT or CLOSING states even the TCP Write will return with an error but not before. Here is a short introduction into TCP/IP operation and why this reliability can indeed pose some surprises for the unexpecting.