Rolf Kalbermatter

All the types ending in numbers are LabVIEW platform independent types defined based on precompiler macros in extcode.h or actually more exactly fundtypes.h included in extcode.h. Aside from the already mentioned short and long types and the signed and unsigned type specifiers he is also missing char. Also the int is not as the list would indicate equivalent to an int16 but really an int32 in any version of LabVIEW. int == int16 was only true on 16 bit compilers. Other variants that do exist are long long (except Windows which uses an internal type _int64) which is int64 and long double which corresponds to extended floating point format on platforms that support it (again with exception of Windows which has no compiler built in type for extended flaoting point). Basically; char == int8 (or sometimes uInt8 if the compiler treats char as unsigned byte, sometimes also possible to change by a compiler switch). short == int16 int or long == int32 long long (on Visual C: _int64) == int64 single == float32 double == float64 Basically parsing C types is quite a complicated business since various compilers do not understand exactly the same for certain types. So LabVIEW header files (and many others) have various definitions based on precompiler definitions that are defined by a compiler directly or through project settings and other included header files. So your parser should be able to define built-in defines to simulate a certain compiler to be able to process C header files. And since C headers usually include other C headers, it needs to handle embedded includes too. Of course if the idea is only to allow a C like definition of types rather than processing existing header files then the task gets a lot easier and you can define whatever subset of the C syntax you are comfortable with to implement.

My experience with logging lots of events is that it is almost impossible to find the interesting needle in the haystack. Logging events and especially errors should be normally the exception, not the rule, otherwise you can just as well throw them away anyway, since nobody is ever going to try to look at the log.

While I understand the reentrant advantage I'm not sure that is such a big deal here. I use a similar error/event logger scheme as yours (from like written 12 years ago or so) (and yes I wanted to redesign it a few times since but it just sits there and works so the need never really pressed itself upon me). In general if you happen to have an application that produces errors so fast that the non-reentrancy of the AE starts to be an issue, of course assuming that you did decouple the actual action properly, then I feel one has a much bigger problem to solve than the possible blocking of other threads by the still busy AE from earlier errors. That said I use the same silly AE based event/error logging system on all my systems including RT apps.

I see no connection between your first post and what you reference here And while LabVIEW PDA supports Mobile and Windows Mobile is the successor to Windows CE, I indeed doubt that LabVIEW PDA goes as far as supporting CE releases. And your original problem of not being able to install a new Windows CE release onto your smart phone points much more basic problems than being able to run LabVIEW applications on it. Sorry.

Wouldn't count on that. In the begin days of the password protection they did that sometimes but after some time they cleanly discontinued that service for all and everyone, because it was unmanageable, unmaintainable, legally very questionable (how to proof that you are the one owning the copyright to it, etc). and simply a to big support burden. Would be surprised if they came back from that decision since. Of course if you do know someone at NI and know their weak spot the above may not apply.

How big is your number then? As you can see 66 years (1970 - 1904) corresponds roughly to 2*10^9 seconds. From your 300 year difference I would guess you are not getting the number of seconds but rather something else such as the number of ms, since that ominous 1970 date.

Windows? There are probably several options: .Net, ActiveX, Windows API and command line tool Personally I would go for the comamnd line tool or Windows API aproach, but the command line tool is the easier to explain. To start a command line tool you use the System Exec VI in LabVIEW and pass it a string "cmd <command>" The command line tool you want to use for this would be "netsh" netsh interface ip set address "Local Area Connection" static 192.168.0.1 255.255.255.0 This would set the IP address of the network adapter "Local Area Connection" to static IP 192.168.0.1 with a subnet mask of 255..255.255.0 netsh has many more options and has an involved command menu structure, but you can find lots of information on the net how to use it.

There are different solutions but all have the disadvantage that making them work on non desktop systems might be a lot of hassle or simply impossible. 1) Use of stunnel or a similar SSL proxy. This sits in between your application and the actual SSL enabled service. You communicate to the stunnel process/service through unencrypted protocols (so your stunnel proxy should be installed on the internal network) such as HTTP or POP/SMTP and stunnel converts that protocol to its corresponding SSL enabled protocol and vice versa. If you have the ability to install stunnel on an internal desktop PC you do not even have to try to get stunnel to work on your RT system, which I assume would be a serious problem although being open source I'm sure it could be made to compile and run there (but it uses OpenSSL and that can be very tricky to port to unsupported platforms). I've done tests with stunnel under Windows and got a simple LabVIEW HTTP VI to communicate properly to an HTTPS server by using the stunnel process as HTTP proxy with SSL encryption. I'm not sure if this is indicative to HTTPS support in general as I didn't test many HTTPS services with this. 2) Using the OpenG Pipe library you could call a tool like plink or putty and redirect its IO streams to LabVIEW, letting it perform the actual SSL encryption and handshaking. This pipe library works fairly well but has some quirks sometimes under some situation that I haven't found the time and interest to debug yet and unless I'm going to need this library in a commercial project where these quirks are an issue it's not likely that I will spend much more time on it. The current state is that it mostly works on Windows, has been prepared to work on Linux and Mac OSX but without being tested yet, and would be a challenge to port to RT systems. 3) I've been working on a Network nodes (TCP/UDP) replacement library that includes TLS/SSL support through use of the OpenSSL library. It is still Windows only and has a few problems that prevent me from making it available for broader consumption. Also it is fairly substantial work so I'm not sure about how to make it available at all. A free open source distribution sounds a bit to much like giving it away. The idea of that library would be that it basically simply replaces the native LabVIEW network nodes as drop in replacement, providing an additional parameter to initialize the SSL operation if so desired. Additional goodies would be optional IPv6 support if available on the platform and some extra functionality such as optional synchronous write operation. The current state is that it mostly works but it hangs always when trying to shutdown LabVIEW after having done one or more SSL related communication because the OpenSSL library seems to somehow hook into system calls that make loading/unloading it dynamically a big challenge. Porting this library to Linux and Mac OSX should be fairly straight forward, and porting it to RT targets albeit probably not as trivial, should be also possible.

Sounds like your .Net assemblies are somehow messing badly with some system internals. I know this behaviour form standard DLLs who try to hook themselves into system calls to do some black magic. When trying to unload those DLLs with the FreeLibrary() function, Windows gets confused in some sort of deadlock situation. Seems Microsoft specifically discourages explicit unloading of DLLs on application termination, saying that this can cause dead lock situations for many API calls during such an unload call. Not sure if this applies in your case but the way you describe it it sounds somehow similar. Problem here is that you can not tell LabVIEW not to attempt to unload a .Net assembly when it wants to close down the VI that contains the last .Net Node to that assembly.

Flash memory doesn't seem to have a serial number that Windows wants to provide. For USB HDs it seems also not possible to get the serial number in any way. And for SATA devices at least in my XP system there won't be any serial number either, unless I directly query the drive using ATAPI SMART but that requires admin privileges. Do you mean to say that HD Tune can give you HD serial numbers without being logged in as administrator? That would be very interesting.

I would guess that this is more important than the fact that it is Windows 7. Apparently someone put some love into the File IO C code and removed a global somewhere in the Open File function that prevented that function from being called as a thread-agnostic function, so the File dialog, which has to run in the UI thread since it does UI , can't block it anymore.

Actually if memory serves me right this is not the first time for The Captain to appear in the newsletter or the website. So not so sure it has much to do with the fact that he works for NI now. He's simply good in marketing, including his own ideas.

Congratulation Chris! It can be sometimes tough but in the end it is one of the greatest experiences one can have. Good luck to the baby, mom and you.

Trial and error, what you can throw away! It very much depends on your application so there is no right for all list. If this is to cumbersome then let it be and use installers! Also watch out when testing such setups. Most of these components are optional and LabVIEW does make a lot of effort to run without those optional methods. This means that you can start up your application fine with most of them missing, until you do exercise one of those components. For instance not having mesa.dll or some of the models files in the modesl directory will not cause your application not to startup. But as soon as you show a window using one of those elements you will see a crossed rectangle instead of the control. This is the same with many other things. Until exercised you won't notice anything. So make sure to exercise all code paths in your application when testing if it still works with runtime files removed, to avoid bad experiences for your users. As a guide-line you can go with this: - all *rsc files should be always added, also the lvrt.dll file - lvjpeg.dll is only needed if you use any jpeg functions in your app, same for lvpng.dll for png files. - serpdrv doesn't apply for LabVIEW 7 and higher anymore - mesa.dll and the models directory are only required if you use the new style (3D) controls - scripts directory is only needed if you are using one of the script nodes, but they got mostly obsoleted by Mathscript in newer versions The advanced analysis library requires from LabVIEw 7.1 on for most functions the Intel Math Kernel Library to be installed. And it will look for that library in the system registry so you basically can't avoid an installer for that. LabVIEW 8.x adds many new features such as Mathscript that are separate components and need to be installed in order to work properly and allowing LabVIEW to find them, Once you do things like LabVIEW RT targets, FPGA, DAQ(mx), VISA etc, you can simply forget to get these things on your machine without installer.

image.ctl is the IMAQ Vision Image Control. And that does not have a scale at all, since that is not how images are typically used. Calibrating an image to be exact in physical measurements is a very difficult task in itself. Especially since such a scale has only any meaning for a very specific depth plane in the picture. Anything a little further away or closer by has a different scale.

Unfortunately that is a functionality of the Windows shell File Dialog. On a successful file selection it seems to set the current directory for the app to the directory that selection was made in. Why in the world the MS programmers thought this to be a good idea, I do not know at all. There seems no way for an application to tell the dialog not to do that. The only LabVIEW workaround would be to keep resetting the current directory to the previous value after each dialog! possibly breaking something that was the cause for MS to add that functionality.

I agree but I was not aware that the FTP VIs would use that range. After all they are from NI and I would hope they do not clash there. ( I know they clash elsewhere!) But since the VIs are in source code and without passwords, the best person to really go after that problem is the OP himself. A bit of single stepping and debugging will surely show the offending operation.

Might the problem be maybe more on the sender side? I ask this because 200ms sounds a lot like the default TCP/IP Naggle algorithmus delay. But that is applied to the sender side to avoid sending lots and lots of small TCP/IP frames over the network. So reading 4 bytes and then the data might be no problem at all but trying to do the same on the sender side might be. It's also my experience that on the reading side you can usually chuck up a package in as many reads as you want (of course performance might get smaller if you do a seperate TCP/IP read for every byte, but that is besides the point). On the other hand it is usually a good idea to combine as many data as possible in one string and send it with a single TCP Write. That is at least how I usually do TCP/IP communication. Another option I have at times used is to enable the TCP_NODELAY socket option, but I have to admit I never did that on an embedded controller so far. Not even sure how to do that on a VxWorks controller as its API is not really standard.

You are right, but 1xxx errors are of the LabVIEW environment type errors (think VI Server, scripting etc.) so I really wonder how that could get into FTP VIs where simple File IO is handled. I haven't looked at the FTP Vis in ages as I use my own library but maybe they use VI Server for some reentrant calls or something in there??? With FTP this could mean that the login was not successful.

I've seen it too many times but it seems to be mainly limited to using the Browse dialog. Normal LabVIEW File I/O primitives usually don't seem to cause that problem. That made me believe that it is something the Browse Dialog is causing and this dialog is largely part of the OS itself. Maybe it's the way LabVIEW is using that dialog. An interesting experiment I wanted to do in ages is to use the LabVIEW file dialog instead and see if the problem persists. Problem is that I have not found a reliable way to reproduce that problem.

Ohh, ohh, you got that mixed up very much mate . LabVIEW 1 was Mac only and so was LabVIEW 2. It did not look like LabWindows at all but like Macintosh. LabWindows was for DOS and its programming was in Basic and a subset of C and the graphical UI was far from what a Macintosh could do although much better than most of what could be done on DOS otherwise. The first LabVIEW version for Windows was 2.5 but it was really a preview release and more like a glorified Alpha. It's stability was ... well, nothing to write home about, but then it was also Windows 3.1 and LabVIEW was probably one of the few applications out there exercising the Windows 3.1 kernel to the limits of what MS never had imagined. The first official LabVIEW version for Windows was 3.0 followed by numerous bug fix releases and with 3.1, if memory serves right, adding SunOS support, which many years later was renamed Solaris 1 by Sun. Somewhere around 3.1 the Macintosh version was also getting back in sync with the multiplatform release, having been sold until then as 2.2.1 version in its old non-multiplattform version, with its Mac only resource format files. The UI has had quite a few changes IMO, with new objects being added regularly. Yes the basic concept hasn't much changed and I wished they had overhauled things like the custom control editor to allow a much better customization of controls. The current editor is from the beginnings of LabVIEW and simply not very intuitive in many ways. Also some of the newer controls seem not to have gotten the internal object message support to be customizable at all in that editor. If I knew this is because they support internally a different object message interface for a yet to come new custom control editor then I could more easily live with that, but I have my doubts.

No I think integrating LabVIEW modules as DLL into a LabVIEW application is a fairly roundabout way of doing business. It is possible and even works most of the times, but there are gotchas. 1) The DLL interface really limits the types of parameters you can pass to the module and retrieve back. 2) There is a LabVIEW => C => LabVIEW parameter translation for all non-flat parameters (array and strings) unless you use LabVIEW native datatypes (handles) AND the DLL is in the same version as the caller => Slowing down the call. 3) When the versions don't match there is also a proxy marshalling of all data paramaters necessary, much like what ActiveX does for out of process servers (but it is not the same marshalling mechanism as in ActiveX) since the DLL and the caller really execute in two different processes => Slowing down the call. 4) The DLL can not for the sake of it communicate through other means with the caller but through its parameter interfaces or platform system resources (events, etc). The notifiers, LabVIEW events, semaphores, etc. are (maybe shared and meaningful in the case of same DLL and caller version) but certainly completely useless if the DLL is in a different LabVIEW version than the caller. There are probably a few more gotchas that I haven't thought of at the moment.

You should also give more informations as to the error number and text you receive and also a bit more background in terms of LabVIEW version etc. Also post the test VI you have been executing when you get your errors. Your description of what you are doing is rather compressed and not very clear.

Or they are simply to smart. You know the pink monkey experiment, don't you! Belongng to a 2% minority is like being a pink monkey especially in a society where everybody is on animal level.

Actually that is not true either. Generally, compiled VIs in a x.x.1 version can be loaded into x.x.0 runtime and vice-versa and executed. It could in some corner cases give strange (visual) effects or calculation artefacts but in general it works. But before LabVIEW 8.5 if you loaded a VI that was not EXACTLY the same version into the development system, it always got recompiled automatically. That is true if you try to load the VI through VI server. It is not true if you compile those VIs into a DLL and call that DLL through the Call Library Node. If the LabVIEW version the DLL is created with does match the caller version, the VIs in that DLL are loaded into the current LabVIEW system and executed there. If the versions do not match (not sure about the bug fix version difference here), the DLL is loaded through the according runtime system and run in that way.