ShaunR

Not surprised. Or ya could use one of these or something similar. Google for em. USB Relay Board

You need "current sinking" digital outputs, then you can switch the resistors in direct without relays. The 9172is a chassis. what modules do you have currently? You could also use the parallel port to switch some relays (be carefull about current though). Or a non NI rs232 digital board (about $90).

Amen...lol. Just look at the internet toolkit and the Vision stuff

Twice as long

First you will need to allow the time-out case to execute by wiring a value (say 100ms) to the blue icon in the top left hand corner. You will then have to use the state of the "Running" boolean to decide whether to increment the counter or not. You can use 2 shift rgisters (one for the state and once for the count). This is thesort of thing you will want to use for the counter.

NI also do PCIe cards.

Sounds good to me. I would suggest darlingtons on the output if current is required.

I agree. It has some unintuitive behaviour. It also has a couple of bugs. There's also MGI which is based on the WinInet.

Many moons ago, I had a vi that was basically a wrapper around the write to spreadsheet.vi. It was for a data logger, and since the customer didn't really know what data he wanted saved (and kept changing his mind); I wrote a fairly simple vi that read the header (first row) and compared it to the current header to be saved. It would look at the header and, if a column was different, would insert a new column in the existing file (i.e upgrade it). If the headers were the same, it would just append the data. Old data therefore had no entry in this new column, but the new data would, but both the old and new would still be in-line with the headers. One caveat with this was that you could not rename headers, but that wasn't a problem in my case.

Just for simplicity, I would suggest a TCPIP packet thats sent when your global changes. 2 seconds to add and has the advantage that you don't necessarily need labview on the remote machine (a C++, Delphi, VB app for instance). I prefer TCPIP over UDP since it is far more reliable, although it is not connectionless (i.e you need a target IP unlike UDP broadcast). Once you start down this route, you will quickly find that you want more and more information and it is very scalable and easy to implement

FWIW???? The Vista x32 installation I tried above was on a Acer Core Duo Laptop. It's probably got more to do with multiple installations. I always have problems with activation since I have to do them manually and (for me) its not worth the aggro having multiple installations.

I think you are still confusing Bi-directional with Full Duplex. Take for example the Micro-Epsilon Micrometers and 2D/3D Profilers (just an example, since I used them recently). They can operate by "streaming" data back to the Master (important for high speed acquisition). If this were to be used in a half-duplex manner, then once switched into this mode, you would not be able to control the device since the device is continuously transmitting. However, with full duplex you can. In another scenario, we have 1MBPs full duplex RS485 digital IO boards. The protocol is a command-response type which is appropriate for half-duplex operation since the devices don't start to transmit until a full message has been received. However, since we have upto 10 of these on a bus, most of the time, the RX line is saturated with messages. We can decide to ignore RX messages if they are a bit stale (since the devices must use hold-off and wait untill the line becomes free due to another device transmitting). But we cannot allow the device not to operate on commands immediately via the TX line. Devices such as these are quite common. And "True" full duplex devices actually start constructing the response on the RX line before the entire TX message has been received.

Don't know how MAX does it, but all the NI product versions are available in the regsitry under HKEY_LOCAL_MACHINE\Software\National Instruments\XXX\CurrentVersion where XXX is the package.

Well. Your drive also seems resistant to WMI as well The pervious DLL used 3 methods, the final one being querying the WMI database. Hmmm. Digging deeper........

Whats wrong with the "Write To Spreadsheet File" in the file functions palette? Simple 2D array where the first row is the header.

Try using the "To Variant" function then comparing.

I've just installed LV2009 on Vista Ultimate x32 to see if I get the same problems. I didn't and it is working fine. Are you sure you are installing the 32 bit version of LV 2009 and not the 64 bit version? I didn't try the x64 to see if the installer complains.

Indeed. Actually, it is worse than that. The restriction isn't so much Admin rights, its the "Integrity Level". For example, the elegant way of reading the bios is to use ZwOpenSection or NTOpenSection. However, those functions have an "IL" of High and Admin is only granted "Medium". Its all got very complicated in Vista. But not to be daunted, and since you seem to have one of these problematic drives can you try this one?

The GetDocument only checks whether the type in the header is text or not. If it is text, it saves it as an ascii file. If it isn't, it saves it as a binary file. If you don't wire a path to the file terminal, it will not save anything (and won't prompt you for a filename).

60uv is not much to play with and I'm afraid no amount of processing or filtering is going to help you. You have to try and identifiy where the different components of the noise are being injected (sensor wires make good arials, but a succeptable amplifier won't help either) The only thing you can do is try to reduce the noise and many medical systems utilise the following. 1. Shielded sensor wires. 2, Short sensor wires. Make them as short as possible by placing the amplifier as close to the sensor heads as possible. 3. Battery supply. This not only allows 2, but also means that your supply wires don't pick up noise. 4. Put the amplifier in a sheilded box.

Not quite what I was after. I want to be able to register and use an Event structure I played around with an active X dll that enabled me to register for events using the register callback node which was rather successful, but as I don't allow active X....I binned it . I was hoping to see the events overhauled with LV2009, but severely disapointed when it was only cosmetics. On topic. Looking at BIOS now. Seems to work on most things except RAID. Any pitfalls?

Try using a "Waveform chart" and fix the history length to 50,000. This will automagically append the latest datapoint and drop the first (fixed array size) and you don't have to use the array build functions. You might get away with this if you say its fine up to 5 seconds.

Hmmm. I thought that was only for build. Does that mean its the project's dependency path thats causing Daklus problems, rather than the vi's?

Not at all. Just replace the word "code" with " an object" in your sentence and thats pretty much OOP.

One thing thats been bugging me all day. You say your having problems with .NET. But .NET assemblies are registered (in much the same way as ActiveX). So in theory, no application (including LV) actually knows where the files are physically located, only if a certain function has been registered. What am I missing here?