Operation definition
From PlcWiki
Each operation needs to be defined by its index and type. All other parameters are optional, but some of them are necessary for a valuable operation definition:
Operation.name.Type = <Operation type> Operation.name.Index = <Operation index>
for example: Operation.AirbagSN.Type = Serial Operation.AirbagSN.Index = 2
A parameter name joins all operation parameters together.
Operation type can be one of the following ones:
SequenceCheck ProductConfiguration LastWPCheck Serial PartCheck PartCode CableCheck (Poka-Yoke Check) Tightening VisualCheck OutputCheckCorrection OutputCheck PidWrite InputSignal VisionSensor PreSequence Measurement RackPartCheck BlindAudit SerialInput DataCheck
Contents |
Operation parameters
Stopping the conveyor
The conveyor can be stopped in case of NOK result of the operation. In case of an operation type OutputCheck the conveyor is stopped immediately after the product ID is scanned. The following parameter is used to define it:
(bool) Operation.name.SendConveyorStopWhenNOk = No | Yes
Automatic sent to rework
The product can be sent automatically to a rework procedure using this parameter:
(bool) Operation.name.SendToReworkWhenNOk = No | Yes
Restriction of a usage of Invalid label bar code
For safety critical operations like VW baugruppen it should be set to "No". Then the control bar code "Invalid label" (PLCIL) is not accepted. The logic is, that a product without safety critical documented items is not cempletely assembled and should not be released to the customer. If it is not possible to scan the part label, the part needs to be changed to the correct one. So then it is necessary to assemble another piece or sent the product to a rework station.
(bool) Operation.name.InvalidLabelAllowed = Yes | No
Restriction of a usage of Accept Bad Counts bar code (PLCABC...)
For very safety critical operations like VW baugruppen it can be set to "No". Then the control bar code "Accept Bad Counts" (PLCABC...) is not accepted. The logic is, that a product without safety critical documented items is not cempletely assembled and should not be released to the customer. If it is not possible to scan the part label, the part needs to be changed to the correct one. So then it is necessary to assemble another piece or sent the product to a rework station. This settings guarantees, that it is not possible to skip such an operation.
(bool) Operation.name.AcceptBadCountsAllowed = Yes | No
Operation dependencies
The possibility to fulfill the operation can depend on other operation(s). Starting the client release 1102151134 it is possible to define multiple dependencies. The full chain of dependencies is considered after this release as well.
If the operation dependency is not satisfied, the operation can't be started.
In case of tightening operations the tightening machine is blocked.
In case of scanning operations the scanned bar code is not accepted (an invalid ID is reported). Enabled scanning operations are highlighted (white) on the screen. Operations with not-yet-satisfied dependecies are displayed in gray.
In case of pick-to-light operations the pick-to-light device is not activated.
The dependencies are defined by the following parameter:
(int) Operation.name.DependsOn[0-9] = <index of control operation>
For the backward compatibility (or to simplify it) it is still possible to use the parameter
(int) Operation.name.DependsOn which is an equivalent to (int) Operation.name.DependsOn[0]
Examples of configuration:
Example 1 - Multiple dependencies WorkPlace.ID = T8 Operation.PartCheck_PassengerAirbag.Type = PartCheck Operation.PartCheck_PassengerAirbag.Index = 3 Operation.PartCheck_PassengerAirbag.DependsOn[0] = 2 Operation.PartCheck_PassengerAirbag.DependsOn[1] = 5 In this case the Passenger airbag (operation T83) can be scanned only when operations T82 and T85 are finished. Otherwise the barcode corresponding to the operation T83 is rejected. The order of operations T82 and T85 can be totally independend on each other.
Example 2 - Chain of dependencies (and a combination with multiple ones) WorkPlace.ID = T8 Operation.Tightening_C214.Type = Tightening Operation.Tightening_C214.Index = 4 Operation.Tightening_C307.Type = Tightening Operation.Tightening_C307.Index = 5 Operation.Tightening_C307.DependsOn = 4 Operation.PartCheck_PassengerAirbag.Type = PartCheck Operation.PartCheck_PassengerAirbag.Index = 3 Operation.PartCheck_PassengerAirbag.DependsOn[0] = 2 Operation.PartCheck_PassengerAirbag.DependsOn[1] = 5 In this example the settings of the operation T83 is the same as in the example before. But the chain of dependencies (8 on 5, 5 on 4) will cause, that the operation 8 depends on an operation 4 as well. Even if the operation T85 is conditional and is not required, the operation T83 can be scanned only when all operations T82, T84 and T85 are finished (or not required).
NOK Sets
So called NOK Sets are sequences (cintinuous or discontinuous) of NOK results of operations which will evoke defined actions. This system enables to define the behaviour of the station only when this combination happend.
The basic NOK set is defined by following parameters: The way, how the set is detected:
operation.name.NOKSetWatch = None | Continuous | Separated
The count of NOK results in a set is adjustable by a parameter:
(int) operation.name.NOKSetLimit
If this basic settings is used for a tightening operation, the spindle is blocked whent the set is reached. When the spindle is blocked, it is necessary to unblock it with a barcode "Unblock tightening machine" (PLCUBTM)t. It unblocks a spindle ant sets a counter of NOK tightenings back to zero. So next NOK set of tightenings will block a spindle once again (and so on...).
Example 1 - Continuos set:
operation.Tightening_1.NOKSetWatch = Continuous
operation.Tightening_1.NOKSetLimit = 2
Tightening OK
Tightening OK
Tightening NOK
Tightening OK
Tightening NOK
Tightening OK
Tightening NOK
Tightening NOK -> Spindle is blocked
Example 2 - Discontinuos set:
operation.Tightening_1.NOKSetWatch = Separated
operation.Tightening_1.NOKSetLimit = 2
Tightening OK
Tightening OK
Tightening NOK
Tightening OK
Tightening NOK -> Spindle is blocked
Tightening OK
Tightening NOK
Tightening NOK -> Spindle is blocked
Extended NOK Sets
Automatic skip of operation
operation.Tightening_1.AutomaticSkip.NOKSetWatch = Continuous operation.Tightening_1.AutomaticSkip.NOKSetLimit = 2
When this NOK set is reached, the operation is being skipped (same as a usage of PLCABC... barcode). The requested operations are then missing on the product and this fact will be detected on an output check station.
Responsible confirmation
operation.Tightening_1.ResponsibleConfirmation.NOKSetWatch = Continuous operation.Tightening_1.ResponsibleConfirmation.NOKSetLimit = 2
When this NOK set is reached, the responsible confirmation (a scanning of authorized barcode) is required. More details are described here: Responsible confirmation
Buffered operations
Mainly for instrumental operations (like for example RFID reading) sometimes it is needed, that the operation is buffered, because its result is sent to CLEVER client before the product ID is scanned. It is possible to use the following parameters in a client configuration file:
operation.name.Buffer.Enabled = No | Yes | Always (int) operation.name.Buffer.Delay operation.name.Buffer.Overwrite = No | Yes
If the operation for the current product is finished, it can be buffered for the following product. If the current product is not yet completely finished, the value of a parameter ToleranceOverPlan is used as well.
If the parameter Buffer.Overwrite is set to "No" (default settings), the operation is buffered only once. An optional next input is taken like the normal attempt.
