ShaunR

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)

Yup that what I'm seeing. It makes it really hard to debug (especially state machines). This is quite a serious slip and means it looks like I'll have to go back to 8.6.1.

We have 3 machines now with LV 2009 they all exhibit the same problems. They all have different hardware (and therefore graphics chipsets). 1 is a laptop, one is an industrial PC another is a desktop. 2 are running windows XP professional x32 and one is running vista utlimate 64. When using debug execution, if the diagram is in the foreground, it does not switch cases to the case that is executing. Rather, you have to search through the cases to find the case where half the subvi's and wires are normal and the others are greyed out. If the diagram is in the background or you switch to the background whilst debugging, subvi's icons don't "ungrey" and you loose the arrow that indicates which subvi is currently executing. You can still see the data travelling along the wires though. Has anyone else come accross this? Is this a known problem? Is there a solution?

Not sure how you can compile the Labview Development environment into an exe (unless you mean you re-install it all on the target machine). The only problem with installing LV on a thumb stick is that when you go to a new machine it has different mac addresses so LV licensing crowbars you (I did try, he, he). The good thing aboout booting from a thumb stick is not only do you have a full development system with all those indispensable tools you've aquired over the years, but it leaves the target machine clean.

Not quite sure what you are doing here. You are merging the generated and the echo response analogue signals and then outputting the result to the AO device. So the merged signal cannot be constructed until it has received both signals. It will then output the result to the analogue output device. Wire the output of the signal generator directly to the analogue out device (remove the merge) then merge the analogue in with the reponse waveform from your echo server. I'm assuming your analogue out is connected to your anolgue input so I'm not sure why you would do this since you don't need the analogue devices at all.

We don't use it on PXI, but we use it on Fanless PC's which we run our final labview apps on. It's been a long time since I had to get the image working and I remember it took me quite a lot of trial and error to find everything I needed. But once you have, you don't have to revisit the process again and you can install things like normal XP. Why not try it out. You can download XP embedded on trial. Find an old PC no-one wants and give it a whirl.