Rolf Kalbermatter

No you need LabVIEW 2010 for this! But I wouldn't expect to much of this. Creating a DLL in LabVIEW and using it from the C environment is certainly going to be an easier solution.

While this would likely work I consider it a rather complicated solution which makes the whole deployment of the library more complicated. Writing a wrapper interface for the DLL (to add the extra error cluster parameter to all functions) is indeed not a trivial exercise (mainly in terms of time, not so much in terms of complication). Especially with open source it also poses the question if you want to modify the original sources or add a separate wrapper. However this is work that has to be done once at creation time and won't bother the end user with complicated setups and non-intuitive usage limitations. If it is only a for a solution for a build once and forget application then it's feasable, otherwise I would definitely try to invest a little more time upfront in order to make it more usable in the long term.

I did test it but didn't make extensive tests. It seemed to work for any combination of OpenG compress -> ALZIP / 7-ZIP uncompress and vice versa as well as compress and uncompress in OpenG. This was enough for me to provide the parameter on the VI interface. I can't exclude the possibility that the generated password might not be compatible with certain other ZIP utilities, and I have also stopped using ALZIP a year or so ago, since they were getting worse and worse in advertisement and eventually tried to push an upgrade to a once free version on the users that was only a trial version and had to be purchased to continue using.

Maybe a restart was necessary. The LabVIEW menu palettes are a bit tricky and while VIPM should attempt to synchronize those palettes after an install, something may have prevented the synchronization to work. A restart of LabVIEW will solve that.

This won't work! While Ledata runs Debian, which is a Linux variant, it also uses an ARM processor (which is the main reason it can be so cheap). LabVIEW for Linux is exclusively x86 (32bit). So the only way to get LabVIEW working on there is to buy the LabVIEW Embedded for ARM Toolkit and create the according interface to integrate the Ledato tool chain. An interesting project but not a trivial one, and certainly not cheap when you look at the price of the LabVIEW Embedded Toolkit.

There used to be a library somewhere on the dark side that contained them. It was very much like my unicode.llb that I posted years ago and which called the Windows WideCharToMultibyte and friends APIs to do the conversion but also had extra VIs that were using those nodes. And for some reasons there was no password, eventhough they usually protect such undocumented functions strictly. I'll try to see if I can find something either on the fora or somewhere on my HD. Otherwise, using Scripting possibly together with one of the secret INI keys allows one to create LabVIEW nodes too, and in the list of nodes these two show up too.

To my knowledge there is no documented C API to the LabVIEW queues. However there is this function PostLVUserEvent() that basically sends back an user event to LabVIEW. This can then be catched with an event structure. Try searching for PostLVUserEvent either here and on the NI LabVIEW forum and you should get a whole bunch of discussions and even an example or two from where you can pick up.

It's likely to get enabled when Microsoft ports their MSI software to Linux. In other words, never!!!

Likely because they make use of the undocumented UTF 16 nodes that are in LabVIEW since about 8.6. And these nodes are likely undocumented because NI is still trying to figure out how to expose that functionality to the LabVIEW programmer without bothering him with underlying Unicode difficulties including but certainly not limited to UTF16 on Windows v. UTF32 on anything else (except those platforms like embedded RT targets were UTF support usually is not even present, which is an extra stumble block to make generic UTF LabVIEW nodes]). Of course they can include the IBM ICU library or something along that line but that is a noticable extra size for an embedded system. It all depends what you consider as "proper". Those nodes will likely make it into one of the next LabVIEW versions. However to support Unicode in every place including the user interface (note LabVIEW supports proper multibyte encoding already there) will be likely an exercise with many pitfalls, resulting in an experience that will not work right in the first few versions, and might even cause troubles in non unicode use cases (which is likely the main reason they haven't really pushed for it yet). Imagine your normal UI's suddenly starting to misbehave because the unicode support messed something up, and yes that is a likely scenario, since international character encoding with multibyte and unicode is such a messy thing.

Actually the proper fix would be to use Pointer sized (signed or unsigned) integer instead. Then you can forget about the conditional compile node. This CLN datatype is available since LabVIEW 8.5.

Actually it is a bit more complicated (or not) than that. On all 16 bit systems int used to be 16 bit and on 32 bit systems it is 32 bit. So far so good. For 64 bits things get a bit messy. int here is still always 32 bit (well for the majority of systems, some more exotic systems use actually 64 bit int's) as detailed here (Specific C-language data models). The most interesting part is however with longs where Linux 64 bit uses 64 bits, while Microsoft Windows chose to use 32 bit longs.Linux is more forgiving to code that casts pointers into longs while Windows is more forgiving to code that assumes sizeof(long) == sizeof(int). Both assumptions have of course no place in modern software, but many programmers can be sometimes a bit lazy.

Well you can convert C algorithmes quite easily into the formula node as that one supports a subset of C. For whole C programs there is simply no way to translate that in a meaningful way into a LabVIEW program by automatic and in fact even translation by humans is mostly an exercise in vain as the runtime concepts are quite different. And if a human can't do it how could you come up with an algorithm that does it automatically. I'm not saying that you can't rewrite a C program in LabVIEW but that is not translation but simply reading specs (here from the C program) and writing a LabVIEW program from scratch. C is in no way as formal and strict as more modern design paradigmas such as UML etc. and I haven't seen LabVIEW code generators that can translate such design documents readily into LabVIEW VIs. If it is indeed simply the code generation part from the embedded Toolkit (and I'm almost 100% sure it is), then all I can say is: The code generation works but it ain't pretty to look at. Personally I don't see much use in generating simply C code. The embedded Toolkit makes some sense when used with a preconfigured tool chain for a certain target but just generating C code from LabVIEW code is not much more than for the wow effect. Converting a simple VI algorithme into C is quite a bit leaner and meaner when done by hand and converting complex programs is likely an exercise in vain as there are to many dependencies on the underlying runtime and OS environment that this could be done in a really generic way .

That is logical. abort() is similar to exit() which is simply a C runtime function to - yes indeed - abort the current process. Exit does try to do some extra clean up before returning to the OS, but abort simply yanks out the floor under the feet of a process and hopes that the OS will be able to clean up the mess that remains. Your GetLastError function might have threading issues. Unless you configured your Call Library Node to execute the DLL function in the UI thread LabVIEW will call that function in any of the threads in the current subsystem and that can be in modern LabVIEW versions up to 8 threads or so. So there might be a problem in storing the error code and trying to retrieve it with another function, as that second function may be called from a different thread. If you store the error in a thread local storage, as Windows does with its GetLastError() you have a very small chance to retrieve the same error value than what was written by the previous function call, and unless you force data flow strictly chances are completely off. Personally I would add an error handler that takes the current parameters and a LabVIEW error cluster as parameters and stuffs the first into the second and also returns an error code (the same stuffed into the cluster) which you can return from the function call to LabVIEW. Every DLL call gets an extra parameter that receives the error cluster and this parameter gets passed to the error handler function whenever it is called. Not knowing the library nor its circumstances I do not know, but if it is truely dual licensed you would be free to choose the license you like for your distribution. The dual licensing here was likely done so that (L)GPL projects could use it, since especially the GPL is considered by some almost incompatible to anything but itself. BSD would seem to me so liberal that it should be easily usable by GPL program, but I believe some GPL critics think that that is not the case.

It's definitely NOT possible. ActiveX is a monster that builds on Windows 3.1 OLE technology and making LabVIEW create ActiveX controls would be almost impossible. ActiveX Automation servers might probably work but why settle for such a crippled beast? As already mentioned you can create .Net assemblies but that is not a .Net control either. Making LabVIEW GUI elements embed into Windows .Net and ActiveX GUIs is only really possible on the lowest platform API level by embedding entire LabVIEW panels into other windows.

Can't really help you with that (well I could theoretically but don't have enough time currently to spend on these things). But if you want to go multiplatform you definitely want to write external code in form of a shared library. Maintaining such platform specific code in the diagram is a major pita. So I guess DLL/shared library it is going to be . Also additional bonus points/troubles for making the that code NOT depend on platform specific icon resources .

Well I guess they all are possible venues, but!!!!! 1) is best if you have the entire algorithm available and also have some good test cases. Porting the algorithm is one thing but proofing it does indeed do the same thing as the original is quite a different beast (and can often take up a lot more time than (re)writing the algorithm itself). 2) Depending on the algorithms used and the way the code is written this could be a complete rewrite as well maybe even employing a different algorithm (if possible) to actually allow parallelization. 3) Quickest and dirty solution 4) This is probably in terms of efforts quite a bit smaller than 1) and 2) but of course depends on the algorithm used if there is really much potential to gain performance.

No Ton already mentioned it although didn't say so specifically. For the libraryname you enter <name>.* and make sure that the .DLL and .so are in the same directory on the respective platform (they can be both present on both platforms but don't need to be). Then LabVIEW will replace the * at the end with whatever prefered shared library extension for that platform and load the resulting library.

Are you sure you have 32bit LabVIEW installed and not 64bit? You can't call a 32 bit DLL from a 64 bit application or vice versa. They live in completely different environments and have no direct access to each others memory. What do you mean with the DLL returning 0 for the reference while the Automation Open crashes? Is this DLL an ActiveX DLL or a normal DLL, accessed through the Call Library node? Otherwise there might be a problem with registration of your component/DLL.

Actually the issue here is most likely that sys.path is not initialized or at least doesn't contain the directory where your socket module is. LabPython does not do much of environment initialization when you create a session (and the Python script node is also simply creating a session implicitedly). So whatever the Python core doesn't find on its own you need to setup yourself. For the script node you would need to add the module directory path to sys.path and for a programmatic session you could execute a statement that sets sys.path accordingly before you execute a script that tries to import things.

Another workaround I use occasionally is to include a property node that access some property of a front panel element. This is a NI sanctioned way going back to LabVIEW 4 or so and I suppose they will not break that intentionally, even-though they may wish they never had used that workaround anywhere.

The OpenG Pipe Project does just that. It is a LabVIEW Library that replaces the System Exec function and returns pipe refnums for the three standard IO interfaces and functions to read and write to those refnums. The project hasn't been released yet as I consider it not entirely release quality but it does work for me and I have actually used in in several of my projects already. Since there is no officially released package yet you can't just download it through VIPM from internet. But here is a copy of a package you can install using VIPM. oglib_pipe-1.0-1.ogp

I heard the ADI Blackfin Embedded Toolkit is going to be discontinued. I'm sure you can still get a version if you have inside contacts but they are not going to develop it further and support is probably going to be minimal.

Can someone post the labview.lib file from the cintools directory from a LabVIEW 2009, 64 Bit for Windows installation? I need that to make some compile test for a 64 Bit version of the ZLIB Tools DLL, but haven't a 64 Bit machine handy where I could install the 64 Bit version of LabVIEW.

Well, there has recently been some work on the underlying ZLIB library to make it ready for 64 Bit. There is also a ZIP library on top of that that will require some careful review for 64 Bit compatibility. I think there might be a few issues there. Then there is also the VI library which would need to be updated to use pointer sized integers for some of the parameters. Last but not least this all needs to be compiled with a 64 Bit ready Windows compiler. I guess one of the Visual C Express Editions might do the trick but I haven't done any work in that direction yet. I have plans to incorporate the recent ZLIB 1.2.5 version into it. This is mostly a simple replacement of existing files in the source code and should help to make that part fully 64 bit ready. Then I will need to setup a working 64 Bit compiler tool-chain somehow and get a bit familiar with it. The real work is trying to find areas where 64 Bit might cause issues. Even if the code compiles fine and seems to do work, that is no guarantee that all the critical areas are fine. So all in all in it is quite some work and even more testing and I'm at the moment a little tied up with other stuff. I do intend to work on this if nobody else beats me to it, but it is for sure not just a recompile. And since the code changes in some ways there will be a new release of all shared libraries necessary and for true 64 bit support pre LabVIEW 8.0 support might have to vanish.

And I'm not going to read all caps text. sorry!