Rolf Kalbermatter

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.

How should that work? An exe build on Windows expects to run on Windows (or maybe Wine) and an exe built on Linux expects to run on Linux. Linux doesn't know how to load and run the Windows PE format that the LabVIEW exe stub is in, and Windows doesn't know how to run the elf startup stub that is in the LabVIEW for Linux executable. Executable Files are always specific to the platform they are created in, and can't be moved to a different machine architecture, independant if the the CPU type is the same. In the case of LabVIEW VIs (not included in an executable but run for instance through VI Server) a similar limitation applies. VIs will only run in the runtime engine for which they were compiled and since the runtime engine doesn't have a compiler included this means you need to have loaded and saved them the last time on the same platform as you want to run them in a runtime engine.

Are you really sure there will be always at least one object? Why not coarse the index to the lower and upper end instead of always setting them to 0 when out of bound? If obj/varCount is 0 you still will index the first element later on!!!!! Are you sure slaveInfo_->group is never a NULL pointer? And if that is the case, are you sure it points to a buffer long enough, that can be overwritten with your string? And the overwriting as well as the commented out code have another potential problem. Since the slaveinfo structure seems to be returned by the function and probably isn't allocated as you otherwise would need to deallocate it at the end, it is likely static memory or at least a static global pointer and messing around with its contents could then have fatal consequences for the driver implementation in the DLL. You don't need the + 1 since LabVIEW string handles don't need to be zero terminated and shouldn't contain a possible zero termination char in their length count. Many potential trouble and I'm sure there could be more as I do not know the entire API. The API structure is a very nasty implementation and IMHO worthless. This is fine for internal function parameters but not for an API that can be accessed by other units.

Copying kernel drivers to the system directory will do nothing for your target system. You also need to register such drivers at the Service Manager, in order for them to be loadable by Windows. And most likely you will also need to add additional registry values, for the Plug and Play system to associate your driver with a particular hardware resource.

In that case you are leaking that memory with every call???? A few more notes: You are indexing into the object and variable tables with passed in parameters without verifying that those indices are valid in the constraints of the provided data.

First I didn't even catch that you were not even allocating memory for the slaveInfo, etc. local variables. That is quite an error to do for a C programmer! It should have been the first thing to check before you even post! But I was really referring to the embedded string handles in the structures you pass from LabVIEW. Unless you go to the length to explicitly fill those elements with actual initialized arrays of sufficient length in the diagram, those string handles will be empty handles when arriving in your function, and an empty array in LabVIEW is simply a NULL handle for performance reasons. No use to allocate a handle (two pointers) that can only hold the 0 integer to indicate that no data follows. LabVIEW Handles are NOT simple memory pointers. They are really pointers to pointers to memory blocks AND need to be allocated and destroyed with LabVIEW memory manager function calls, as described in the External Code Reference Manual, since LabVIEW will use the same functions to handle those handles. If you just plainly go and use malloc(), you confuse the memory manager in very serious ways that will sooner than later result in unrecoverable errors. Look into NumericArrayResize(), which is the recommended way, or the low level functions DSNewHandle(), DSSetHandleSize(), etc. Instead of: size = strlen(slaveInfo_->group);memcpy(LStrBuf(*pSlaveInfo->group), slaveInfo_->group, size);LStrLen(*pSlaveInfo->group) = size; you will want to do something like: size = strlen(slaveInfo_->group);err = NumericArrayResize(uB, 1, (UHandle*)&pSlaveInfo->group, size);if (!err){ memcpy(LStrBuf(*pSlaveInfo->group), slaveInfo_->group, size); LStrLen(*pSlaveInfo->group) = size;} And a nitpick really but it's not a CIN. As far as I know the newest LabVIEW platform versions (64 bit Windows for instance) doesn't even support creating CINs. Instead you create a shared library (DLL) and import it using the Call Library Node (CLN) on all platforms.

What makes you think these handles have been allocated so you can simply access their data pointer to write data into?????

That is not control panel related. You will want to look for Twain control from within LabVIEW. There exist libraries, some commercial and I think at least one non-commercial to do that, but be warned: Twain is a recommended standard to the letter, meaning recommended is all there is. Every scanner supports whatever it feels like from that standard, and that is usually very little. It's sometimes a vabanque game how to get a scanner to work through Twain, yet any other way of accessing scanners (for instance DirectX) is usually even more problematic.

The internal MatchPattern function is regex similar but by far not as extensive. I haven't timed the MatchPattern with a normal PCRE call yet. Personally I think MatchPattern, while being a nice function, most likely isn't as optimized as PCRE but doing less and therefore being simpler it still likely does it's thing faster than PCRE. Since the MatchPattern function exists in LabVIEW since at least version 3 or 4, and since it would be way to tricky to develop a wrapper around PCRE to behave EXACTLY as the old Match Pattern function, I'm very sure it is still the old function. On the other hand I just recently run into a problem, where behaviour of Match Pattern was changed. First they changed the documentation in 8.2 and then they changed the functionality to match the documentation in 8.5!! It struck me as very sneaky.

What would be wrong with using Boolean logic (NOT, AND, OR) and ROTATE instead? There you have full control of signedness of numbers and that worked as far back as LabVIEW 2.x.And it's most likely magnitudes faster, since it can be all done inplace, translates typically directly into one or two assembly codes, and doesn't use variable size arrays at all.

Sorry, this method doesn't really exist as far as I know. The archive directory is embedded in the actual file stream and modifying it without modifying the entire file structure seems not very easy. The structure does allow adding new entries to the archive without complete rewrite of the archive, but deleting and modifying is another beast. I may have missed something but as far as I know using the same aproach as the ZLIB Delete File function is really the best there is.