Actuating a Piston With two valves in a cycle

[GBEN]

Hi Community,

I am looking to actuate a hydraulic piston that has two valves and an LVDT reading piston position.

SV0 lets hydraulic fluid in to insert the piston

SV1 lets hydraulic fluid in on the other end to retract the piston.

An LVDT reads the piston position and is an analog in signal, let's just say 0-10 of arbitrary units for now.

I am looking to actuate and retract the piston in a cyclical manner, so for example, when "actuate" button is pressed, actuate SV0 until piston is inserted, then turn SV0 off and actuate SV1 until the piston is retracted, and then repeat until the "actuate" button is turned off.

So SV0 stays on while LVDT is increasing, until the end of the stroke. Then SV1 opens and stays on until piston is retracted. Then SV0 opens again, etc.

Eventually I would want to include a controllable delay between cycles but I can work on that after I get the basics going.

I appreciate the help!

VI attached is in Labview 2019.

Thanks!

[altenbach · Accepted solution]

You should implement a proper state machine.

On a side note, your shift register is not initialized, so it might retain stale value between runs. Is that a good assumption?

You don't need pyramids of case structures for simple logic. Here's equivalent code.

Of course in a state machine you might want to carry the array of three booleans in a shift register and modify it in the various states.

[GBEN]

Thank you for the quick reply!! I was thinking I may need to do a state machine.

I will look closely at your sample and work on this a bit and get back with any questions.

again, appreciate it!

[GBEN]

@altenbach - Thanks again for the guidance.

I spent a bunch of time building a state diagram and building up the state machine (attached VI).

I'm getting close!

Some issues I am trying to figure out though:

1. In my "wait for events" state, I monitor a start/stop process button. When that button is pushed, I go to a different set of states that lead to operating the piston in the desired manner. That works. The issue is, though, that I need to continuously still need to monitor that "start / stop process" button while the other states are still transitioning between one another. 

For example, if in wait for events the value change of "start / stop process" is detected, and that brings us to state 2, which brings us to state 3, etc (some with conditionals determining what state is next, as seen in the VI), I need to keep monitoring for events while those states 2, state 3, etc are transitioning. 

Do I need to implement a queued message handler?

I tried putting a property node for the value of "Start / stop process" boolean as a condition in each other state but that didn't seem to work well.

2. One of the event triggers I made for the "waiting for events" case is an overpressure situation that checks vs a value.

This doesn't seem to work with the logic being inside the event structure. Where should I be putting the logic, knowing that the boolean "Overpressure" needs to be inside the event?

Thanks again for all the help!  

[GBEN]

Doing some studying and refreshing my learning, I think I found the start of an answer:

I'll get started with method 2, a producer/consumer design.

EDIT: also a channeled message handler looks appropriate

[LVNinja]

The event structure only works to monitor user interface. Otherwise the code will be stucked and not be executed until the user interface trigger that event. 

[GBEN]

Thanks LVNinja, appreciate the response.

That is why I am moving to a producer-consumer structure.

Do you think that is the way to go?

One question with the produce/consumer structure and my application -

where would I put the state machine for all the other cases in my scenario? (i.e. the states not driven by a user input on the front panel, but states the machine transitions to based on previous states and other conditions)

example structure:

[GBEN]

OK, I have a working solution now. I combined a producer-consumer framework, queued message handler and enums.

[altenbach]

---

@GBEN wrote:

OK, I have a working solution now.

---

Unfortunately, all you show is a picture, no real code in sight. Honestly, what we can see has a weird smell, since there are several independent code sections that enqueue new elements. That just does not look scalable and debuggable. I strongly feel this is not optimal, but we cannot really offer suggestions until we see the big picture e.g. what is the other cases/events and what the requirements and states are.

[GBEN]

Hi Altenbach,

I appreciate your reply.

The structure seems fairly straightforward to me and has been working well and relatively easy to debug.

I attached the VI.

The "producer" loop is monitoring for events on the user interface so that none are ever missed and can interrupt the rest of the flow.

The "consumer loop" can transition the state machine as needed but would not miss a button press requiring a different state from the user. 

The VI as attached is a simulation for a system I am building on a crio so some things may seem a little off (I am simulating some controls and data in for instance).

Again, appreciate your advice as always.