Guillaume Lessard

You got the first part and most of the second part. It seems like the shift register is precisely what you need. Use it to keep track of a value from one iteration to the next. Currently you always add one to zero; with a shift register you would increment a value that has potentially been incremented at previous iterations. Sounds more useful to me... Guillaume Lessard

There is a "Value (signalling)" property to controls that triggers the "Changed Value" event. I have been using it in order to avoid duplicating code that is inside event structures. You could put that in a state machine (or a sequence, heh) in parallel to your event structure. GL

Thanks JP!! Now, at the risk of beating a nearly-dead horse to a shapeless pulp, I realized that the diagram I posted earlier does, in fact, produce a biased result. Upon carefully reading Knuth's shuffling algorithm, I realized that the correct diagram is: Thou shall shuffle each cell only once. Now we can all go have :beer:, because the code is both correct and efficient. GL

Sorry about the lack of picture. I didn't really try to post a screen shot at first. GL Is there a really easy way to get a picture of the block diagram from within labview? something easier than printing to HTML, that is...

I couldn't help wondering if the two really are statistically equivalent. They happen to be the two shuffling algorithms popularized by Knuth. See this. I'm perfectly willing to take Knuth's word on algorithm correctness! Guillaume Lessard

If you randomly select only one of the two elements, everything will be fine. 1. Select first element with the loop counter 2. Select second element randomly 3. Swap them. Works with no extra buffer allocation! Download File:post-3022-1145556103.vi I would think that this is equivalent to the "cluster shuffle", but I don't really want to try and prove it... Guillaume Lessard P.S. this tends to be the algorithm you find upon googling "array shuffle"...

How about calling the DLL from LabVIEW? If it's a special matlab-friendly DLL, maybe you can make another DLL that wraps it with a labview-friendly interface... =)

On a single, you have only 23 bits available for mantissa (significant digits) of your number. Your first example is 2^24, and adding 1 is below the precision of the format: it gets rounded off. Same thing for the second example. More verbosely but more precisely: http://en.wikipedia.org/wiki/Single_precision

Don't know if that's what you need, but there is an "FP.Run-Time Pos.Get", and one of the items is "Position" (top and left.)

The Win32 call SystemParametersInfo has stuff about the screen saver, power management and many other things... http://msdn.microsoft.com/library/default....ametersinfo.asp When I launch my monitoring VI, I extend the screen saver timeout using that call (I modified some spaghetti found on the NI boards for this purpose): Download File:post-3022-1145046622.vi

Those "native" VIs potentially require large amounts of memory allocation and/or copying. That is a problem whether in LabVIEW or in C or in java or anywhere else. When you're trying to do something fast, spurious memory allocations can easily kill your efficiency, and they're not that easy to prevent in LabVIEW. Many times it allocates blocks of memory in completely unnecessary places, but I haven't figured a way to convince it otherwise... that doesn't make things easy when doing RT work, for example. Vladimir: unless someone else replies with the perfect solution, try and test against your requirements. And what are the requirements? Less time? Less memory?

You should show what you've tried, because you mention parallelism but then your description sounds sequential... Can't you just put a second loop that displays something and waits for a set number of milliseconds?

I tried it in LV8.0.1. It works, but now all my VIs that use error wires are difficult to open until I manage to save them again. The difficulty: "This VI was changed on disk since last opened by LabVIEW. Revert?" followed by "Discard changes?". Clicking cancel in either dialog results in the VI not being opened. In some cases it's a pretty strange succession of those two boxes until somehow it all opens. Edit: Rebooting the computer seems to have fixed this. Not that it makes sense.

I can't think of why LV tries to recompile files regardless of extension... My user.lib is under subversion, and I was quite surprised to find out that LV had re-compiled the 'svnbase' files. What a wreck. Your new mass compiler is much, much safer in that sense. I like!

Two weeks ago I tried slapping together something quick using shared variables; I would previously have done that program using the "Simple TCP/IP Messaging" bag of tricks. The result was not good. Crashes aplenty on the RT machine after a few minutes of run time. Meanwhile I have fundamentally the same functionality implemented the old way and that runs for hours without any problem. I've thus decided that I'm not trying shared variables again on 8.0... Guillaume Lessard

The new architecture that enables seeing the front panels from an RT target as the same time as local VIs is great, but it has problems. If you forgot to explicitely "Connect" to your RT target (ETS) and attempt to deploy a VI to it, LabVIEW (on XP) freezes. Relaunching the app is sufficient to fix it from my end. Or maybe about 3 lines of code on NI's end... (The absence of a "Run" command from the project list's contextual menu is inexplicable.) Guillaume Lessard