Rolf Kalbermatter

NI often seems to be a bit conservative in their estimated shipping dates. I remember my last cDAQ project where I needed 4 cDAQ-9181 and some modules. The cDAQ-9181 were quoted with 10 days delivery time on the website, when I ordered I got a call that they had production problems with getting some necessary parts for a production run and they estimated a shipping time of about 2 months later. You can understand my surprise when I got the product about 2 weeks later and it fully worked! It's all doable if you have access to the host itself. There is a Real-Time Deployment Library that allows to build in code into the host application, that can update, reset and restart a realtime controller from the host application at runtime. No need to have access to the cRIO over internet or to a LabVIEW development system on the host for upgrading the realtime part.

MSDN only says that some functions might do that, not that it is how it should be done. Officially it is an error to do that, yet Microsoft tries often to accommodate even misbehaving applications for compatibility sake. In this case it is of course always safer to call GetLastError() immediately after a function indicated an error (and that function contract says it returns an error status in GetLastError()). Assuming however that GetLastError() returning non-null means the previous API did go wrong is ALWAYS wrong, since most APIs behave like MS meant it to be and do not overwrite the GetLastError() error status when they succeed. Also you have to take LabVIEW into account here. A typical Windows API call is done from a C program and the C programmer controls thread execution completely and knows exactly what was called between any API call and the possible GetLastError() call. First if he doesn't explicitly pass control between the API call and the GetLastError() call to a different thread, (and which C programmer would do such a stupidity, since it is a lot of work and sweat to do multi-threading programming, so it doesn't happen accidentally?), he is sure that both calls are executed in the same thread. And he is exactly sure what other functions he may have called in between in that thread. In LabVIEW the only way to have a similar sure way of knowing is to use subroutines. If two CLNs are set to execute in the UI, they will execute in the same thread but have to share that thread with a lot of other things in LabVIEW, especially UI execution. So there could be 200 other API calls in between done by LabVIEW, that all might have altered GetLastError(). If the CLNs are set to execute in any thread, they can and often will execute in different threads, so GetLastError() won't necessarily see the error code that the API possible has set, since Windows goes through a lot of trouble to make the GetLastError() value only thread global and not process global. In fact in Windows every thread has its own GetLastError() variable. The only way to guarantee that GetLastError() will see the error set by the previous API is to use subroutine, since LabVIEW guarantees, that the entire subroutine call will execute in the same thread and without any other interruption than what the OS might do to preempt a thread for its proper multi-threading operation. Another point is of course that it's a rather brain dead idea to have an API that returns a boolean status to indicate one should call GetLastError() to get more information about the error, since GetLastError() also only returns a DWORD value which would just as well fit into the BOOL returned by the API. It made maybe a little sense in Win 3.1 where BOOL and DWORD were not the same size, but it could have been depreciated for any API that was introduced in Win95 or later. In fact the underlaying NT Kernel all returns HRESULT values, and the kernel32 and user32 API convert them to GetLastError(), since kernel32 and user32 are only really thin wrappers around ntdll.dll and similar other kernel APIs since Windows NT 4.

Have you considered to use the cDAQ-9188 instead? True it's about double the price of the cDAQ-9174 but it is shipping. and I would expect the cDAQ-9184 to be about halfway in between these. The cRIO-9075 would be a little cheaper but you don't use DAQmx to access it, but instead place a realtime control programm on its integrated controller and transfer the data from there.

One or two nitpicks. GetLastError() queries a thread global variable in kernel32.dll and therefore can and usually only does return the right answer if called in the same thread than the function that caused the error. This might seem like being guaranteed by running the actual function call and GetLastError() in the UI thread, BUT unfortunately that doesn't work like that. LabVIEW is free to schedule other UI calls between the two CLNs such as drawing something in the front panel and many of those functions can also set the last error so the actual error caused by the first CLN might be already overwritten, when this VI tries to read it. The solution is to make the VI subroutine priority, which will tell LabVIEW to execute the entire VI in the same thread without scheduling anything in between but that also requires to make the CLNs run in any thread, as subroutine VIs can not contain code that can run asynchronously such as CLNs set to run in the UI thread. Also GetErrorStatus needs to be changed to subroutine as well as a subroutine can only contain subroutine VIs. Last but not least, GlobalMemoryStatusEx() returns a status of FALSE (0) on error and TRUE (<>0) on success. The GetLastError() and CO should only be executed when GlobalMemoryStatusEx() indicated a failure as Windows functions are not supposed to change the last error value on success at all, and you might retrieve a last error value from a previous API call somewhere in LabVIEW. Get Win32 Error Message.vi GlobalMemoryStatusEx.vi

I think it is intended by precedence. In fact I'm totally surprised that List Directory does also filter directories based on the pattern. So what do you get if you want to list *.txt files? No directories at all? I had thought that in older versions of LabVIEW you got all the directories anyhow, but at least back to 7.0 the List Directory already filtered directories as well. But looking at the List Directory Recursive I see that the Directory enumeration is done seperately without any pattern to indeed get around the "limitiation" of the LabVIEW native List Folder node, so it is clearly an intentional decision. I guess you could add an optional boolean that is set to false and in the true case just use the "directory names" output of the first Get Files by pattern function, skipping the "Get dirs" function. But changing the default is not really an option since it could and likely would break quite a few OpenG Tools such as the OpenG Package Builder, Commander and its decendent, the VIPM.

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.