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.
Friday, December 19, 2014
Friday, November 28, 2014
A Different PLC !!!
I'm taking a break from the historical narrative. One reason is that I am still working for the company I moved to as mentioned at the end of the previous post (over 30 years now) and feel that I would unfairly edit my posts. But I'm near retirement, so the updates won't be long in coming And I will try to update more often.
Over my career using PLCs (and I must say, I didn't PLAN it, it just kind of fell in to place) I have dealt with many different manufacturer's PLCs. The first major shock to any PLC programmer is not the learning of the first PLC but, when confronted with the next PLC realizing that they are DIFFERENT!
So let's discuss items which appear common to PLCs:
They accept 'Inputs', which is data from an outside source. This may be 'discrete' (On/Off) or 'analog' (a value within a range of numbers which reflects the level of a continuous measurement). The 'analog' or numeric information may also represent 'text' or other information. 'Analog' will be used to refer to any information represented by more than one 'bit'. The information may come from local hardware or from remote hardware via some sort of communication.
The 'Inputs' are referred to by a variety of names and stored in various formats. The important thing is, while you must understand how the current PLC references or stores this information, you must not get obsessed that this must be the ONLY way that this information can be referenced or stored.
In like manner 'Outputs' is data sent to an outside location. Again this can be discrete or analog information. It may be sent to local or remote locations. Remember the same warning about being obsessed over the naming or storage.
Next there is information stored 'Locally'. This, again, may be discrete or analog. This is information stored from current or previous states in the PLC. It is useful, when combined with future 'inputs' to generate useful 'outputs'. As in the case of the other two categories, do not develop an extreme affection for one particular nomenclature or method of storage.
Next there is the programming 'language'. In general the programming language provides a structure for transforming current 'Inputs' and 'Local' information into new 'Local' information and/or 'Outputs'. Prepare to be open to different languages.
In conjunction with the 'language' are the available 'instructions'. These are the individual operations which may be performed to implement the 'transformation' I mentioned in the previous paragraph.
You may wonder why I didn't include 'Timers' and 'Counters' in the 'Local' information. In the PLCs I've used most of the 'Counters' and 'Timers' are instructions which interact with stored data to provide their function.
In a very few instances there are separate hardware timing or counting functions which operate external to the particular language or instructions. These are typically more accurate and provide a more precise function than the 'instruction type' timers and counters. These must be dealt with on a PLC-by-PLC basis. Learn how to read manuals.
Why am I being so general in my descriptions? As a programmer you MUST remain flexible. When confronted with a new PLC you need to identify the various areas I have outlined. You must review the language and the instructions. Read about EVERY instruction, even if you don't think it will be needed for the current project. Review any 'help' information including that provided by the PLC manufacturer's web site.
Please, don't be one of those who can ONLY learn with videos (I see more of them claiming to have this limitation all the time.) You must be open to all forms of information about a new PLC. You must use your imagination and THINK !!
In the meantime look for "BeBop To The Boolean Boogie". I kid you not. This is an excellent reference (both in hardware and in general computer thought processes for the PLC programmer.
More on adapting to new PLCs in the next post. (Thanksgiving weekend - 2014)
Over my career using PLCs (and I must say, I didn't PLAN it, it just kind of fell in to place) I have dealt with many different manufacturer's PLCs. The first major shock to any PLC programmer is not the learning of the first PLC but, when confronted with the next PLC realizing that they are DIFFERENT!
So let's discuss items which appear common to PLCs:
They accept 'Inputs', which is data from an outside source. This may be 'discrete' (On/Off) or 'analog' (a value within a range of numbers which reflects the level of a continuous measurement). The 'analog' or numeric information may also represent 'text' or other information. 'Analog' will be used to refer to any information represented by more than one 'bit'. The information may come from local hardware or from remote hardware via some sort of communication.
The 'Inputs' are referred to by a variety of names and stored in various formats. The important thing is, while you must understand how the current PLC references or stores this information, you must not get obsessed that this must be the ONLY way that this information can be referenced or stored.
In like manner 'Outputs' is data sent to an outside location. Again this can be discrete or analog information. It may be sent to local or remote locations. Remember the same warning about being obsessed over the naming or storage.
Next there is information stored 'Locally'. This, again, may be discrete or analog. This is information stored from current or previous states in the PLC. It is useful, when combined with future 'inputs' to generate useful 'outputs'. As in the case of the other two categories, do not develop an extreme affection for one particular nomenclature or method of storage.
Next there is the programming 'language'. In general the programming language provides a structure for transforming current 'Inputs' and 'Local' information into new 'Local' information and/or 'Outputs'. Prepare to be open to different languages.
In conjunction with the 'language' are the available 'instructions'. These are the individual operations which may be performed to implement the 'transformation' I mentioned in the previous paragraph.
You may wonder why I didn't include 'Timers' and 'Counters' in the 'Local' information. In the PLCs I've used most of the 'Counters' and 'Timers' are instructions which interact with stored data to provide their function.
In a very few instances there are separate hardware timing or counting functions which operate external to the particular language or instructions. These are typically more accurate and provide a more precise function than the 'instruction type' timers and counters. These must be dealt with on a PLC-by-PLC basis. Learn how to read manuals.
Why am I being so general in my descriptions? As a programmer you MUST remain flexible. When confronted with a new PLC you need to identify the various areas I have outlined. You must review the language and the instructions. Read about EVERY instruction, even if you don't think it will be needed for the current project. Review any 'help' information including that provided by the PLC manufacturer's web site.
Please, don't be one of those who can ONLY learn with videos (I see more of them claiming to have this limitation all the time.) You must be open to all forms of information about a new PLC. You must use your imagination and THINK !!
In the meantime look for "BeBop To The Boolean Boogie". I kid you not. This is an excellent reference (both in hardware and in general computer thought processes for the PLC programmer.
More on adapting to new PLCs in the next post. (Thanksgiving weekend - 2014)
Subscribe to:
Posts (Atom)