I looked at your Executive VI. I do not have any easy way to save back to LV 7 now so I am going to attempt to describe in words how I would approach this mess.
I think it can be done with two loops, one event structure, one case structure, and no local or global variables. Actually there will probably be a few small case structures and for loops inside some of the case, but nothing like the ~12 layers of nesting you are now fighting.
Look at the Producer/Consumer (events) design pattern as the starting point.
The Producer loop (event loop) will have the event structure. It will have a case for every control which requires immediate action. The ones I could identify are: Get Telemetry, Print Front Page, Open Log, Abort, Press Char Mode(?), Temp Char Mode(?), Scan, Stop, End Wait, Single Step(?), Continue, and Execute. Most of the buttons should be set to Latching mechanical action and the terminals placed inside the appropriate event case. Then no locals are needed to reset them. The ones with (?) may not need event cases. You may want to have a timeout case to display your Date and Time, eliminating that (painful to my eyes) loop. I am not sure about the other stuff in the timeout case, but most likely it belongs in the other loop. If the Chamber 1, 2, .. buttons change during runs, they may need event cases also. Inside each event case is exactly one item: the Enqueue function. Create a Command enum and make it a typedef. Enqueue the value of that enum. The queue will be read in the Consumer loop where all action occurs.
The consumer loop is your state machine. It has a Dequeue function to get a new command from the event structure. It has several shift registers to pass data from one case to another. These eliminate your global and local variables. I would have shift registers for each of the following: The State (typedef enum), error cluster, Temperature (array), Pressure (array), Results (array), Stat Results (array of clusters), and a big Indicators_Flags cluster (typedef). The Indicators_Flags cluster would have everything which is in the cluster you initialize in the black frame sequence (and then never use again) plus all indicators Except the arrays in separate shift registers plus all your globals and any status flags you might need.
The case structure is the heart of the state machine. All the shift registers pass through it. It will have cases for everything the program does. Everything in that black Initialization frame goes into about 15 Init cases. The while loop at the right of the initialization frame goes away but the cases inside become some of the cases of the state machine. The Temperature Cycling frame code goes into 1-3 cases. The Pump mode code and Pressure Read from your event timeout case move to 1-3 cases. Telemetry code: 2 cases. Print Front Page: 1 case. Excel code. Abort code. Temperature and pressure cycling code from main program: 5-20 cases. Graphing, saving to file: more cases. Shutdown: 1-2 cases.
I would make a list on paper of all the cases you think you may need and use that to create a typedef enum to control the cases. By making it a typedef, it is easy to change without chasing all over the code looking for the constant in every case to change. The enum names will show up on the case structure like strings. Create the loop, the shift registers, and the case structure. Wire the shift registers through both of the original cases then duplicate the case until you have a case for each value of the state enum. (Do not use the Make case for every value option because that will make empty cases that you will then need to wire through.)
Then copy code from the various places in your existing code to the appropriate cases in the new VI. Try to avoid copying locals as that will create new controls. Use unbundle by name and bundle by name to get data into and out of the big shift register cluster. This provides self documentation of the data being used.
Check back in a month when you have other problems. This will not be a quick fix. But it will be worth it to have a program which works and is maintainable.
Lynn
