PartCheck

From PlcWiki

(Difference between revisions)
Jump to: navigation, search
m
 
(7 intermediate revisions not shown)
Line 1: Line 1:
Generally, this type of an operation checks if the scanned part is the correct one, which is requested for this product.
Generally, this type of an operation checks if the scanned part is the correct one, which is requested for this product.
 +
Anyway, the aim of that feature is a bit more: to control, to check and to document, if correct parts are assembled to the cockpit. The main focus is on the check feature, but other two functions are important as well.
 +
 +
There are some circumstances, needed to be followed because of an implementation in all customer plants (and all time when the software is implemented). These circumstances were taken in an attention when the basic design of the functionality was being developed and how it was originally requested by customers (1998-1999).
 +
 +
Generally:
 +
# '''The incoming data doesn’t need to contain exact part numbers of parts which are assembled to the products'''. Sometimes the call-off data are different than the part numbers like they are used in the assembly, sometimes the requested part number is given by a combination of the call-off data. This is the reason, why we use PartDistribution.cfg to convert the call-off data to the requested part numbers. If extended form of the communication JIS->Clever is used, this functionality is on the JIS side.
 +
# '''The barcode content on the parts doesn’t need to be the same like the part number of the part'''. Depends on the parts, depends on part suppliers, how the part type (i.e. part number) is encoded into the barcode. Even the same parts can have different barcodes depending on who is the supplier of this piece. So this is the reason, why we need the conversion between barcodes and part numbers.
 +
# '''When the product is scanned on the station, we have to display a clear information about the requested part'''. So the requested part number (using PartDistribution or extended JIS data) is displayed for the operator.
 +
# '''If the operator makes an OK part check, the information of the part number is stored into the database'''. So we have to convert the scanned barcode to the part number.
 +
# '''If the operator makes an NOK part check, the information of the part number needs to be stored into the database'''. Not the scanned barcode, but really the part number. Same on the screen, we display, which part number (incorrectly) was scanned. The barcode itself is not so important. This is the reason, why we make a conversion from the barcode to the part number, even the part check is incorrect.
 +
# '''The checking function of the part check, needs to check, if the assembled part is correct'''. Not if the scanned barcode is correct. So the Client converts the barcode to the part number and then it compares, if that part number matches to the requested part number. The following files are used for the conversion barcode -> part number:
 +
## plc_parts.OpID – because on the Client originally it was the only file containing this information (part number <-> barcode)
 +
## PartDistribution.cfg – it is used with newer Clients, as this file is synchronized with the Kernel master copy.
 +
# '''The system should be robust and redundant'''. So if some configuration information is missing, so if possible, we are trying to continue without it. So if the Client is not able to convert the scanned barcode to the part number, it compares the scanned barcode to the requested part number to evaluate the part check as well. It is the case, when the barcode configuration for the part is completely missing. There is no risk of a doing that, because if an incorrect part is scanned, the result will be “NOK”.
 +
== Mandatory parameters ==
== Mandatory parameters ==
*Operation.''name''.Type = PartCheck
*Operation.''name''.Type = PartCheck
Line 41: Line 56:
*Operation.''name''.SNStore = '''No''' | Yes
*Operation.''name''.SNStore = '''No''' | Yes
If this parameter is set to Yes, an operation stores two results from one scanning. The first one is the result of a part check and the second one is the whole scanned bar code as its serial number. The plan (in plan...cfg file) for such an operation should be set to 2.
If this parameter is set to Yes, an operation stores two results from one scanning. The first one is the result of a part check and the second one is the whole scanned bar code as its serial number. The plan (in plan...cfg file) for such an operation should be set to 2.
 +
*Operation.''name''.maxLastSNs = '''10000''' | 0
 +
If this parameter is set to 0, content of barcode will be stored but not duplicate SNs will be checked. If it is set to any value n > 0, then last n SNs will be checked for duplicate.
=Sequenced display of part numbers=
=Sequenced display of part numbers=
-
It is possible to display required part numbers for part check operations in the sequence window. So it shows to operator which part numbers will come in the following sequence of ptoducts. This feature is controlled by following parameters:
+
It is possible to display required part numbers for part check operations in the sequence window. So it shows to an operator which part numbers will come in the following sequence of products. This feature is controlled by following parameters:
*Operation.''name''.SequenceDisplay.Width = (int) Width
*Operation.''name''.SequenceDisplay.Width = (int) Width
*Operation.''name''.SequenceDisplay.RegExp = Regexp
*Operation.''name''.SequenceDisplay.RegExp = Regexp
Line 58: Line 75:
[[File:Client_scr2.jpg]]
[[File:Client_scr2.jpg]]
-
In case of ''PartNum'' ColorMode it is necessary to define the color for those part numbers for which you want to display them in color. In case of standard JIS communication, this information is stored in PartDistribution.cfg. In case of the extended communication it is defined in JIS system.
+
In case of ''PartNum'' ColorMode it is necessary to define the color for those part numbers for which you want to display them in color. In case of a standard JIS communication, this information is stored in PartDistribution.cfg. In case of the extended communication it is defined in JIS system.
  Here is an example of PartDistribution definition:
  Here is an example of PartDistribution definition:
  #==========================================================
  #==========================================================
Line 114: Line 131:
| b@WH
| b@WH
|}
|}
-
 
=Multipart mode=
=Multipart mode=
Line 124: Line 140:
The following picture shows the multipart mode for an operation X82:
The following picture shows the multipart mode for an operation X82:
[[File:multipart_mode.jpg]]
[[File:multipart_mode.jpg]]
 +
The operation was defined like the following:
The operation was defined like the following:
  operation.Check_GBX.Type = PartCheck
  operation.Check_GBX.Type = PartCheck
Line 138: Line 155:
  operation.Check_GBX.PartStart[0] = 0
  operation.Check_GBX.PartStart[0] = 0
  operation.Check_GBX.PartLength[0] = 8
  operation.Check_GBX.PartLength[0] = 8
 +
 +
=Compare two operations=
 +
Lets have a serial check PP3 and a serial check CP1 operations. It is possible to set a check on the operation CP1 to check that we scan the same barcode like on the PP3 operation. To do it you have to define:
 +
 +
In a plan configuration file set a path to a workplace data file for the workplace PP.
 +
 +
WorkplaceDataFile = /usr/local/plc/var/PP.wpdata
 +
 +
In an operation CP configuration you have to add a parameter "VerifiedOperation",
 +
 +
operation.SerialCheck_Plancha.VerifiedOperation = PP3
 +
 +
In an operation PP configuration you have to add a parameter "SendDataToKernel",
 +
 +
operation.PartCheck_Plancha_2.SendDataToKernel = Yes
 +
 +
 +
It is possible to compare operations locally too. In such case it is not necessary to send the data to the Kernel. We just need to set a parameter "LocalVerifiedOperation" for CP1
 +
 +
operation.SerialCheck_Plancha.LocalVerifiedOperation = 2
 +
 +
(2 is a local operation index).

Current revision as of 07:30, 13 February 2017

Generally, this type of an operation checks if the scanned part is the correct one, which is requested for this product. Anyway, the aim of that feature is a bit more: to control, to check and to document, if correct parts are assembled to the cockpit. The main focus is on the check feature, but other two functions are important as well.

There are some circumstances, needed to be followed because of an implementation in all customer plants (and all time when the software is implemented). These circumstances were taken in an attention when the basic design of the functionality was being developed and how it was originally requested by customers (1998-1999).

Generally:

  1. The incoming data doesn’t need to contain exact part numbers of parts which are assembled to the products. Sometimes the call-off data are different than the part numbers like they are used in the assembly, sometimes the requested part number is given by a combination of the call-off data. This is the reason, why we use PartDistribution.cfg to convert the call-off data to the requested part numbers. If extended form of the communication JIS->Clever is used, this functionality is on the JIS side.
  2. The barcode content on the parts doesn’t need to be the same like the part number of the part. Depends on the parts, depends on part suppliers, how the part type (i.e. part number) is encoded into the barcode. Even the same parts can have different barcodes depending on who is the supplier of this piece. So this is the reason, why we need the conversion between barcodes and part numbers.
  3. When the product is scanned on the station, we have to display a clear information about the requested part. So the requested part number (using PartDistribution or extended JIS data) is displayed for the operator.
  4. If the operator makes an OK part check, the information of the part number is stored into the database. So we have to convert the scanned barcode to the part number.
  5. If the operator makes an NOK part check, the information of the part number needs to be stored into the database. Not the scanned barcode, but really the part number. Same on the screen, we display, which part number (incorrectly) was scanned. The barcode itself is not so important. This is the reason, why we make a conversion from the barcode to the part number, even the part check is incorrect.
  6. The checking function of the part check, needs to check, if the assembled part is correct. Not if the scanned barcode is correct. So the Client converts the barcode to the part number and then it compares, if that part number matches to the requested part number. The following files are used for the conversion barcode -> part number:
    1. plc_parts.OpID – because on the Client originally it was the only file containing this information (part number <-> barcode)
    2. PartDistribution.cfg – it is used with newer Clients, as this file is synchronized with the Kernel master copy.
  7. The system should be robust and redundant. So if some configuration information is missing, so if possible, we are trying to continue without it. So if the Client is not able to convert the scanned barcode to the part number, it compares the scanned barcode to the requested part number to evaluate the part check as well. It is the case, when the barcode configuration for the part is completely missing. There is no risk of a doing that, because if an incorrect part is scanned, the result will be “NOK”.

Contents

Mandatory parameters

  • Operation.name.Type = PartCheck
  • Operation.name.Index = (int) index

Other parameters

Bar code settings

  • Operation.name.SelectPattern[i] = Regexp
  • Operation.name.PartStart[i] = int
  • Operation.name.PartLength[i] = int

The above parameters define the bar codes belonging to that operation. The value of SelectPattern is a regular expression (regex) which assignes the scanned barcode to the operation. If they match, the bar code is assigned to the operation. The index of SelectPattern is used for a join between SelectPattern, PartStart and PartLength parameters. These parameters defines the substring of the scanned bar code which is compared with a requested bar code from PartDistribution.cfg table. For example if the secanned bar code matches a SelectPattern[0] parameter, then PartStart[0] and PartLength[0] are used. PartStart parameter points to the first character of the substring (its default value is 0, it means the beginning of the bar code). A parameter PartLength defines the length of of the substring (its default value is 0 and means "till the end of the bar code" otherwise its value define the length).

Example of the barcode definition:
operation.PartCheck_2.SelectPattern[0] = "^204# 1K.*$"
operation.PartCheck_2.PartStart[0] = 5
operation.PartCheck_2.PartLength[0] = 14
operation.PartCheck_2.SelectPattern[1] = ^204#1K.*$
operation.PartCheck_2.PartStart[1] = 4
operation.PartCheck_2.PartLength[1] = 14

PartDistribution record:
1K1614105CG     1K1 614 105 CG  T13     1K1614105CG

Scanned bar code:
204#1K1 614 105 CG#1#081 248 9474#11/10/10/41*204 3VZ10B0WRW1*=
matches SelectPattern[1], then PartStart[1] (4) and PartLength[1] (14)
will be used, it means the substring 1K1 614 105 CG will be compared
with 1K1614105CG (spaces are automatically erased before a comparing).
  • Operation.name.CheckSumType[i] = (int) CheckSumType
Possible values of CheckSumType:
0 - No check (default settings)
1 - SumEven + 3*SumOdd MOD 10
2 - SumEven + 3*SumOdd MOD 36
3 - Sum MOD 43 (Code39)
  • Operation.name.CheckSumSubString[i] = Regexp
It is possible to define the substring from the scanned bar code for the CheckSum test.
For example:
Operation.PartCheck_BrakeBau.CheckSumSubString[0] = ^.*\*(.*)\*.*$                                                                                            
Scanned barcode: 204#6R1 614 105 G##315313184#210510  *204 FTAC00BXGIG*=
Only the highlighted substring (204 FTAC00BXGIG) will be tested for the CheckSum
  • Operation.name.InvalidLabelAllowed = No | Yes
  • Operation.name.SNStore = No | Yes

If this parameter is set to Yes, an operation stores two results from one scanning. The first one is the result of a part check and the second one is the whole scanned bar code as its serial number. The plan (in plan...cfg file) for such an operation should be set to 2.

  • Operation.name.maxLastSNs = 10000 | 0

If this parameter is set to 0, content of barcode will be stored but not duplicate SNs will be checked. If it is set to any value n > 0, then last n SNs will be checked for duplicate.

Sequenced display of part numbers

It is possible to display required part numbers for part check operations in the sequence window. So it shows to an operator which part numbers will come in the following sequence of products. This feature is controlled by following parameters:

  • Operation.name.SequenceDisplay.Width = (int) Width
  • Operation.name.SequenceDisplay.RegExp = Regexp
  • Operation.name.SequenceDisplay.ColorMode = Periodical | PartNum

The following screen is a result of the following configuration:

operation.Scan_P1_Combine.SequenceDisplay.Width = 8
operation.Scan_P1_Combine.SequenceDisplay.RegExp = .*
operation.Scan_P1_Combine.SequenceDisplay.ColorMode = Periodical

operation.Scan_P1_CD.SequenceDisplay.Width = 8
operation.Scan_P1_CD.SequenceDisplay.RegExp = .*
operation.Scan_P1_CD.SequenceDisplay.ColorMode = PartNum

File:Client_scr2.jpg

In case of PartNum ColorMode it is necessary to define the color for those part numbers for which you want to display them in color. In case of a standard JIS communication, this information is stored in PartDistribution.cfg. In case of the extended communication it is defined in JIS system.

Here is an example of PartDistribution definition:
#==========================================================
#    HVAC    |
#-------------
# JIS           PLC             Op.     Barcodes   Colors
#----------------------------------------------------------

AH22 18C424 EB  AH22 18C424 EB  P11     443170446  f@WH
AH22 18C424 DB  AH22 18C424 DB  P11     443170445  f@RE
AH22 18C424 EC  AH22 18C424 EC  P11     443170446  f@YE b@RE
AH22 18C424 DC  AH22 18C424 DC  P11     443170445  f@YE b@GR
AH22 18C424 ED  AH22 18C424 ED  P11     443170446  f@GR
AH22 18C424 DD  AH22 18C424 DD  P11     443170445  b@BU

The default color is f@WH b@BK. It is not necessary to specify it. Then the part number will be displayed with a white font on a black background.

The following color codes are available:

Color Font code Backgroung code
black f@BK b@BK
red f@RE b@RE
green f@GR b@GR
yellow f@YE b@YE
blue f@BU b@BU
magenta f@MG b@MG
cyan f@CY b@CY
white f@WH b@WH

Multipart mode

The multipart mode is used when it is supposed to handle a large amount of part numbers (up to 100) within one operation. The complete list of requested part numbers is displayed in an operation window instead of a single part number. The following parameters define the multipart mode:

operation.name.MultiPartMode = No | Yes
operation.name.MultiPartColumnWidth

The parameter MultiPartColumnWidth defines the width of list columns in the operation window. The default value of this parameter is 11.

The following picture shows the multipart mode for an operation X82: File:multipart_mode.jpg

The operation was defined like the following:

operation.Check_GBX.Type = PartCheck
operation.Check_GBX.Index = 2
operation.Check_GBX.Default = 5
operation.Check_GBX.MultiPartMode = Yes
operation.Check_GBX.MultiPartColumnWidth = 13
operation.Check_GBX.WindowTitle = Scan GBX (Rij 18)
operation.Check_GBX.ToDoMessage = Scan GBX (Rij 18)
operation.Check_GBX.DependsOn = 4
operation.Check_GBX.ToleranceOverPlan = 0
#operation.Check_GBX.SNStore = No
operation.Check_GBX.SelectPattern[0] = ^\d{8}
operation.Check_GBX.PartStart[0] = 0
operation.Check_GBX.PartLength[0] = 8

Compare two operations

Lets have a serial check PP3 and a serial check CP1 operations. It is possible to set a check on the operation CP1 to check that we scan the same barcode like on the PP3 operation. To do it you have to define:

In a plan configuration file set a path to a workplace data file for the workplace PP.

WorkplaceDataFile = /usr/local/plc/var/PP.wpdata

In an operation CP configuration you have to add a parameter "VerifiedOperation",

operation.SerialCheck_Plancha.VerifiedOperation = PP3

In an operation PP configuration you have to add a parameter "SendDataToKernel",

operation.PartCheck_Plancha_2.SendDataToKernel = Yes


It is possible to compare operations locally too. In such case it is not necessary to send the data to the Kernel. We just need to set a parameter "LocalVerifiedOperation" for CP1

operation.SerialCheck_Plancha.LocalVerifiedOperation = 2

(2 is a local operation index).

Personal tools