ShaunR

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.

Well. I suppose its what you are used to and your requirements (if you really, really need deterministic control and only want to use LV, then theres not much of an alternative). I presume you are in this camp since you are using an FPGA. We have a high IO count (typically >96 DIO lines) so your talking mega cash with cRIO. We use RS485 digital IO boxes (each has 32 In, 32 out, 24v @ 0.5A per channel. Cost to us about £80 each) running at 1MBps which is perfectly adequate for near real-time system control. But of course they are dumb IO. We usually connect them up with a Intel Atom Fanless PC running XP Embedded which we can also put a PCI card in if we need to. Total cost about £1200 and more IO than you can swing a cat at (plus you get Gigabit LAN, USB, RS232, 5v GPIO etc).

I've got a usb stick that big...lol. In fact it (now) has windows 7, Codegear and VC++. I pretty much carry my PC in my pocket and just pick a vacant machine if I'm not at my desk or on-site or forget my laptop. I'm still chained to a chair with Labview though.

I don't have a problem with large installations per say, but when you have to deploy an installation of a couple of hundred megs to run a 300k executable, it makes Microsoft look positively anorexic. I could understand it in the old days when LV run as a virtual machine giving you 32 bit applications in a 16 bit world. But now its just a huge api with loads of dependent apis that have nothing to do with your program (like PXI for instance). ---rant over

Put a single network shared variable in a vi. Save it. Build it into an exe and then build an installer. How big is the installation?

It used to be a great boon that most of labview was written in labview. There were lots of sub vi's installed that found uses outside the original premise. Pretty soon we'll have one vi (call library function) and everything will be a dll call.

I use quad cores and yes 8.6 was a dog (nearly 1 minute to load). I commented on another thread that LV2009 was far quicker (4-5 seconds).

Progress The compact RIO (cRIO) is a separate installation on the DD DVD.I didn't install it since I don't use cRIO (far too expensive) so cannot verify the installation, but looking at my installation I have NI-RIO 3.2.0 and NI-RIO 3.2.0 real time driver installed since vision is dependent on them (quite why I have no idea). I would suggest going back to the DD DVD and installing the Reconfigurable IO section and all its dependents and see if that works. One thought. It you are targeting cRio, it probably isn't 64bit so compiling to 64bit isn't really an option. It might be that the target is only possible on the 32 bit version. Whilst NI do supply FPGA cards for PC's, they probably can be targeted (and therfore the need for the NI-RIO driver core), hence the "Module Not Supported" lines in your screenshot.

This usually occurs with an incorrect baud rate or a baud rate that is not one of the "standard" ones.

Ooooh. Its all got very complicated, very quicky. Now we have variables, events AND notifiers Take your proposed topology. Replace the variable with a queue. Don't bother with events since the queue will wait and you have what I said a few posts ago about a 1 element lossy queue! The only reason you can't use a single notifier is that you have to already be waiting when it fires or (if you use the history version) you have to clear it before you wait. Not every one has (or can afford) the DSC module. Queues, notifiers and network shared variables all come as standard. Coding around it isn't difficult with the built in tools. Its just bloody annoying when a single notifer with a history that gets checked off everytime it executes would halve the code complexity. In fact, it shouldn't really be called a "notifier with history", perhaps a better name would be "notifier that gets round the other notifier bug"....lol.

I don't believe they intrinsically suspend execution until an update is received. They also have huge caveates (e.g cannot be dynamically created at run-time). Its a bit of a sledgehammer to crack a nut IMHO.

Instead of replacing threshold values with 255 (to get your black and white) replace with 1. Your picture control will look all black. If you want to see the results in the picture control, right click on it and select Palette>binary. You will then have a red and black image. Either your black and white or red and white images (binary) will work with mask functions as effectively they operate on zero and non zero for binary operations.