Rolf Kalbermatter

I have played a little with the vxWorks toolchain. The reason that the // comments are not accepted is that the example vxWorks makefiles that I used as a template for my lvzip makefile do specify the -ansi switch to the C compiler. This reverts to C90 and disables C99 features such as // comments and inline keyword explicitly. Removing that allows compilation without problems but I'm not sure if the resulting shared library is still fully operational for the LabVIEW realtime target as it also has a few effects in terms of compiler builtin symbols that are enabled and are in C90 replaced with library symbols that the compiler will link the resulting object files to. This library shouldn't use any of those symbols but not sure if there are side effects.

Have you tried playing with the mode input from TCP Read? Do you use message termination scheme with CR LF or something else? Basically LabVIEW defaults to a semi buffered mode but most simple socket programming without any poll() operation resembles more the immediate mode of LabVIEW. A mismatch in this mode with what a C program expects is usually the most likely reason for the behavior you see. The C Read with LabVIEW Write most likely will simply work if above is the culprit.

Most likely it's location is stored in a key in the registry in a National Instrument specific subtree.

Well the actual code that adds appending support to an archive was incorporated around 2006 or so, so it should definitely have been in the .out library you had first used. There were other changes to the c source including the change to zlib 1.2.5 but not really between the two dates you show. But it is good to know that it the current source seems to work fine now. I will try to go through all targets and build a new shared library file for them in the next few weeks. This would be by now: Windows x86, Windows x64, Mac OS X x86, Mac OS X PPC, vxWorks 6.1, vxWorks 6.3, Linux 32 bit. A serious series of toolchains that one can't install on one computer or even two or three alone. And Mac OS X x64 is probably coming too, as the newest OS X doesn't seem to allow to startup in 32 bit mode anymore. I'll check about the comments. If they are not in the zlib files I'm going to change them, otherwise I'm not sure what is the right solution at the moment.

Well I had submitted a few zlib related fixes lately that haven''t made it yet into the official upstreams zlib library, so those changes could be the reason that it now works. I didn't expect those changes to have such an influence though, as it was really about troubles when compiling as 64bit code. But I'm baffled about the need to change comments! I have compiled this library with the same toolchain and no modifications to the source code without any compile errors about comments. And I would rather leave the comment style as it is, since most of the files are just taken from the zlib project and changing them each time the zlib project has modified files is simply to painful. Can you give some information as to what errors you got from the // comments One guess I have might be that the updated_gcc toolchain that is now on the NI page incorporates a new gnu version that stumbles over the // comments when compiling .c files, as // comments were originally only a C++ feature. But that would be a rather awkward change, since most C compilers nowadays accept both comment styles anyways and it seems also part of the official C99 standard, which is for standard C compilers. So not sure why GNU would revert a feature that is officially declared in the C99 standard.

I'm afraid so but don't have a quick idea what the problem would be. Debugging on VxWorks is also a pain, since I don't have the integrated VxWorks development environment available (which costs $ and I can't justify this as the whole library and especially the VxWorks port is simply voluntary work).

The first parameter needs to be SHCNE_ASSOCCHANGED = 0x08000000 and the second SHCNF_IDLIST = 0x0000. The first parameter is a bitmask where the set bit defines the type of event and with no bit set, you simply invoke this function to post no event at all.

Of course there is! Use a recent LabVIEW version and of course don't use functions that are synchronized through the UI thread. That includes all VIs itself set to run in the UI thread but also just about every LabVIEW VI server function including Property Nodes and Methods.And everything else that will put up a UI screen such as a dialog or similar.

Is the framework you remember maybe RT System Replication? If so this is not for the application on the RT system to replace itself, but to push down an update from a host application to the (running) RT system. And honestly I don't think you want to have an RT system poll some remote location and attempt to replace itself with a new version. Imagine the system crashing somehow because the new version is not operational. And that system being at the other end of the world. You do want someone to take responsibility when the running app is replaced and be ready to take action if things go wrong.

But if there is no diagram it wouldn't run in a different version than the one it was created in, would it? I remember some dialogs in the past when trying to open a diagramless VI in a different version.

When you leave the address input open to Open Application Reference, LabVIEW does make a short-cut connecting directly to itself rather than routing everything through TCP/IP. So it's a bit different than the TCP/IP nodes.

Well, it's obviously the .Net DLL that is doing something wrong. So the first question to me would be, how was this DLL even tested? I would recommend to try to test it for instance with a Visual Basic test program, unless the programmer is willing and able to use LabVIEW himself. It could be a lot of things, from obvious programming errors in the C# code, to setup errors for the type library that LabVIEW then uses to generate the correct interface stubs, to simple setup errors such as the need to first call some other methods in the library to configure certain things, such as the FT communication port to use, before you can run the test method. So the .Net exception could be a bug in the C# such as referencing invalid objects, but it could just as well be an exception thrown by the code on purpose since it can't perform anything without the proper setup information.

Naw! They don't seem to read the internal HW serial number of the drive. What they seem to do is preparing some 2MB of data space on the flash Drive with some specific data that is read back by a specially prepared DLL that will return this data after some encryption/decryption. Supposedly they do something to prevent the simple cloning of the flash drive by ghost or similar software. How they do that is not clear and I doubt they will tell you. However it does not seem to read any serial number of the flash drive itself.

In general, it's hopeless unless you have a specific USB drive for which you know a proprietary access method to retrieve its chip serial number.

A combination of the File Dialog and the Create Folder function.

Well usually you don't create backup files in the same directory anymore, just for the reason you mention of not having the according rights to the directory anymore. Instead you copy it to the temp directory, update the old file and if anything fails, attempt to move the backup back or on success delete the backup file.

This is also part of the online manual that gets installed with your LabVIEW software. Read the last paragraph to find some samples that are also installed with your LabVIEW installation! It took about 10 seconds to go to www.ni.com and type in "LabVIEW ActiveX Server" in the search box and it was one of the first links on the list.

Don't know about NTX but just because it is similar or maybe even based on Pharlap ETS it is not very likely' that the LabVIEW RT will be able to work on that. Windows CE is a small footprint variant of an OS with an API similar to Windows 32Bit. As such it is meant for resource challenged systems such as embedded controller, Pocket PC devices, and Mobile Phone devices (the latest not anymore as Windows Phone 7 is supposedly a rather different system). Windows CE targets typically RISC CPUs though it may be available nowadays for x86. But it has no provisions to support true realtime operation so you can't call it a realtime system. It's strength is that it can run on embedded hardware, and on source code level its fairly compatible with Windows 32 bit, but its target architecture was completely different so you couldn't move (and even if they might have x86 support nowadays which I don't know) binary modules from Windows to Windows CE, since the file format and CPU target were different.

The NI realtime OS on non embedded systems (cRIO, cFP) is Pharlap ETS as already mentioned. This is a Win32 API compatible system with the same PE executable file format. The catch is that it does not support recent Win32 API additions after WinXP and also does not implement the entire Win32 API (partly because it's not useful or possible on an RT system) partly because the Windows functionality is not documented. Also the runtime library support installed on the system is about Visual Studio 7.1 with an option to install VS 8.0 runtime support if I remember correctly. This usually means that using newer Visual Studio versions will pull in runtime library stubs and functions that are not available on the Pharlap ETS system. So if you have already compiled everything into DLLs, AND have that running from normal LabVIEW for Windows, AND you can compile your DLL in Visual Studio 7.1 then you are mostly done. You'll only have to check for compatibility with the DLL checker and possibly modify code to use older Win32 APIs where necessary and you are ready to debug your system in your realtime environment. The same DLL that works on your Windows system will then work on the realtime system too. And Windows CE isn't a realtime system at all, and you'll have a lot of problems to get NI DAQ hardware working in that.

I'm pretty sure the WIKI refers to this thread. LAVA got an overhaul after a big crash and lots of links were lost then and had to be recreated. Maybe you can change the WIKI accordingly.

It's really the same. The toolkit is just an extended version that includes support for various MS Office applications. And the LVOOP is mostly an adaption of the existing code, not a rewrite from ground up. LVOOP makes it possible to install easily the extended Toolkit without replacing any of the basic VIs already in place. This can be also achieved without LVOOP, but not as elegantly, and it wasn't done in the old version as I found out when looking into creating a PDF export possibility.

The Report Generation Toolkit was written way back when those VI Server methods didn't exist. And it apparently hasn't been updated. Also note that it may not have been possible to update it for a long time, because of the oldest LabVIEW version it was supposed to support when being installed.

The problem is this: IE puts the path to the local cached image onto the clipboard, while all other browsers put the original URL onto the clipboard. So for IE LabVIEW can simply grab the image and decode it, as for all others it would first need to download it to its own local temp location. No biggy you might say and in theory this is right since LabVIEW contains all the necessary routines already in its C code to access HTTP (and likely FTP data) BUT there is the concern of additional delay to download the snippet and possibility that the connection might have gone/flaky/interrupted etc. which makes the dropping of a remotely located resources not such a desirable operation. Of course we are 3 years further and computers that are not constantly connected to the internet are almost an archaic reality from the past, right? Nevertheless it's not so simply. And browsers frequently change the other formats they put on the clipboard. Firefox as good as it may be in many aspects, changes the clipboard formats quite frequently and occasionally breaks them in the process too.

It's possible but not without writing a DLL/shared library for every platform you want to support. For Windows straighforward, for MacOS X quite a bit of digging in the Carbon framework and for Linux a bit of a pain to do, since it can vary depending on kernel version, distribution and packaging. And not to forget, that it doesn't invoke a .NET monster framework to get at some low level system information that is accessed through several other layers by the .Net library.

A LabVIEW timestamp is a 128 bit fixed point number. The first 64 bits are a signed 64 bit value indicating the seconds since Jan 1, 1904 GMT, while the second 64 bit are the fractional seconds. So it's possible to treat the timestamp as raw data but VERY error prone since it is easy to make errors with signed/unsigned integer and 64 bit integer arithmentic math, and getting the time difference between your epoch and the LabVIEW epoch wrong.