asbo

Wouldn't you think the answer would be 101010 then?

You can right-click the Express VI, select "Show Front Panel" and have it converted to a normal subVI, at which point you have a foundation you know works. You then have the ability to trim out excess code that you don't need.

If this wasn't an intended feature, it is a ridiculously handy accident. I'd be disappointed if its removal was an intentional change in 2009.

Give ya $5 to hit all mine while you're at it ...

The IEngine has a ShutDown method which has a "final" parameter: I vaguely recall messing with execution stuff at some point but I don't recall anything in specific working. That doesn't mean it's a dead end, per se, but I don't remember anything promising. Does it still present if the block diagram is visible? Have you tried highlight execution and seeing if that changes the behavior? I guess it's important to consider what version of TestStand you're using - we used 4.1. Just out of curiosity, have you tried putting any code at the end of that VI to fake keyboard/mouse input to see how it responds. Solve the problem by hiding it

We saw this problem at one point on a project which uses TestStand API; this may be an important difference as the Simple OI uses callbacks instead of API calls and the Exit button callback really should be doing everything properly. The issue is gone now and it was the least of our TestStand worries at the time, so I can't tell you for sure what's made it go away. It may not be the culprit, but the shutdown procedure in your OI is a good place to start. This is the shutdown procedure we settled on after lots of debugging and extensive support from NI for our API system: 1) Close all the references you have open which related to sequences (Execution, MainSequence, SequenceFile, ModelFile) in the opposite order they were opened. 2) Call a "final" ShutDown on the IEngine automation; close its reference. 3) Call a Shutdown on the IApplicationManager. If this doesn't return true, you need to wait for the ExitApplication event from TestStand. Close the IApplication reference. 4) Close whatever references (events, whatever) you have left. Since we’re not using the same approach, you need to make sure you’re doing the equivalent for the callback approach. It’s possible you might be looking at an issue with windowing rather than shutdown – you could try removing the Set TestStand Application Window VI call. I can’t explain why that’s possible, it’s more of a gut feeling. Good luck.

Is there some reason you can't use an Automation reference and Variant To Data? ActiveXVariantToAutomationRefnum.vi

You'll need to use scripting to create controls at run-time - unless there's an upper limit to how many you'll need. If that's the case, you can hide/show controls as you need. Either way, that page has a few examples to show you how scripting works.

Runner-up for sure.

D'oh. Perhaps next time I'll check my palette first.

I imagined you imagining a NI employee randomly reading LAVA and being like "Oh I knew I forgot something" and frantically writing code and then you writing a post about it -- crazy.

LabVIEW doesn't have the erf function natively, but the MathScript node seems to. You could implement your function as a whole using that.

This is a horrible abuse of SQL datatypes. If there's four values per point, you should have four columns for data per record, one record per point. Tie all the points in a set with an additional column, it could be as simple as a TIMESTAMP. Caveat: you should pick a timestamp before inserting any records and then use that pre-generated timestamp in each record; otherwise, the default behavior for a TIMESTAMP field is use the time of insertion). As for ease of debugging, just "SELECT * FROM `table` WHERE `timestamp`=(the data set you're interested in)". If you clarify your data structure a bit more, I could give you a better recommendation.

I see two ways to approach that: 1) Insert the data to the database as you read those points (maybe write the data to a buffer which commits it asynchronously at a lower priority than your test in the background?) 2) Write a wrapper which expects to have an array of data points and have it loop through the array, committing each point. There are ways to save arrays to a database (serialization comes to mind) but I have never found a good reason to do so. It adds a lot of overhead and there is always a better approach to storing the information. Like I mentioned, you could use phpMyAdmin, but that necessitates the people who are using it to be fairly intuitive and competent. Definitely not the solution to use if big wigs are going to try and review the data.

Based on your description of how much data there's going to be and the interface requirements, I would agree that SQL would be a good solution - if you think it won't suck up too much of your time getting aquainted. Not that I've any experience with it in LabVIEW, but you could have a backend set up for this in less than an hour. I'd use MySQL (unless you find that another flavor is more suite to your task) and throw up a package like phpMyAdmin on a basic Apache install - there are guides everywhere for Apache+PHP installs. If you don't want people to be able to modify the database, then you can create a credential for just viewing the data. phpMyAdmin is designed for use by people who know SQL, but I (believe) the interface does allow more basic use. It's worth checking out if you want more of a turn-key interface. Like I said, I've yet to actually use SQL in LabVIEW, so hopefully someone else can chime in on how troublesome that will be. I think more than anything it's going to come down to just how much motivation you have to not shell out for licenses.

LabVIEW In Life Assures Happiness? Congrats!

Very cool! For some reason, I thought the OLE provider needed some sort of extension from the Excel install. (And I actually skimmed that very article before posting - oops!)

That won't work since he doesn't have Excel installed, though, right?

Good catch - I didn't notice that he was doing that. A space there is just completely incorrect syntax; the driver letter must be immediately followed by a colon and either nothing OR a backslash. That is, "c:" is correct (in some circumstances) but "c:\" is always correct. As a side note, you can have leading spaces in directory names, but trailing are trimmed.

It sounds like a few of you are mixing up page breaks with new worksheets altogether.

Properties >> Scales >> "Time (X-Axis)" >> Scale Style and Colors. Select the top left icon.

This really makes me think functional globals.

I'm seeing this too (with Outlook 2007) and I'm curious - is there anyone who has this problem but isn't deleting each post after having read it? I always deleted them in the LAVA 1.0 feed and never had any problems, but I think it's been established already that this is an IP.Board issue. Also, I think the thread I've noticed doing this most often is the Mat-file IO thread.

In a quick test just now in 8.6, it does in fact reload from disk VIs it does not consider to be changed.

Trying to run an error wire through a local is would just be unnatural looking anyway... the flat sequence structure once again finds purpose.