Operation definition

From PlcWiki

(Difference between revisions)
Jump to: navigation, search
(→Responsible confirmation)
 
(19 intermediate revisions not shown)
Line 1: Line 1:
-
Each operation needs to be defined by its index and type. All other parameters are optional, but some of them are necessary for an valuable operation definition:
+
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''.Type = <Operation type>
Line 15: Line 15:
  LastWPCheck
  LastWPCheck
  Serial
  Serial
-
  PartCheck
+
  [[PartCheck]]
  PartCode
  PartCode
-
  CableCheck
+
  [[CableCheck (Poka-Yoke Check)]]
-
  Tightening
+
  [[Tightening]]
  VisualCheck
  VisualCheck
  OutputCheckCorrection
  OutputCheckCorrection
  OutputCheck
  OutputCheck
  PidWrite
  PidWrite
-
  ixpioSignal
+
  [[InputSignal]]
  VisionSensor
  VisionSensor
  PreSequence
  PreSequence
  Measurement
  Measurement
-
  RackPartCheck
+
  [[RackPartCheck]]
  BlindAudit
  BlindAudit
  SerialInput
  SerialInput
 +
[[DataCheck]]
== Operation parameters ==
== 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
-
(bool)Operation.''name''.'''SendConveyorStopWhenNOk'''
+
==Automatic sent to rework==
 +
The product can be sent automatically to a rework procedure using this parameter:
 +
(bool) Operation.''name''.'''SendToReworkWhenNOk''' = '''No''' | Yes
-
(bool)Operation.''name''.'''SendToReworkWhenNOk'''
+
==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.
 +
 
 +
==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.

Current revision as of 12:36, 18 April 2019

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.

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.

Retrieved from "https://plcwiki.clever.cz/index.php/Operation_definition"
Personal tools