Problem with two parallel While loops

[mostafanfs]

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. 

[CoastalMaineBird]

I'm not sure why you need two separate loops.

Can you not issue the commands and receive the results in the same loop?

I haven't looked at your code (My monitor is only 1920x1600), but I usually attack these things in a single loop:

Repeat

    If NeedToSendPressureCommand

        SendCommand( )

        ExpectedDataType = "Pressure"

    If NeedToSendFlowCommand

        SendCommand( )

        ExpectedDataType = "Flow" 

    If DataAvailableAtReceiver

        ReceiveData( )

        case ExpectedDataType of

        Pressure:  HandleNewPressure(ReceivedValue)

        Flow: HandleNewFlow(ReceivedValue)

    if NOW >= TimeToDoSomething

       NeedToSendPressureCOmmand = TRUE

until Stopped.

If you do need to synchronize the two loops, then look at the SYNCHRONIZATION palette.

There are Notifiers, and Rendezvous operators that might help.

[mostafanfs]

Because I need to have a permanent control on pressure. It's not just setting the pressure. Once I set pressure to 2Bar I might have to keep it 2Bar for hours. So I have to read it and if it was necessary, send it again to keep it in a constant situation. I dont think I have a better option. 

What do you mean your monitor is only 1920x1600? You could simply use CTRL+SHIFT+N to look all over the code. Of course you know that already. 

Has anybody ever faced this issue? What am I suppose to do ?

[RavensFan]

---

@mostafi wrote:

What do you mean your monitor is only 1920x1600? You could simply use CTRL+SHIFT+N to look all over the code. Of course you know that already. 

---

He means your block diagram is way too large.  Using block diagram cleanup helps a little bit to get rid of some of the excess white space.  But your code still takes up too many screens.  The recommendation for good LabVIEW style is to try to keep block diagram to one screen size.  The navigation windows helps to get a rough overall picture of the diagram, but when you have to drag it around so much to figure out what is going on.  It is too difficult to figure out how your program works.

[mostafanfs]

If you look at the code in the first while loop which is a state machine, in some states there is a delay around 10 to 30 second.
What would happen for pressure control if I dont use a parallel while loop to have a permanent control on pressure? It's obvious we wont have control on pressure while those delays occurres.

Anybody?

[CoastalMaineBird]

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.

[mostafanfs]

Thanks Steve

Now it's getting better ...

Could you please attach a simple VI so I can understand it much better?

[CoastalMaineBird]

Take a look at this.

There's an example linked at the end.