Rolf Kalbermatter

Well, it seems I should be able to do something here, sans Mac support, if I leave all the encoding stuff out. There is a potential problem about extended ASCII characters in filenames inside the archive that has existed since the beginning and caused some problems in the past that I was trying to tackle. But no matter what I try to do, it always turns out to cause problems somewhere. So I have started to remove all the encoding translation from the current version in order to get a version out that should be functionally at least the same as older versions of the OpenG ZIP library (but support the new 64 bit platforms and the RT systems). It will still badly fail for filenames that contain extended characters but I'm not really anymore sure it's useful to try to fix that. I might try to add later some simple conversion function on LabVIEW level to handle those filenames a little more gracefully when extracting an existing archive (there is no way to guarantee letter for letter matching between the original archive name and the resulting file name after extraction since LabVIEW doesn't support Unicode filenames yet) but it will at least extract the files to a similar name. As I'm going to ski vacation at the end of this week I don't think I will be able to create a fully featured OpenG package but will try to post a preliminary and limited tested package here before that.

I was allowed a few minutes before the exam to sit at the machine in setup the preferences to my likings. Very important as I still use many settings as they were around LabVIEW 5.1 as default and hating certain things like auto wire routing and auto tool selection.

LabVIEW developers call your writers "stompers". They stomp on the memory they receive as input. The LabVIEW compiler is smart enough to not create a copy if only one data sink is a stomper. It schedules the code in such a way that all the non-stompers read the value first and then lets the stomper use the data. It goes even so far that an input can change its stomper status based if an output of that node is wired and may reuse that input value or is left unwired.

A wild guess but do you call any VIs in there that call into a DLL?

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!