ShaunR

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.

And press "Alt" to get just the active window.

I would defensively code a check to see if the file exists, force its attribute to be writable and delete it before trying to save (I actually do this anyway with overwriting files and have done for years). Then phone NI to see what they say. There may be a reason for it.

Sounds like my workplace

I'd prefer a "Wait on notifier history" that only executed the number of elements in the history. LV 2010?

A pendulum swinging is just eye candy. You don't need to synchronise it.KISS.

Animated "Gif" image.

I had this problem recently. My scenario was that the asynchromous consumers could either send a "completed" notifier immediately (no part present) or after some arbitrary amount of time (part has been processed). The sequence engine would wait for all notifications from the subsystems, index a carousel and then send a "Go" notifier to all of them . The problem was that if the subsystems sent it immediately, the chances were that the sequence engine wasn't waiting for the notifier at that moment in time, so on the next round would wait indefinately. The elegant solution would have been the "Wait on notifiers with history". But this doesn't wait again unless you've cleared the notifier and since you don't know which is the last one in an asynchronous system, you don't know when to clear it. If it executed the number of times there were notifications in the history....it would be perfect! The normal notiifer will only execute when you are actually waiting (if ignoreprevious is true) or again, you need to clear it (if it is false). So that didn't work either since the sequence engine was unlikely to be already waiting if a subsytem returned immediately. So I ended up with all the subsytems waiting on a notifier to "go" and a separate 1 element lossy queue for each subsystem to send back the completed (basically a notifier with a history of 1). Luckily I have a Queue.vi so it wasn't messy and just meant replacing my Notifier.vis with the queue one.

Indeed. For me it depends on whether I want (or need) to spend a day thinking about an elegent approach for a trivial part of the program or just want the results. I'm not particularly a purist, so if its neat, easily understood but not the quickest piece of code on the planet, then thats fine.

Surprised me too . But maybe optimisations are coming into play. Not sure what you mean by "whenever possible". If you need to "iterate" then I don't really see any other alternatives apart from "while" loops which don't have inherent capablity to dynamically terminate on the array length. Example perhaps?

The thread that anything runs in is not dependent on the loop (LV 9.0and "for" loops excepted) but the "Execution System" that you define. Additionally, the number of loops is irrelevent. Its the vi's that count! The max thread count is 8x5x5 = 200 (8 per execution system x 5 execution systems x 5 priorities). The default is 4 per execution system with 0 for background . So if you look in process explorer you will probably see 21 threads (4x5=20 + 1 for LV itself). Therefore, if you have 4 threads and 12 loops in 1 execution system in 1 vi which is at "Normal" priority,then the LV scheduler will split the 12 loops between the 4 threads (black magic NI secret how this is applied....chime in here LV gurus!). If you want to ensure that a single loop runs in a single thread (not documented but works for me). Then run those loops in their own vi and in diiferent execution systems (I use other1 and other2 a lot) and in asingle vi. If you change the threads per execution, then you will see the threads grow in "Task Manager". Bear in mind, that LVpre-allocates threads, so you will only see the difference when youre-start LV. One further point. Don't confuse parallelism with multithreading. You can run 2 loops in parallel but LV may only run them in 1 thread and "timeslice" between them. A usefull utility exists in vi.lib\utility\sysinfo\threadconfig.vi where you can change the thread allocations. - Don't know. None of the PC's we use have AMD processors, but seems a bit unlikely.