Rolf Kalbermatter

Relaying on online services is a tricky thing to do in a product. Those services do go away, change their API contract, and what else. Besides there are many people who are behind a firewall and don't have all kinds of access to certain things, that non-corporate users are taking as totally granted nowadays. It may seem a very nice addition to the snippet function, yet the inherent implications are so far reaching, that I do not see NI adding this anytime soon. I think they could make it a little easier along the lines of what the CCT does already but going further is a sure way of creating a maintenance nightmare. And if anything is worse for a product idea than huge costs, it's the prospect of adding maintenance effort in the future rather than eliminating it.

Actually that remark was specifically targeted at accessing variant data directly from the C side, eg, allow to pass Variants to the LuaVIEW DLL and do the right thing in that DLL. The C interface to Variants, while it exists and gets used in some small manner by DAQmx and some other NI drivers, is undocumented so far. I think the Flattened Format of a Variant would look mostly similar to the Flattened format of other data in LabVIEW with the addition of Variant properties added in. I also believe that the LabVIEW documentation does even document that format to some extend, but it's been a while that I looked at that. In fact the OpenG LVData package implements that approach sort of. But flattening a Variant to pass it to LuaVIEW is while possible, very supoptimal and I don't like the idea to implement it in such a way.

Where did you try to put the DLL in the executable and what cpath did you use? It's been a while that I dealt with this issue for an application so I'm not sure about the details at this moment. I do remember something about that it didn't work properly without the compat-5.1 fix that was floating around at that time. And being busy to go through all the tests for the new beta package makes this also a bit harder. But I will look into it as soon as the beta is released. Could you maybe provide a small example project that shows the problem? That would certainly accelerate the issue a lot.

I mean that a LabVIEW Vision Development Module for mobile platforms never will exist. The targets are simply not suited enough for that and much to troublesome to even consider porting the very non trivial C++ code in the shared libraries of the VDM to it. NI hasn't even ported it back to MacOS, which is the platform where it originally was developed on, before they bought it from Graftek. Your best bet is to interface to whatever API is present in Windows Mobile to do what you need to do and failing that find a specific DLL library that works on that platform. Then create an according Windows stub DLL so you can deploy your VIs, although being able to test it on the host too may be a bit more trouble.

And I bet my hat that there never will be!

Hello to everybody being interested in LuaVIEW. I’m in the final stages of testing and finalizing a package for the Beta of LuaVIEW 2.0B1. This new release has a number of changes to the previous release but efforts have been made to keep it as compatible as possible to the last LuaVIEW release. Following characteristics are valid for this release: LabVIEW 7.1 or newer Uses Lua 5.1.5 as Lua engine (LuaVIEW 1.2 used Lua 5.0.3) The core library has been changed into a DLL/shared library Supports LabVIEW for Linux x86, Windows x86 and x64 Distributed as OpenG package, can be installed with the OpenG package installer or with VIPM This Beta is time limited and will stop working after the end of 2012. If no serious problems are found during the Beta test, the 2.0 release version is expected to be released around end of August. The release version will include runtime support for LabVIEW for Mac OS X and NI realtime systems (cRIO and Pharlap ETS). It will also include a binary module to access NI-VISA directly from within a Lua script for at least Windows. To receive a download link to the Beta package please send me a pm and specify which LabVIEW version and OS you plan to use with this Beta. Sincerely

You had me wondering for a moment there, as initially there was only a white image with some meaningless text about "no softlinks" or so! But I'm sure Hobbits would use LabVIEW if they had computers.

Switzerland uses polarised plugs and there is a convention that the live terminal should be connected to the right pole, if the middle earth pole is at the lower end. However it is specifically forbidden for a device to rely on this fact, so no connection of the left pole to any touchable metal part at all!! Basically the only thing you can say for sure is that three poled connectors have a known earth connection and any electrical conductive parts on a device that can get in contact with a human or animal should be connected to that earth. Oherwise you have only two poles and the device needs to be double isolated for safety. Such double isolated devices should have the according sign somewhere on it's casing, a rectangle inside another rectangle, symbolising the double isolation. The French and Belgium installations seem not to have any preference for which side to connect the live pin, despite the fact that the socket is actually polarised due to the unsymetrical earth pin. Basically for any appliance that can handle unpolarised connection, such as used in the German "Schuko" system, it should not matter at all, if the outlet is polarised or not. The opposite is obviously not true, but I would think that any appliance expecting polarized connection, would be a total pita to sell outside of a few very limited markets.

And in practice LabVIEW has already the seperation of runtime system and IDE, or otherwise remote target deployment and debugging both with RT and FPGA targets as well as from desktop LabVIEW to desktop LabVIEW would not be possible. But it's not the solution for allowing truely abortable CLNs. You would have to separate the actual CLN context in order to be able to recover from an aborted CLN and that would mean an isolation of parts of the runtime system inside the runtime system. A pain in the ass to do, and a total performance killer as you have already aluded to about string and array parameters that would trigger copies.

Well, yes they allow to call another function or more precisely three. One when the CLN is initialized, one when the VI containing the CLN is aborted and one when the CLN is unintialized. Each takes a context parameter that can also be added to the actual function call itself. So in the OnReserve function you create the context with whatever info your function might require, in the function call itself you setup some bookkeeping of some sort to be able to signal the thread to stop, and in the OnAbort you abort the thread, preferably not by killing the process but by correctly signalling whatever is waiting on some external event. OnUnreserve you deallocate and clean up whatever has accumulated during the OnReserve, OnAbort and function calls. Of course if your DLL is buggy and just hangs somewhere, this signaling won't help, but honestly once you are in there, nothing will really help safe from killing the process. LabVIEW can not even start to guess how to recover properly from such a situation since it has absolutely no control of the stack during the function call. Any attempt to resume after a forced abort is doomed to cause many nasty sideeffects, if it doesn't immediately go into pointer nirvana. And no a DLL interface doesn't specify a certain Exception handling interface at all, and Exception handling very much depends on the used compiler, since each tends to have it's own patent encumbered exception handling mechanisme. The OnAbort function is responsible to signal the waiting thread and make sure it cleanly exists back to the LabVIEW diagram with properly cleaned up stack and all.

Actually since about LabVIEW 8.2 they sort of are through the badly named Callback functions. LabVIEW 7 didn't have that but CINS had a CINAbort function that could do that, if properly implemented.

Yes! You can not change the buttons for a window once they are assigned, only hide them with the other method. It should have nothing to do with dumping the VIs out of memory, but closing the window (and therefore removing its taskbutton from the taskbar) which has the buttons assigned.

I was refering to a method to retrieve the case labels. That is where I came across this error at some point. It may be in 2011 though, didn't check recently.

Actually that doesn't have to be. It's a logical VI scripting method for case structures, yet it seems the need was never big enough in comparison to the implementation cost that anyone has really bothered to assign resources for this. So yes this may jog NI and it could result in either adding the implementation or fixing the availability of that method in the public VI interface, depending if the implementation is hampered by some difficult to tackle subtleties or not.

They use the MSI API which is basically the official low level API to the Microsoft Installer technology. It's a super complex system based on a relational database system to manage all the packages, versioning, dependencies and what else that a packaging management system needs to maintain. There are probably higher level MSI interfaces based on .Net and ActiveX but the core API is a pure DLL based interface in MSI.DLL but I doubt would be useful to try to interface with the Call Library Node directly. NI uses a DLL interface that was probably developed by the LabWindows CVI group to support creating installers from applications developed in it. I have read some time ago a comment by a former member of the MSI developer group, who admitted that choosing for a relational database system for this, was probably more than a little bit of overkill but that once that decision had been made there was really no way of going back and changing much anymore. The whole MSI technology used is therefore really Windows provided, and the application builder just uses a higher level API that allows the minimum amount of customization to this functionality that is required by the NI application builder. It could of course provide more flexibility but the cost of such a solution is simply enormous, the knowledge to use these options rather high, and therefore unlikely to be used by most. I believe that the OpenG Builder did interface to an undocumented VI to plug into the application builder part of the MSI component and LabVIEW 8.0 changed the entire Application Builder so that the OpenG Builder broke. However at the same time NI documented part of the application builder VI interface so that it was possible to access those methods outside of the project interface.

You are right that callback from Lua code to LabVIEW and vice versa is an integral part of LuaVIEW. However there is a limitation: You can't do that recursively at this time. This is due to the fact that call stack management across those borders is limited and can't be easily chained in a recursive matter, both because of very different parameter interfaces between LabVIEW and Lua, with LabVIEW not even having a classical call stack at all, but also because of complications in error unwinding when backing out of recursive call sequences. I have been looking into relaxing that limitations with a fully recursive call stack management, but the necessary effort is rather high in comparison to the benefits, and that feature also offers a very easy way to create overly complicated architectures that are bound to let a user shoot in its own feet. Variant integration would be great but unfortunately the C side of the LabVIEW variants are not only undocumented but have also varied between different LabVIEW versions.

What's the reason for using gzip instead of ZIP format? Knowing that would give us a better idea about your needs. As to the Python node, you can find that under LabPython. The OpenG Tools don't support the gzip format out of the box. While it wouldn't be impossible to support it, since both make use of zlib internally, it's quite a bit of work. But integrating gzip by using LabPython is really very roundabout. Have you looked at executing the gzip executable through System Exec?

Version difference, varying support by various browsers?

Not exactly like that. Web UI Builder is a project NI already has put up, and your posting is either more or less copying that or building on top of the NI Framework. I'm not sure. One of the biggest drawbacks of Web UI Builder is that it is based on Silverlight. While this is ok if you don't mind locking out more than 50% of potential computer and tablet users, it's a to big limitation in my eyes. I think that initiatives like WebSocket are more interesting in that respect, eventhough they have their problems too. Also I said Open Source, not crippleware.

I stand corrected. For some reasons I believed it would include 1 in the possible range, and wondered why as that made not to much sense at all.

A competitor doesn't need someone like this on board either. Such a person is just as likely to hack their tools, leave after some time in disgruntlement because of one or the other disagreement and put everything up on internet to show them who is the real king. Besides, this poking under the hood is not something their already hired developers couldn't do, especially when all the info is posted so nicely. It's also not something you need a particular CS degree for. Any inclined hack kiddie can do it, if he has access to LabVIEW. Last but not least, no competitor is really interested about the rusty nails in LabVIEW's attic, they rather would want the construction plans of the whole thing. Even if they had, they would need to be very careful, or they are faster out of business because of legal action than they can create a product from it to start cashing in. And if you can't cash in on something it is worthless for every economical thinking entity, which everyone wanting to stay in business has to be. Personally I would be impressed by someone showing that he can pull off an Open Source project. It doesn't have to be a LabVIEW clone

Mathematics is tricky. The round to zero is possible with the floor() operation but is not sufficient. Since Randomize() produces values between 0 and 1 with the ends inclusive, you still can end up with a few potential values outside the range every now and then. Also just as a trivia there are in fact two round() used in mathematics, one rounds 0.5 always up the other towards even numbers. The second is meant to reduce the effect of rounding errors in combined mathematic calculations with multiple roundings occuring.

Well my Dutch is worse . I'm from origin Swiss, with Swiss German, then had to learn French, of which I remember very little, then ventured into English and finally Dutch. So while I'm still fairly good in German, a bit less in English and Dutch, the mix of all these three hasn't helped the grammatical correctness of any of them.

How exact is exactly? If you talk about microseconds you better employ an RT system or some hardware timer. If seconds is enough a little (abortable) wait loop is all that you need.

Using a Method node set to operate on a VI reference and executing the FP.Close method, after everything else in the VI has finished?