asbo

I had thought that timestamps readily coerce to doubles, but it seems that using the To Double Precision Float primitive is necessary.

There's a Boolean to 0,1 primitive which will help. Use an array of booleans to create an array of your Y values, bundle it into a waveform, and adjust its properties as necessary.

[citation needed]

Aww, crap, you're right. What a shame. On the other hand, your implementation didn't trail by very much: KnuthShuffleStringBenchmark.vi

I was, actually, but I stopped after reaching First Class - they must have started making connection to programming in Life and beyond It doesn't have to use a sequence structure, the reinitialize to defaults method would work as well ... but then you'd have to wire the error to both loops. So a little messier, maybe

That's It's different because the setting doesn't syntactically change the language, it simply adds nodes where it thinks you mean to have them.

I'm glad you explored that a little bit - my knee-jerk reaction was just to use the timeout in Loop B and all would be well. However, I propose another solution to the race condition: don't reset the local after Loop B completes, reset it before passing the occurrence into Loops A and B at the start. It leaves the boolean in a TRUE state, but I don't see that causing anything but aesthetic problems.

In this case, why wouldn't it be accepable to have the default value passed out? It's a tricky situation all the way around, I guess. I disagree - something so fundamental as tunnel behavior, particularly in a niche case, shouldn't be a setting. I don't have a solution to the problem, but I don't think functional behavior should be squirreled away in configuration.

Oops, I missed Ton's message too. I'm with Jim on this one, there's a lot of icon real estate that's unused, so I think it makes sense to use the polymorphic instance icons. I don't think it will "cause issues" per se, but it's painless and if it will save some organization grief down the road, why not? WRT DAQmx, typically the icons are already pretty busy, and it would be difficult to convey the multitude of choices adequately in the icon (DAQmx Read, for example). Just my two cents.

Riffle. I was banging my head against my desk trying to remember that name. Here's my take on it. I benchmarked it using 1KB of Lorem Ipsum text on my Quad Core i5 and it happy chewed up 25% of each processor. But it averaged < 1ms over 250k runs. Maybe it's late on a Friday, but something seems wrong here. Edit: 70KB in 6ms. Dang. RiffleString.vi RiffleStringBenchmark.vi

I'm onboard with everything here. Especially since NI's verbiage uses cleared, that's what users starting with OpenG might look for.

My brain tried to process that as German. It didn't go well. My perspective on passworded diagrams is that they are not for the protection of IP - it's more about keeping developers away from code that's fragile or not ready for public consumption. The true protection for source code is, like AQ said, to remove the diagrams altogether. If it's code which needs cross-version compatibility, you're going to need another copy of the code saved into the other LV version anyway, right? The only thing this truly prevents is ad infinitum cross-version compatibility, but I can justify that as more of safeguard than a restriction.

D'oh. Didn't think that one through. Touché.

Only thought is that it's suppress.

Keep a revision of the VI which opens with the dirty dot, save to it a different file name, then do a diff (Tools > Compare) between the two.

Bluetooth and TCP both use the Windows Socket API, so it might be a hang-up internally where bluetooth blocks TCP for some reason. 5-8 seconds sounds a lot like the timeframe necessary for a discovery scan.

The instrument manufacturer should have documentation detailing the use of each interface. If they don't provide a protocol for detection, you can fabricate your own once you understand their specification.

Thanks for the source. I'd like to hear more about this, not because I love occurrences so much as I'm curious why the recommendation arose. The wiki article does mention some "unexpected" behavior - maybe that's it.

I hadn't heard that, and would actually find it surprising. Though I haven't used them very many times, I go to occurrences first when I need really simple signalling. DAQ uses them too, doesn't it? Also, rather than the fill-in-the-blank approach, I would have the VI accept a VI reference and use a blocking Run call. It would force you to make all of the potentially-slow code a subVI, but that may not really be a bad thing. On second thought, though, if the potentially-slow code needed any local data (or returned anything), it would take a more work to pull that off.

I would hesitantly guess that because you're using LV calls to manage memory, it will still "know" about your allocations. Having never used these particular functions, I can't speak in specificity, but it might be work writing out some test code that just allocates a crap load of memory and then returns ... then see what LV does when the VI unloads from memory.

Typically, our projects use an architecture based fundamentally on user events. Despite a little bit of setup on the front end, I've grown to like it quite a bit, which is why I rarely find the need for queues/notifiers/etc.

They never drop and the sky's the limit ...

Ask to do both

The Acquisition license is for run-time and the Development license is for ... well, development. The end user should only need the Acq license for the software to run properly.

What's your OS? I'll run LV2009 and LV2010 on Win7 x64 if you backsave the VI.