Rolf Kalbermatter

I haven't played with the watchdogs on cFP and don't have one handy to play with but I'm afraid there is only one wtachdog hardware resource on the cFP. Either trying to open more than one will not work at all or if it does it may reset the watchdog on every access which means you would only fail if ALL your loops stop. A better aproach may be to wire up a small LV2 style global that allows your loops to open a reference to some internal state (an array index might work). On every reset store the actual timestamp in the apropriate index and evaluate all timestamps to have not elapsed more than your set value. The whole thing might be a little bit involved in logic to make sure to reset the actual watchdog apropriately but it could definitely be made to work. Rolf Kalbermatter

In principle LabVIEW should only use XWindow and therefore should be independant of the Window manager and Desktop environment used so should run on any system that has an XWindow server. There have been however some trouble in the past letting LabVIEW run on dummy XWindow servers that only provide some sort of text output (to save resources for applications that could run as headless systems) and I'm not sure there has been any work done to improve on that. Rolf Kalbermatter

Inlined means that a C compiler will simply reserve the necessary amount of bytes for any fixed size data element in the structure itself. An example struct { int val1; int array[]; } will represent a structure with 8 bytes length first the val1 integer and then a 32 bit pointer struct { int val1; int array[100]; } will represent a structure with 404 bytes length, again the val1 integer and the 100 array elements directly following. Similarily an array int arr[10][10] inside a structure will represent a memory area of 400 bytes (10 * 10 * 4 bytes) directly in the structure. In LabVIEW you would create a cluster of 100 integer elements for this. An array int arr[][] would really mean a pointer to an array of pointers instead. In C multidimensional arrays are a little bit strange if not to say inconsistent. As you can see fixed size arrays look in the organization similar to what the data area of a LabVIEW array does (but a LabVIEW array is always a handle to the data) while non-fixed size multi-dimensional arrays are really hard to deal with.

There is a VI File Info.vi in the OpenG Toolkit file package that allows to change the modification date and creation date of a file provided the current user has enough privileges for the file in question. The prototype you are showing in your VI is VisualBasic syntax and not very helpful for LabVIEW purposes. LabVIEW is strictly typed just as C is and needs to be configured to match the expected C types exactly. If I remember right then FILETIME is a 64bit integer or a long long. This can be achieved directly in LabVIEW 8 with the (u)int64 but in LabVIEW before 8.0 you would have to create a cluster of two (u)int32 and pass that instead. Rolf Kalbermatter

The SetWindowsHookEx function takes as one of the paramaters a callback function. This is a function pointer and can only really be confortable done in C so you will have to write a DLL in C that does the hooking. The callback function will inspect the message passed to it and either modify some parameters, deny handling of the message altogether or allow handling of the message unaltered. The return value of your callback function determines if the message should be further handled or not. It's a low level work area and if your callback function does the wrong thing you can get your Windows system in a rather hard to control state. (Ctrl-Alt-Del) may be your only friend then or the reset button. Rolf Kalbermatter

As Chris said demand is the key issue with NI. But another issue is that OpenOffice was not a well known topic at all back when the report generation toolkit was created. Otherwise chances are that at least a basic interface to OO may already have been built into by an enthuastic NI developer. Several of the example libraries and toolkits started out as a private pet project of someone inside NI and sometimes even outside of NI. Rolf Kalbermatter

As far as I'm aware a large part of the find uitlity is not exposed at all to the LabVIEW diagram. Maybe that changed in LabVIEW 8 but in earlier versions the Find utility was a LabVIEW internal dialog that had direct access to all internal methods of LabVIEW without having to go through a VI server interface. Rolf Kalbermatter

Nice work from JdP indeed. This is what most Windows programmers do not seem to like very much but which is very common on Unix. Just call the other program directly with some parameters. It keeps everything rather simple by using standardized interfaces, leaves specific functionality to the tools that can do them best and follows the KISS principle. Right, I undersign the (someone else ) part! I'm not a masochist and doing Active X on MS Office applications is aiming for a moving target! Not much fun at all! Rolf Kalbermatter

Some very minimalistic Vision VI functions are installed by NI-IMAQ the driver software for National Instruments image acquisition boards. Those functions allow NI-IMAQ to give you an image back into LabVIEW but that is about it. The Vision Development Toolkit is a much broader library that contains all the VIs that you could possibly dream of. Rolf Kalbermatter

You got quite a bit wrong here! First the arrays you have are all fixed size so they are inlined as such and represent nothing like a pointer. You would need a cluster with following setup: int32 num cluster of 4 uInt8 name cluster of 16 int32 dnum uInt8 flet cluster of 16 * 256 uInt8 aname Especially the last one is not very convinient to do and I personally would treat the entire structure as an array of unsigned bytes passed as a C array pointer and write VIs that insert an retrieve the according information from that byte stream. Rolf Kalbermatter

Capturing events from other applications is something only doable with Windows API programming and with some involved ones too, using callbacks and such. Search MSDN for filter hooks such as the SetWindowsHookEx function does. Basically you have to install a global filter hook for the events you want to block, implement the callback function that receives the redirected events and discards them depending on the passed parameters etc. Doing this for LabVIEW will absolutely positively mean that you have to write an intermediate DLL. Rolf Kalbermatter

I'm no expert in c++ but LabVIEW will only be able to handle standard C types. They also are the only types that are really standard across C compilers. I think the best is to declare your function prototype as standard C such as: #if defined(__cplusplus) || defined(__cplusplus__) extern "C" { #endif int MyFunction(double array[], int length); <other function protoypes you want to export from the DLL > #if defined(__cplusplus) || defined(__cplusplus__) } #endif This should tackle most of the problems with C++. Rolf Kalbermatter

I'm pretty sure MAX is not a LabVIEW application. Probably not even a LabWindows CVI one. Rolf Kalbermatter

That is what you get when playing with forbidden toys ;-) Sincerely I haven't used this method at all but the host window is the window handle of the window you want to be the parent of your VI. This handle is the platform specific window datatype such as HWND under Windows or WindowPtr under MacOS. As you can probably see it is not so much meant to embed VIs into other VIs (Subpanels do generally a good and often even better job in this) but to embed a LabVIEW frontpanel into a non LabVIEW window. That said I doubt you can embed windows across process bounderies so this method has probably mostly only limited value for some obscure projects NI has been working on. Rolf Kalbermatter

I know this might be a moot point with LabVIEW 8 only supporting 2000 and XP anyhow, but there are many people still running on older LabVIEW versions and Windows OSes. And for them .Net is not just an inconvinience but simply an impossibility. So why use a high tech laser cutter for something where a simple pocket knife will do more than well enough? Rolf Kalbermatter

Hmm, if you would want a complete one it would be more something like a few 1000 I'm afraid. And if you only want a subset you open all doors for a fight about which are important: VISA, IMAQ, Database, Internet Toolkit, IVI, Active X, .Net, etc, etc? Better don't go down that path ;-) Rolf Kalbermatter

Robolab is AFAIK a commercial software actually meant to be used with Lego Mindstorms. The fact that you can download it from some servers does not mean that it is free and Open Source. And as far as OpenVisionToolkit is concerned, why not step up yourself and show to everyone that you want to do some real work ;-) Rolf Kalbermatter

Does your server need authentification (password) to connect too. That would be the most obvious reasons. The server initially accepts the connection but when seeing the client trying to send mails without first doing authentification it simply drops the connection. The SMTP VIs do not support authentification of any kind so it will not work for email servers requiring that. And since you do seem to get a connection initilially I'm pretty sure you got the server name already right. Rolf Kalbermatter

LabVIEW 7.1 should not need a patch to do inport and outport on NT machines of any color (NT4, 2000, XP, 2003). But you need of course the Port IO support installed on that machine. In the Application Builder in the Installer Settings->Advanced dialog make sure you also select the Port I/O Support under Additional components to install and rerun the resulting Installer on your target machine. Rolf Kalbermatter

If you get this kind of error when calling DLLs then you are doing something wrong in the Call Library Node configuration. Show us the prototype(s) of your function(s) and the according VIs then we might be able to help you point out possible problems. Rolf Kalbermatter

BOOL in Win32 API nomenclature is really a 32 bit integer while a LabVIEW boolean is an 8 bit integer. In this case it might be a non issue but if you pass it as a function parameter this might be rather important. LabVIEW assuming an 8bit integer might decide to only initialize the lowest significant byte of the 32byte value pushed on the stack leaving the other 24 bits at random. If the DLL expects a Windows BOOL instead and does the standard boolean expression evaluation of only comparing against being non-NULL, you likely will never see the DLL receive a FALSE no matter what you do in LabVIEW. As far as using signed or unsigned integer for a Boolean does not matter at all. Since a Boolean by definition is either 0 = FALSE or non-0 = TRUE, the signed evaluation does not matter at all. Rolf Kalbermatter And how does the prototype of the function look, you are trying to call? Rolf Kalbermatter

LabVIEW does not support this because there is no possibility to do something like this from Win32 API or any of the other OS user applications APIs LabVIEW runs on AFAIK. You would have to go directly to the filesystem driver API and that is messy and prone to errors not to mention that many filesystems couldn't possibly support such a mode at all. Rolf Kalbermatter

Well, by predicting the future you basically changed the timeline that could lead to such an event and prevented it from happening . That is what you get if you try to be smarter than what nowadays physics is willing to allow us mere mortals to be able to do. But in principle you are right. It's not worth doing because LabVIEW is a compiler. So the only reason to do that would be for performance reason and in order to make really a difference that would require a highly optimized C compiler and that is a business only a few crazy people at Intel and some more in the Gnu CC project are willing to tackle Just as trivia here, if you have the Application Builder you already have a C compiler on your system. It is the LabWindows CVI compiler engine packed into an Active X Automation Server. This is used to compile the C stub wrappers and link the final DLL executable image for DLL targets. The C stub wrappers are the actual functions exported from the DLL and take the stack parameters and translate them into LabVIEW datatypes, then invoke the actual VI through the LabVIEW runtime engine and reverse the data translation for any return values before returning to the caller. But LabWindows CVI never has been and most probably never will be a highly optimized C compiler. And it doesn't have to be because it's strength is in the Test & Measurement integration and the shaving off of a few nanoseconds runtime performance is almost never critical to any application that might ever get created in LabWindows CVI. And if you ever happen to get across a function library that needs this high optimation then you will have to get the Intel C compiler and create an object library that you can link into your project, not really that a high investment actually Rolf Kalbermatter Basically almost every LabVIEW application I have written so far spends probably about 99% of its CPU time waiting for user input events and in doing so causes a real CPU load even on lower end machines of a few %. A project that I'm working on and off for the last 7 years is about controlling a 5 axis motion system over a DLL, some 20 or so serial devices, communication with 3 more devices over TCP/IP, doing image acquisition for position recognization and barcode decoding, writing data files to disk and when running full speed controlling all these devices more or less in parallel (each device is controlled by its own deamon consisting of a dynamically launched VI and communicating its device states through dynamically instantiated LV2 style globals to the main system) CPU load never peaks higher than about 30% even on an 7 year old Pentium machine running Windows NT4. And there are similar other applications. I really seldom have seen any of these applications peak even a single time close to 100% CPU time other than when switching from a different application to that application on older low end machines when all the user interfaces need to completely be redrawn. Rolf Kalbermatter

This seems like overkill. What you are trying to do while not impossible is not how the Excel Active X interface was meant to be used. Rather than trying to find out how this would have to be worked out and then maybe the more complicated thing to try to explain it I would rather suggest to send the data to Excel instead and then start a macro in the Excel Spreadsheet that takes those data and creates an Excel Graph from it. While this may sound work intense I'm sure trying to get a LabVIEW graph properly into Excel as bitmap will be at least as hard and that would assume you know how to build a device independant bitmap in memory and transfer its handle across process bounderies. Rolf Kalbermatter

Go to msdn.microsoft.com and search for the function you want to know about. Rolf Kalbermatter