Controlling one vi from another (auto button pusher)

Question

The labview forums have been such a great resource, especially for someone that is not an expert level programmer like myself, that I thought it was just about time, that I tried to give something back to the community of people that have been so helpful. I just recently solved a problem that I would think effects lots of other industries, and that possibly many people have been in a similar situation.
We have a fully built labview program that tests a box that we have here. It is an actuator for the aerospace industry. But it could just as well be any other sort of electronic box. The labview code has been evolved for a number of years now, by many different developers, and is in a word AWFUL. It is just about the the most complicated and convoluted code I have ever seen. What makes it even worse, is that there is no documentation whatsoever. Imagine trying to fix the engine of a car, with no instructions as to how any of the parts are supposed to work, and you get the idea. 
The time has come in our developement process, that we want to start doing some automation. The main .vi has buttons and indicators that a technician will enter information into, send it to the box, and then wait for a response (part of a testing procedure). The code is not modular at all, and it would take a VERY long time, to attempt to re-write the code as it should have been written, in a more modular fashion. So what to do?
So I came up with a concept that I am calling "automatic button pushing". So basically what I did, was perform an Asynchronous VI call, to the VI in question, and then use various references and property nodes back to that VI, to push the buttons, and then look at the responses, as though I were a technician doing it manually. Clearly, this is not the most ideal solution. The proper way to do this, is to re-do the software so that things are more modular, and then probably use something like teststand to set up the testing for it. All of those things will happen in the future, but they needed something quick that can bridge the gap, and they did not want to touch any of the original code, as that would require re-certification etc. So what I proceded to do was to create a series of sub-vi's that touch all of the various buttons, and read the indicators that I need. Then string them together in a top level .vi to create a fully automated test. Enclosed is the subVI that I used to do the Asynchronous VI call, and an example of one of the controls that I am "pushing".
I am thinking this sort of thing might be very useful for others. Hope this is helpful.....
Attachments:
Enum Control.jpg ‏74 KB
Async Call.jpg ‏40 KB

Answer 1

djs_at_eaton wrote:
Your description:
The labview code has been evolved for a number of years now, by many different developers, and is in a word AWFUL. It is just about the the most complicated and convoluted code I have ever seen. What makes it even worse, is that there is no documentation whatsoever. Imagine trying to fix the engine of a car, with no instructions as to how any of the parts are supposed to work, and you get the idea.
sounds frighteningly familiar.
Unfortunately your situation is quite common.  But I'm wondering if you couldn't simply have used normal LabVIEW techniques to call the code as a sub-VI.
I understand your misery.  I've got code with a cluster of about 140 variables passed through a queue-driven case statement with over 100 cases.  Each case can add any other cases to the execution queue.  I'm not sure the original programmer understood it.  I'm rewriting it.
Something like that, I would likely leave alone.  You just don't know that something idepending on something that was coded incorrectly.  You could end up chasing your tail.
edit
Unless, of course, that was the scope of the project. 
/edit
Bill
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.