Friday, December 19, 2014

'State' Programming

An interesting thing thing happened to me. I viewed a description of a system which had a 'state machine' description. To be clear this is description of a system which remains in a particular 'state' until specific 'inputs' or conditions occur.

This happened to be a description of transitions between states of MODEM transmissions.

But it inspired in me the vision that a state machine, not a continuous system, could be viewed as a 'current state' then 'what is required to transition to the next state'  logic situation.

What does using the 'state machine' design philosophy mean in a real-world situation? Of course you enumerate the output devices and the input devices for the system. But then we will temporarily forget them.

Let's say at one point in the operation a section is extended by operating a solenoid until a switch is made. For this 'state' write down 'Extend part A until it is fully extended'. Name this statement 'Extending part A'. You have these parts: the name of the state, an action which is taking place, the condition to end the state and begin doing something else. Continue writing down the states required to perform your process without referring to specific input or output devices.

Other sections of your 'state' descriptions are those required from a power-up start and those required to perform an orderly shutdown.

If you find that a 'state' has multiple things happening the you probably haven't broken it down far enough. It is possible to have multiple states operating at the same time - in parallel. These states may refer to each other for their ending conditions.

We have a machine with multiple sections operating on parts. Each of these section have states working through their operations. When all the section have reached the 'end' state then another series of states is triggered to transfer each part to its next section. Some states during this transfer provide operations on the parts. When it is done the individual section beginning 'states' are again triggered.

I encountered this in the next employment situation.

Because of the then current high cost of PLC systems they had designed their own single-board control systems.

This was based on the 6800 Motorola processor. I reviewed the instruction set available to this processor and the I/O structure they had designed. I was able to find a failure in a system due to an uninitialized variable. I was assigned a job repairing controller boards. But these soon became less competitive due to the dropping prices of PLCs.

Using Allen Bradley PLCs I was able to implement the 'state machine' philosophy of control. But the company needed a yet more cost effective control system. I was able to recommend that the the company change to the PLCs made by AutomationDirect. They provided a more direct method of implementing the 'state machine' design using their RLL Plus version of 'Stage' programming.

2 comments:

  1. Hi. I really enjoyed my brief visit on your site and I’ll be sure to be back for more.
    Can I contact your through your email?

    Please email me back.

    Thanks!
    Kevin
    kevincollins1012 gmail.com

    ReplyDelete
  2. This blew my mind and changed my programming perspective forever. I've dabbled in stage logic before, but I apparently didn't quite 'get it.' Now, thanks to the inspiration gleaned from your story, I did the research and am firmly convinced that such is the most logical path to take when writing for machines. Thank you for sharing your experiences (and for the answers which you have provided to so many which I frequently find useful in my searches for posts on various subjects of inquiry).

    ReplyDelete