asbo

Are you using the lvsound2 library, particularly the Sound Input library? I know first-hand that its input parameters are buggy, in that asking for x samples at x Hz will not actually return x samples, it will be some proportion fewer. I ended up using a coefficient to tweak some of the inputs to give me (approximately) the right amount of data.

AFAIK, you can install the RTE and use it anywhere. It would be a big shot to the foot to impose restrictions on the base RTE, I think.

Compiled VIs? "Compiled" does not apply to VIs in the conventional sense; everytime you make a change, the IDE is compiling. I think you mean in a built executable - the reason these don't show up is because they're in the Run-Time Engine, and a separate application instance to boot, which is separate from the development IDE.

I've never seen that before, but it's rather clever. I like it.

It's probably related to:

Here's a VI I've used before to change a pair of arbitrary X and Y arrays into a waveform, if you need some help on the interpolation front. XY Data to Waveform.vi

Another vote for the Savitsky-Golay, it's almost beautiful sometimes.

I'm still tagging along, but I haven't done any testing myself yet... I have heaps of reuse installed so that I can draw on it naturally. If I need to, I just do a project analysis afterwards to audit what was used. If anyone's going to, I would expect you to use a totally different paradigm.

Big mistake: started watching this at work...

Bummer that it took so much effort to get things working. However, if you have time to kill, it would be interesting to know if upgrading back to DAQmx 9.6 reproduces the issues. That way, you could hand it off to NI with a test case so they can fix it.

Did you expect them to retroactively fix the board? Re-design it?

It locks up right on the first iteration, right? My recommendation would be to trying reproducing the problem on another machine - if you can't, repair your DAQmx install. If that doesn't work, then try downgrading DAQmx to DCorney's version, in case a bug was introduced.

You could ask about loaning an adapter to see how it works for your setup. Conversely, you could send your adapters in for them to test with.

Sounds like you have a starting place. Start dropping callbacks that you're registering for one-by-one until the crash goes away. Depending on what you're registering for, maybe you want to drop breakpoints right at the front of the callback VIs and make sure they're not responsible somehow for the crash.

I'd be interested to know more about that, if not only out of academic interest. I assume if you cast back to a timestamp, you'll lose the benefit of that extra precision because it goes back to a formatted value?

I've never looked at the actual bitwise representation of a timestamp, how sure are you of this? I've read the whitepaper Phillip linked before and that pretty much cemented a 16-byte representation. Their interpretation examples seem to contest what you're saying.

This is a great two-birds-one-stone technique for public libraries. The author can prove to themselves that the features works (and easily catch regressions) and the users get to see how the author intended it be used.

I like to think they are thoughtfully making a backup of my life so that when I die, they can just reincarnate me from my search history. All I can say is, thank God for incognito mode.

Not that I necessarily think that it's related, but why aren't you using auto dispose ref? Personally, I've only ever seen the Resetting dialog when I really botch something and I'm trying to close a hung, running VI. That said, LV8.2.1 to LV2011 is a huge jump, it could be possible that something upgraded incorrectly. If you haven't inspect everywhere you touch those references. You might toy with the Start Asynchronous Call node that's now available to you, see if it eliminates your issue.

You forgot the best of all, Chrome!

I have a huge JSON archive from a project I worked on some time ago. It's all pretty similar data, but I'll try to find some time to play with it since I'd like to see a JSON library mature.

Loops with 0ms waits (which allows CPU-yielding) really is the best tool we have. This is sometimes annoying to incorporate with significant disk IO and isn't a cure-all - for example, with ActiveX/dotNET/CLNs, anything you have to call in the UI thread is immune to this.

I *think* that for an XControl to be "running", it has to be displayed. I don't think they can be used in a FGV-esque style. edit: And I have almost immediately found something to the contrary: http://forums.ni.com/t5/LabVIEW/XControl-Shared-Variable/m-p/600606#M280070

Got a CAR from NI: 371976. The AE confirmed that it was not the expected behavior that LabVIEW silently include the installers, but nothing specific wrt what kind of fix would be intended.

Make sure you have the the object leak dialog turned on to illuminate when you're not cleaning up properly. Configure > Station Options > Preferences > Debug Options.