bernie_carlton
Lifetime Supporting Member + Moderator
I guess I have it lucky as the mechanical designers have pretty much designed their part of the machine before I get into the act. But I don't ask about inputs or outputs first.
I ask 'what happens first'. I don't ask what causes it (motor, cylinder etc) just what happens. I write that down. Then I ask 'what happens next'. I write that down. Then I ask 'what caused it to stop doing 1 and start doing 2'? This may be 'a sensor detects the work' or 'it has done this 3 times' or 'a certain amount of time has gone by'. You see 'what happens first' is "STATE 1". 'What happens next' is "STATE 2". 'What caused it...' it the "STATE TRANSITION 1-2". We continue on establishing states and transitions until, generally, we get back to the point that "STATE 1" is the next state.
Once we get the entire machine function established with all the states and transitions and only then I ask about the actual input and output devices. Once this information is nailed down I can write the program (thank you AD for STAGE Logic) in an incredibly short amount of time.
Generally the only thing that has to be modified at start-up is if the designers forgot a step. Error detection becomes fairly obvious as 'in state X too long' or 'event X happened (and it shouldn't have) while in this state'.
Of course our machines generally have multiple sequences of states happening at the same time with some interlocking between states. But it's just an extension of this method.
I ask 'what happens first'. I don't ask what causes it (motor, cylinder etc) just what happens. I write that down. Then I ask 'what happens next'. I write that down. Then I ask 'what caused it to stop doing 1 and start doing 2'? This may be 'a sensor detects the work' or 'it has done this 3 times' or 'a certain amount of time has gone by'. You see 'what happens first' is "STATE 1". 'What happens next' is "STATE 2". 'What caused it...' it the "STATE TRANSITION 1-2". We continue on establishing states and transitions until, generally, we get back to the point that "STATE 1" is the next state.
Once we get the entire machine function established with all the states and transitions and only then I ask about the actual input and output devices. Once this information is nailed down I can write the program (thank you AD for STAGE Logic) in an incredibly short amount of time.
Generally the only thing that has to be modified at start-up is if the designers forgot a step. Error detection becomes fairly obvious as 'in state X too long' or 'event X happened (and it shouldn't have) while in this state'.
Of course our machines generally have multiple sequences of states happening at the same time with some interlocking between states. But it's just an extension of this method.
Last edited:
