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.

I'm trying to do something that is identical to what Ravi did almost one year ago, so I will probably reuse as much as possible from his code. What I don't understand is: why the LV Task Manager doens't list compiled VIs?

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.

Lots of Eastern Europe uses 12-XII-2012 or XII-12-2012, where the months are Roman numerals, which has the nice property of being language independent AND distinguishing the day from the month so order isn't ambiguous. I really like this one.

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

It's probably related to:

Please be adviced that this library will cease to operate after end of June because I expect to have new releases out there before that time.

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.

Not sure how many are still reading.

I'm still tagging along, but I haven't done any testing myself yet...

It's not a case of liking. There's some great stuff in there. It's a case that not everyone can use OpenG stuff. It's also not really appropriate to expect someone to install a shedload of 3rd party stuff that isn't required just to use a small API (I had to install OpenG especially just to look at your code and uninstall it afterwards)

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.

In the end, the correction was to change the specification for the board.

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.

I can post my code (somehow ugly because of a lack of time and idrectly using the TS API exemple given with LV...). However, I already tried to trim it down... and it seems to crash just after callbacks are registered. So if the issue comes from a callback code, I'm stuck... Else, it would come from the functions made to deal with users and rights.

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.

Hmmm. Not sure where I got that from. Certainly in the LabVIEW Timestamp Whitepaper I just found it shows it is indeed 128 bit so I;m obviously wrong. But I have recollections of it being 12 bytes as it was one of the improvements (adding a timestamp) to the Transport.lib (which after some research I made 12 bytes). Since then it's just stuck as one of those anomalies to my expectations since 12 is a bizarre number.

I'd be interested to know more about that, if not only out of academic interest.

Technically a timestamp can store much greater resolution. If you go subtracting almost similar timestamps (like your TS1 and TS2) you'll better use Cluster substraction:

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?

LabVIEW timestamps are 12 byte (96 bit not 128). The upper 4 bytes are not used and are always zero.

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.

As an aside. The examples that ship with the SQLite API are, in fact, the test harnesses and provide 99% coverage of the API (not SQLite itself, by the way. that has it's own tests that the authors do). That is why the examples increase when there are new features

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.

Indeed. In fact, there are very few browsers now that do not support them.

I've gone off Chrome at the moment though. Nothing to do with the features or the browser itself (which is arguably the best). More to do with it being so nosy and by default trying to track everything you do and put all your private info on their servers (as I found with my contacts list one day). Still. Not as bad as the iPhone.

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.

Any Android smartphone/Tablet (Like your Galaxy Tab)you can use Firefox, Safari, Azura, Opera Mini, Opera Mobile etc

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.