Well, the good news is that you already (kind of) have a state machine, meaning you use the enum to control which case you execute. The bad news is that there is only 1 state to run your entire test, which makes it not very flexible at all. One clue that your states are too big is that your diagram way overfills the monitor.
To start, you will want to break your states into much smaller chunks. This will be up to you, but might include: Initialize Instrument, Create Ramp, Begin Ramp, Set Power, Read Data, Update UI, End Test, Close Instrument.
Since you are already using a queue, you can enqueue the next state at the end of each case.
A couple of unrelated notes:
You do not need to name your queue. Especially with an empty string. If you tried to make another queue this way, it would obtain the exact same queue and you would only have 1 queue.
You do not need to unbundle the status of the error clusters, you can wire them directly to the stop condition, (though a better way is to have an "exit" case so that you stop in a safe state).
Even though you have too many functions in the same state, the code could be compressed a lot with more careful wiring. A little organization goes a long way for readability.
