ShaunR

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.

Intriguing question. Well. For loop original 10000 runs = 5080 ms. No for loop 10000 runs = 2ms For loop with 10000 run loop normal but code loop // (2cores)) 10000 runs = 2887 ms For loop with 10000 run loop // (2cores) and code loop // (2cores)) 10000 runs = 2 ms

Don't know where the "attached discussion forum" is, but I've thought for years that "Elapsed Time" should be in ms resolution. It would have been useful then .

Unfortunately you can't because it uses serialised data. I've actually found very few scenarios (so far) where I can use that feature. That maybe due to how I partition my code and the type of implementations.

Now your just being difficult...lol.