In the second application example, we will consider the control of a conveyor used to feed components past a test station as part of a quality acceptance process. The components under test are plastic housings used in the production of an elec- tronic product. We will assume that these components have been produced by an injection-moulding machine. Before each component can be used in production it must pass a quality inspection test that checks a number of key parameters including the main dimensions and component identity that is etched into the component surface as a bar-code. A record of each test will be recorded in an external database held on a remote server machine.
The main features of the conveyor are shown in Figure 6.5. This depicts a conveyor belt that is driven by a conveyor drive motor. Components are fed onto the conveyor one at a time and passed under a quality acceptance station from a component feeder. If the component has compliant quality parameters, i.e. they are within the accepted tolerance, and the component has the correct identity, as read from a component bar-code, the component is passed on to the ‘compliant component’ roll-off table. On the other hand, if the component fails any of the quality checks, the reject gate is operated and the component is dropped into the reject hopper. As each component leaves the conveyor, a new component is fed on to the belt from the feeder. The conveyor can be started and stopped by an operator from a small control panel that has ‘start’ and ‘stop’ buttons.
The top-level function block diagram model for this system is depicted in Figure 6.6 To create this model we have assumed that the control will run on a single resource. Later we will consider how the design could be distributed to run on different controllers. Issues such as dealing with conveyor jamming and other exceptional conditions have not been considered to keep the example simple. We have also assumed that the quality parameters are fixed and can therefore be part of the configuration data. In a real system it is likely that these would be provided by an external device or entered from a control panel.
The function blocks that represent the functionality in this design are:
FB_Exec1
This is an instance of an Exec block type. This block fires up a chain of events that keep the whole control system running. It does this by issuing a single initial event ‘InitO’ when the control system is first powered-up. It also produces
Figure 6.6 Conveyor test station FBD Figure 6.5 Conveyor test station example
a ‘Stop’ event when the control system is powered down that causes the conveyor and all equipment to stop.
FB_DriveCntl1
This is an instance of a ‘DriveCntl’ type. This block controls the motor drive and its interaction with the control panel; we will look at its internal design later. This block produces an initialisation event ‘InitO’ when it is first activated that is used to trigger the initialisation of all the other blocks. It also produces an output event ‘EXO’ when the motor changes state, i.e. changes from ‘stopped’ to ‘running’, or from ‘running’ to ‘stopped’. It also has a ‘Running’ output signal that remains true while the belt is moving. The ‘Running’ signal must be true for the feeder and roll-off mechanisms to operate. Note that when an ‘EXO’ event occurs and the output ‘Running’ is true, this indicates that the motor has started and the belt is moving.
FB_Feed1
This is an instance of a ‘Feed’ type and is used to control the component feeder. The ‘Start’ event from the ‘FB_DriveCntl’ is passed to the ‘FB_Feed1’ block to operate the component feeder. An event at its ‘Feed’ input along with an asserted ‘Running’ signal causes the ‘FE_Feed1’ block to push a new component onto the conveyor. If the feed operation is successful, this block then asserts an ‘Onbelt’ output signal and issues an ‘OK’ event.
FB_QualStation1
This is an instance of a ‘QualStation’ type and provides an interface into quality test station equipment. Values for the parameters to be tested are passed into this block on its ‘Parm’ input. This block starts the check of the component dimensions and the scan for the component bar-code when it receives the ‘Check’ input event along with an ‘Onbelt’ signal from the ‘FB_Feed1’ block. When the component has passed under the test station equipment, this block issues a ‘Done’ event and sets a number of outputs. These are: a Pass signal that indicates whether the component has passed the quality checks, the Component identity, quality data and a count of components tested so far.
FB_RollOff1
This is an instance of ‘RollOff’ type and provides an interface into the Roll-off table and the reject gate mechanisms. When this block receives a ‘Done’ event from the test station block ‘FB_QualStation1’ on its ‘Run’ event input, it reads the values of its ‘Running’ and ‘Pass’ inputs. If the ‘Running’ input is not asserted, this indicates that the belt has stopped and so no action is taken. If the belt is running and a pass signal is true, the roll-off mechanism is activated to move the component on to the compliant component table. However, if the component has failed the quality tests and the pass signal is set to ‘false’, this block opens the reject gate and the component is dropped into the reject hopper.
FB_Inventory1
This is an instance of the ‘Inventory’ type and provides an interface into a database in a remote server to store information from the component tests. When this block receives an ‘OK’ event from the ‘FB_RollOff1’ block, indica- ting that the component has been removed from the belt and a signal indicating
that the component is off the belt, it gathers data to be sent to the remote database. The input event ‘Save’ triggers the block to gather the following information: whether the component has passed the quality test, the component identity, quality data and a count of components tested. This information is sent and stored on a remote server. When the data has been successfully received and stored in the remote database, this block produces a ‘Done’ output event. This is fed back to the ‘FB_Feed1’ block to trigger the loading of the next component.
Note that the event streams merge where the ‘Done’ event from ‘FB_Inventory1’
is fed back to ‘FB_Feed1’, shown by a tee-junction. As discussed in chapter 5, this is graphical shorthand for an instance of a standard event function block ‘E_Merge’.
This conveyor example is one in which the execution timing of the function blocks is synchronised exactly with the speed of transfer of components along the belt. The ‘FB_Feed1’ block is only triggered to feed a new component on the belt when the last component has been removed from the belt and its data processed. This contrasts with the scanned execution timing strategy of the previous Temperature control example.
The design of the ‘Exec’ function block type is shown in Figure 6.7. This is an example where an instance of a standard event function block ‘E_RESTART’ has been re-encapsulated as a new function block type to simplify the external interface. The ‘DriveCntl’ is an example of a fairly complex component function block as depicted in Figure 6.8. This provides the following functionality:
• It continually reads the values of the start and stop buttons from the control panel, i.e. every 100 milliseconds.
• It sets the motor drive state, i.e. ‘running’ or ‘stopped’ and writes this out to the motor drive actuator whenever the panel requests a change of state.
• It produces an initialisation event when the panel and motor I/O have been successfully initialised.
• It produces an ‘EXO’ event when the motor (i.e. the belt) changes state between ‘stopped’ and ‘running’.
Examining the internal design of this block, we see that the ‘FB_Cycle’ block, an instance of an ‘E_Cycle’ event block, produces a stream of events at 100 milli- second intervals. These events are used to request to read the value of the control panel buttons, i.e. using ‘FB_Rd_Panel’. For simplicity, it is assumed that the panel buttons can be read as a single Boolean value where true means ‘run’ the motor and false means ‘stop’.
The Run state is held in an RS bistable block ‘FB_EnableRun’, an instance of ‘E_RS’ as described in chapter 5. The ‘Run’ state is set by the rising edge of output RD_1 from ‘FB_Rd_Panel’, which is set to true when the start button is depressed. The bistable ‘FB_EnableRun’ is reset when either the stop button is depressed and ‘RD_1’ is false or a stop input event is received. Whenever the output Q for ‘FB_EnableRun’ changes state, an event is produced on output ‘EO’. This is used to trigger a request event ‘REQ’ to the ‘FB_Wrt_Motor’ block to change the state of the motor actuator. When the motor actuator has completed its change of state, i.e. it has switched between ‘Off’ and ‘On’, the ‘FB_Wrt_Motor’ block produces a confirmation event ‘CNF’. This is used to create the final output event ‘EXO’.
‘FB_Rd_Panel’ and ‘FB_Wrt_Panel’ are instances of service interface blocks IO_READER and IO_WRITER as described in chapter 4 and provide an interface into the device I/O sub-system to read inputs and write to outputs.
We can now outline the designs of the other function block types used in the conveyor test station example:
Feed FB Type—provides an interface to the feed mechanism; its design will
also use instances of the service interface block types IO_Writer and IO_Reader to write output values to actuators and read in values from sensors concerned with operating and monitoring the feeder.
QualStation FB Type—provides interfaces to the quality test station equipment.
This design will again use service interface block types IO_Writer and IO_Reader to operate and read values from the test equipment and vision inspection units. The interface to the bar-code reader uses serial communications that can be modelled using another form of service interface block.
RollOff FB Type—this provides the interface for the roll-off mechanism and
reject gate. Again this functionality can be modelled using instances of the service interface block types IO_Writer and IO_Reader to control the various actuators and read back the values of sensors.