Creating solutions strategy

[vnv]

Hi all,

being a new user I am struggling to understand logic behind Plus+1 Guide.
I am experienced programmer but it seems that this doesn't help when it comes to using Plus+1 guide.
What is missing from information point of view is what is general strategy behind building solutions for mobile hydraulics application.
For example I would like to use Danfoss controller to control machine (driving tracked vehicle). What comes in mind is creating state machine which would describe states of the vehicle itsef and then perform operations inside those states. Is this approach right with Plus+1 Guide or there is other logic behind it.

[FluidPowerTom]

I'd call myself experienced at programming mobile electronic control systems but not an experienced computer programmer at all.  I've used a few other platforms besides GUIDE, so I've got some point of reference.  With that all said, I would advise that the decision to model your program as a state machine depends more on the application. 

If your specific application with driving a tracked vehicle can be described primarily as having discrete modes of operation then you might program it as a state machine.  Conversely, if the logic is more of a mix of dependent and independent functions then you might separate out each machine function and program it that way.  I've more frequently dealt with the latter type of system. 

For example I might have my logic grouped into functions such as 'engine governor', 'engine on/off', 'diagnostics (hydraulic & engine)', hydraulic logic', 'input signal conditioning', 'valve output signal conditioning', and 'winch control'.  To borrow from the IEC you can call these logic groups Program Organizational Units (POU's) which have input, output, and internal variables.  You might, for example, have some signals going from the 'engine governor' logic to the 'hydraulic logic', but for the most part these are separate programmed functions.

All of that said, I sort of cooked that strategy up myself without any sort of experienced mentor, and it works for what I'm doing.  Some of the much more experienced developers on here might have very different ideas.

[oiltronic]

I come from embedded software (asm/C/C++/Perl) and PLC (ladder/FBD/ST) worlds.  My general strategy is similar to Tom's where I divide similar operations logically into separate pages.  I've done a few state machines as well, and using the regular graphical programming environment for this can be challenging.  Some tips:
- consider buses like a data structure.
- avoid merging buses into huge global data structures.
- try to flow the logic from left to right and top to bottom.
- flow usually goes gather inputs -> condition inputs -> determine state -> decide output -> condition output
- label unavoidable reverse-flow signals as such ("feedback!").
- state machines should never store their state in non-volatile memory.
- state machines should be able to re-initialize at power-up based on external input.
- state machines are best advanced and sequenced by external input.

I had to make software that sequenced a number of overlapping hydraulic actuators while the operator held down a single pushbutton.  Some actuators had limit switches, some required over-travel delays to tightly position against a hard stop.  The code ended up quite ugly compared to doing the same thing in a text language.  I created separate pages for each sequence, just to determine the current step based on the inputs, and then I created more pages just to decide which actuator(s) to activate based on the current step.  I tend to use boolean state machine steps, not integer state numbers, as it ties into the rest of the control logic better.  The step flags inside each operator are mutually exclusive by making each step possible only when the previous step is not active.

I also had a machine that needed to move a number of different ways in a cycle, but it was impossible to tell from sensors alone where in the cycle it was, because some steps needed repeating a number of times and the cycle also reversed on itself.  I still did this with boolean step flags but added counters and a few other flags.  This also made it relatively easy to insert a new step in the middle of the sequence, because nothing before or after needed to change, unlike trying to track numeric states (which are only a side-effect of using typical C things like an enum anyway).

Hope that helps more than it confuses.