Rolf Kalbermatter

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.

I see why you think that, yet this tends to be rather static data, unless you happen to startup and exit lots of service enabled NI and LabVIEW software applications. So not really that exciting to watch

Actually a better fix is to apply the correct logic in ZLIB Store File.vi itself, since in there is already code to detect if the entry is a file or directory. I will look into this as soon as I have finished setting up the essential tools on my new machine, since the old machine is kind of dieing, I rather don't want to use it for any work anymore.

Actually a correction to my earlier post. The VI library mentioned does not allow to see all the registered services but instead you can enter in your prefered WebBrowser: http://localhost:3580/dumpinfo?

You could look into service names. The TCP and UDP functions in recent LabVIEW versions allow to wire a string to the port input which can define a service name. For server functionality this registers the service name with the dynamically allocated port number at the NI Service Locater service for that machine. For client functionality it queries the Service Locater for the port number for the specified service name. I saw in the LabVIEW 2010 configuration yesterday that you can specify a service name to be registered for the current LabVIEW instance and I'm sure that can be put into the executable configuration too. Not sure however how that works in combination with multiple instances of the VBAI since they all would use the same configuration file to startup. Also there is a VI library in vi.lib/Utility/ServLocater.llb that allows to interact with the service locater programmatically. It allows to query the service locater for all currently registered services, so you may be able to see if starting up multiple VBAI instances does register any service name and what pattern the service name would follow.

Font is not equal to font. You have so called bitmap fonts and true type fonts. Bitmapped fonts can only be displayed in the sizes that the font file contains specific bitmaps for. Maybe that Windows 7 in the user interface supports resampling them nowadays, not really sure about that, but the result is always suboptimal, with artefacts such as blurry edges. However most printers still don't know how to resize bitmap fonts, and I would be surprised if the Report Generation Toolkit even attempts to support that. Courier New is a true type font and those are defined in vectorized form and can therefore much more easily be resized, and Windows supported resizing them basically from the start when they introduced that feature in a similar way than Apple had decided to do already earlier. True Type fonts are really developed in cooperation with Apple and Adobe, and Microsoft took them over with some help of Adobe, not without making some minor modifications to the meaning of some of the parameters in the font file, so that a one to one copy wasn't possible.

A well, .Net. Always a possibility but annoying to use. In my searchs I have found that LabVIEW 3.x and 4.x did export a C manager function that would have allowed to do that in a CIN and after 5.0 with a Call Library Node but alas, the LabVIEW Gods at that time decided that this was an unneccessary private API and they removed it.

I assume you would want to display a selection box with all the possible fonts listed. And I have to inform you that despite very deep searching in the depths of LabVIEW's basement and attic, I have not found a way to get this information during runtime into an application. My detective work has been carried out 2 or so years ago, so there is a small change that 2009 or 2010 have some hidden possibility for this, but I somehow doubt it.