asbo

You can't just merge binary files (which VIs are, obviously) and while LV provides a merge tool, you'll usually spend more time sorting out the merge than just taking one version's changes and implementing it in the other by hand. As for locking, not really - the argument is made (for SVN, as well) that since locks are really only advisory, you should use "proper" forms of communication and collaboration. I don't agree - I think it's awesome to have an SCC which has a built-in mechanism for this situation. In theory, yes, that'd work. The reason I prefer locking is because it's very valuable to have the repository "know" when a developer is working on a particular object so that information can be distributed without any extra effort on the developer's part. I can't imagine having to e-mail around my multi-developer team everytime I was going to update a bunch of VIs - I only see that as useless overhead. Ideally, you never have developers working on the same extra area at once, but exceptions can (and always will) surface - if it's no skin off your back, why not use a system. I can see why you'd want to be able to make commits without necessarily pushing code, though; it's can be handy to have instantaneous versioning as you develop. There's no stigma involved because you're not actually committing WIP code to a public resource. So it looks like your decision weighs down to the flexibility of local version control versus a mechanism to control code concurrency.

These are the right questions to be asking - they're definitely problems OP is going to run into using Git. Since each developer has his own stand-alone repository, it would be very difficult to work concurrently on code; you don't know if anyone else is working on the same code until you've both sync'd with the master or pull'd one another's code. Either way, I think it would add a lot of unnecessary logistical problems that can easily avoided with existing, proven solutions. It's a really, really awesome system for files you can merge (a.k.a., text) but I think that (and some people on LAVA disagree) that using SCC with a locking paradigm is the right way to develop LabVIEW code.

Just out of curiosity, was there ever consideration given to the primitive having a context-menu option to offer access to either behavior?

Actually, it says "Ur computer needs" ...

I disagree with crelf - I think the path constant should go above the while loop.

This NI article might delineate the two for you. Again, that there are two different paradigms available is just my presumption from looking at your block diagram. You really ought to be googling something like "labview DaqPad 6020e example". Also, here are some caveats of the DAQPad-6020E. You can read a lot about error terminals on the LabVIEW Wiki. In a nutshell, writing code without error handling is like driving at night without headlights - you may pull it off, but it's a really bad idea.

I know, right? I was totally expecting to come back to nice, bloated RSS feed, but all I got was Alfa String ...

If I'm seeing this properly, you're doing a point-read for AnCH2 and a buffered-read for AnCH3 (or maybe vice versa?) - is there a reason for this? Either way, it looks like you're mixing channel-based and task-based paradigms. You're using Build Arrays on all the channel terminals - have you tried putting AnCH2 and AnCH3 in an array together, passing that into your Config/Wave VIs and seeing what is spat back out? And maybe most important - wire your error terminals together!

The OneNote Developer Center is as good as any place to start. They do have a video right on the front page, Video: Introducing OneNote Programmability and How To Develop Solutions and Extensions, as well as a two part series on the COM API that's new in 2007.

Odd, I would have totally swapped your definitions here.

I was able to make the VI reetrant, but that made no difference either. Of course, I manually inlined the VI long ago, now this is simply curiosity. I was hoping that perhaps someone would have a laundry list already, but it seems this is a relatively unused token.

28.20513% - Total Geek. Not so bad. And yeah, there's 5 checkboxes at the end if you're female. Cow-orkers, you say? Sounds delicious.

Non-reentranct. No USRs. No feedback nodes. No local variables. There is a static property node, but it's in the one that works (and it gets deleted upon inlining). No required terminals.

I thought about that as I wrote it up, and unfortunately came up with no good absolution. The way I see it, if a Moore machine can only progress based on the current state, how can it possibly do any decision branching? Yeah, I could see that as well, particularly with sticking states on the front of the queue. Perhaps Moore and Mealy didn't think that there would ever be such a thing as a QSM - 640K ought to be enough for anybody, right? It's entirely possible that it succeeds definition by Moore or Mealy. As a hilarious aside, it seems some vandalism has escaped the WP nazis ... for now:

I suspect when your memory overflows, you will get some pretty strange behavior, or your application will crash altogether. You could use a circular buffer to replace the oldest data with the newest. There's plenty of information about these (and a version to download) on NI's website.

Nope, it's really quite a straight forward situation. It's my own VI, not polymorphic, it has a block diagram, unprotected, not in a class. VIs similar to it in code structure and prototype will inline OK, but I have found others which also will not inline for any obvious reason. Going through VI properties didn't give me epiphanies, either.

Per the handy INI key in http://zone.ni.com/devzone/cda/pub/p/id/347#toc2 you can enable code inlining in the development environment. However, I went to use it and the menu option is disabled. Anybody know under what conditions this gets disabled?

You can use a notifier/occurrence in parallel with your original SystemExec call which will do a System Exec of taskkill.exe /im "your executable/script/whatever" after a given timeout. So give your Wait on Notifier or Wait on Occurrence whatever timeout you think your call will execute in. There shouldn't be any harm in calling the taskkill if your Wait doesn't time out, but you could code around that anyway. I noticed you said script, specifically - what kind is it, batch, VBScript, JScript? Depending on that, you may have to taskkill whatever engine runs those scripts, rather than "whatever.vbs". For a batch file, it would probably just be taskkill /im "cmd.exe". Unfortunately, I think that's about as elegant as it gets using System Exec.

Obviously, it's rarely that will you ever see a pure Mealy or a pure Moore SM in LabVIEW. In general, your code will tend to be more-Mealy - when's that last time you built a VI that had no sequence deviations/condition handling/etc? As for Mealy versus Moore, I would classify a state/SM to be Mealy if there's more than one possibility for the next state, strictly from the scope of that state. If decide if you have a "pure" Mealy, simply see if all your state qualify as Mealy. In your instance of states which *don't* queue a state, they can't really be classified as either, I wouldn't think. Mealy machines depend on the current state and *input to that state* - whether or not there are other queued states shouldn't change the classification of the SM. I think because it's more a level above the behavior of the state itself, it should be removed from the consideration.

I am horrendously jealous of folks like you - really makes me wish I had been raised bi-lingual.

Have you tried doing a mass compile and/or source export? Just looking for some way to make LV realize what it's doing is wrong.

No such luck - HD Tune doesn't give me a serial number over USB. This isn't surprising as USB devices can't be queried for a whole lot of details.

My suggestion isn't LabVIEW, so maybe you won't like it, but if you've never heard of it there is a scripting language called AutoIt designed for tasks like this. It implements a bunch of handy APIs which let you do things like find the current activate window, get a list of open windows, get details of controls within those windows, and send keyboard/mouse input to all the of the above. I've used it before and I know a couple other people who really like it (hooovahh, cough cough). You *could* implement these same APIs in LV, but why re-invent the wheel if you don't have to, right?

It wasn't in LV 2009, but there was another thread about a problem like this. Looks like the "fix" was to restart LabVIEW and build it again.

It probably has something to do with the preallocation of memory, these are my theories: If you wire both into the first frame, both arrays are allocated and copied before the first frame executes. If you wire it into a frame in the middle, that frame is responsible for allocating that memory. In your first example, try wiring in the second copy one frame sooner and then wiring it sideways into the case where its needed and see how that affects your timing.