ShaunR

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?

The USB detect I have uses message notification for removal andinsertion (oh what I'd give to tap into windows messages fromLabview:P) . It just walks the registry to find out what was removed or inserted from the device ID returned. Good to know that that's not foolproof either.

LOL. Bi-directional isn't the same as full duplex. In RS485, you cannot have 2 devices driving the line at the same time, i.e in contention. (In full duplex you can TX and RX simultaneously since you have 2 pairs of wires). If 2 drivers try to drive at the same time (e.g a master is transmitting whilst the slave isresponding) the electrons get confused and you will get rubbish on the bus.

Don't think this would work. Electrons get confused when they meet each other on the other side of the pavement.

Ahh. I have a rule with our programmers. No .NET and No ActiveX. If a "Texty" wants a feature from one of those technologies, he can get off is arse and write it, and while he's at it, make it really easy for use in LV (i.e no obnoxious referencing). You'd be surprised at how often they come up with a far more elegant solution Your options are limited. Unfortunately, the modification bitset is read-only-no help there! You could walk the project list using a vi installed in the environment that re-compiles any vi's when a project is loaded,, but I expect your SC would still complain that the file has changed. The only viable way forward that I can see is to enforce a directory structure so that they can't put the files anywhere and can only check them out to a single "working area" which is the same on all machines. We do this anyway as it means anyone can go to a machines and not spend 10hrs hunting for files.

Not much

Thats a joke....right?

I haven't seen a property node for getting this. The only problem is that I've had the ID change several times due to adding cards or because LV thinks its about time to annoy me. Besides. This disk serial thing is getting personal between me and Microsoft. Damned if I'm going to be beaten by it!

We define a relative path inside the vi that calls the dll (using "specify path on diagram"). So it doesn't matter where the dll lives as long as it lives in the same relative position. It means you can move it anywhere and LV won't go searching or re-compiling. The added plus is that (with LV2009 x64) we can also switch DLLs between x32 and x64 depending on which environment it was deveoped/compiled in.

The two drives tested are SATA. So maybe what you are seeing is peculiar to XP. I'll take one of the laptops from work home and see what happens. I wasn't particularly looking at USB drives since they can be moved from PC to PC, but in my wanderings I did notice they don't give a serial (serialoffset=0). It is looking like the only reiable way is to walk the registry and look at the device ID (was hoping to avoid that since to me it seems tacky), but if I do go that route, at least it will also get the USB drives (I already have a detect USB drive insertion that works of 7,vista and XP that uses that method).

Always the heathen . SCRIPTING! Since your only putting aside 1 week, you'll have loads of scripting goodies at the end instead of just a headache.

Will it support 4-wire? Most industrial applications use 4-wire full duplex. I think you wouldn't have much of a problem supporting 4-wire 1/2 duplex, but it'd be interesting to see how you tackle full duplex through a USB.

Unfortunately, not everyone uses NI products with LV. Anyhoo. New build. Works without Admin rights (well, on my Windows7 x64 and Vista Ultimate x64). Tested so far on the only have 2 drives at at the moment (A western digital and Hitachi). See how you get on.

Then why ask if ists a .NET dll Then why not offer it as a solution to this users request? I didn't see anyone offering a solution, so proffered this since I had to do it anyway. I don't see the point in making miniscule dlls called from labview since you have to install a couple of hundred megs of labview rubbish, so whats an extra few kilobytes? I could have got it down even further (the dll is actually a wrapper around a VCL component) but 162 KB is fine without spending more time on it and having separate source. Saying that. I did recently download a Matrix screensaver for Pelles which was only 56KB when compiled. That was impressive! What Rolf said! The OP did say that he didn't want the volume information serial.

Who makes this? I've got just the project

Thinking about what you said. It did seem a little large even with the extra functions. So I went back and took a look (on a weekend too )and realised a unit was included that wasn't necessary (used during debugging). Well spotted! I Is 162KB more to your liking?

No its a Delphi DLL. It can actually do more than just those 2 functions, but this thread was asking for serial numbers. Saying that though...... Getting the info is far from trivial.

I've just noticed that saving to 8.0 breaks the error cluster wires (another bug?). Just re-wire them and you should be good to go.

I'll fie one First thing Tuesday morning (bank holiday on Monday).

I had to do this this week, so thought I share the result. (N.B. Only for windows)