Problem with two parallel While loops

Question

I have a serious problem with controlling two parallel While Loop. Here is the deal:
I have written a VI to send a series of commands called Cycle through Serial Port to a custom hardware. One of these commands is setting motor pressure by sending it's command and changing it's voltage. After setting desired pressure I have to read and control motor pressure, again through serial port in a parallel loop. There is a Pressure Sensor in system and I can obtain current's motor pressure by sending a command and receiving pressure value. In the first While loop I send some commands to hardware including Pressure Setting Command trough a state machine. In the second While Loop I read pressure value and then decide to increase motor voltage or decrease  it. Now the problem is in communicating these two loops. In cycle after "Init" state when state reaches "Pressure 2 Bar" motor voltage will increase. Meanwhile I have to control this voltage in parallel While Loop. As you can see I used Local Variable to communicate between these two loops. The problem is that loops are not synchronized. Specially when I switch to "Pressure 3.8 Bar" state during cycle running control loop (second while) is still working based on "Pressure 2 Bar" state not 3.8 bar. Because of this motor pressure goes to 3.8 bar for a sec (becuase of  "Pressure 3.8 Bar" state) and comes back to 2 bar (because the second while still has not gotten that new state,most probably cause of all the delays in the loop)  and after couple seconds it goes back to 3.8 bar.
I really don’t know what to do. Is there a way to fix this? Or I should consider a better way to do this?
I went through Occurrence Palette but couldnt figure out how to embed that in the VI. 
Sorry for my poor English. I attached VI and it's subVIs as a LLB file. I can explain more details if somebody wants. 
Attachments:
QuickStartCycle.llb ‏197 KB

Answer 1

I make it a point to NEVER have a WAIT function inside a state machine.
It sort of defeats the purpose, which I define as "Examine current state; decide whether you've met the conditions to advance to another state, then get out".
For example, I have a single state machine VI controlling four identical instruments, via TCP connections.
For some functions, that means issuing a command, waiting 60 seconds, then reading results.
If I waited INSIDE the state machine, then it's tied up waiting on one device and cannot handle any others.
Not a good plan.
To handle this, I have a loop which calls the state machine.  After issuing the command, the state goes to "Waiting on Response", and there is a target time of 60 seconds from now.
It's called over and over in that state, and each time merely compares NOW to the target time.  If NOW is past the target, then we read the results.
the state machine can tell the caller when to call back; that's how I distinguish between an urgent need and nothing-to-do.
By having the CALLER do the waiting, instead of the state machine itself, the state machine is free to handle another device, or do something else on the same device.
You should be calling the state machine over and over and over anyway.  So, have the state machine "control the pressure" on every call, and THEN examine whatever state it's in.
Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com
Blog for (mostly LabVIEW) programmers: Tips And Tricks