asbo

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.

[img=http://zs1.smbc-comics.com/comics/20091207.gif] If you're using the fancy full post page, there's a little button two over from the smilie face which will turn an image's URL into the proper BBCode.

That looks a lot like the Vista/W7 clock widget ...

Nah, I was just prodding for fun. I do recognize the situation you're describing. Invariably, there is going to a be a juror with a different perspective, moral or otherwise, that could hang a jury with the power of nullifcation. It's a sticky situation and it's hard to fairly balance the value of the perspectives of those involved. IMO, though, I think you'd only really run across this situation when there would be value in more closely examining the common conscience regarding the situation. ... I hope the reads as clearly as I thought it.

So, basically, we can't trust the average juror to use their conscience properly?