Kernel configuration

From PlcWiki

(Difference between revisions)
Jump to: navigation, search
(PartDistribution.cfg)
(PartDistribution.cfg)
Line 19: Line 19:
  Condition Displayed OperationID Barcode(s)              [Sound] [ColorCodes]
  Condition Displayed OperationID Barcode(s)              [Sound] [ColorCodes]
   
   
-
  ''regex''    ''text''      ''3 chars''    ''text'' or <%regex:''regex''%> [sound@''sound_index''] [ColorCodes] [specKey@''specMap key'']
+
  ''regex''    ''text''      ''3 chars''    ''text'' or <%regex:''regex''%> [sound@''sound_index''] [ColorCodes] [specKey@''specMap_key'']
Fields in the record must be separated by tab.
Fields in the record must be separated by tab.
*Condition - Generally it contains a part number. More part numbers can be combined using logical operators "+" (AND) and "!" (NOT). Each part number is evaluated as regex.
*Condition - Generally it contains a part number. More part numbers can be combined using logical operators "+" (AND) and "!" (NOT). Each part number is evaluated as regex.

Revision as of 09:14, 14 April 2020

Contents

Kernel configuration file

The main configuration of the Kernel process is stored in the file /usr/local/plc/etc/plc_krnl_project.cfg.

Sending of backflush

The backflush data can be created either by the Kernel, or it can be prepared by a PMC data flow when the data are being received.

Kernel data

PMC data

# It is possible to backflush the product using the PMC dataflow. PMC will prepare the datafile                                                       
# in time when the data are received to Clever system and place it to the defined DirQueue. When                                                      
# the product assembly is finished, the Kernel crates the flag file and PMC DirQueue sends the                                                        
# datafile to JIS.                                                                                                                                    
#EndAssemPMCFlagDir = /usr/local/plc/var/pmc/backflushdirq                                                                                            
# The flag file can be created by a done operation as well.                                                                                           
DoneOperationPMCFlagDir.OC2 = /usr/local/plc/var/pmc/backflushdirq                                                                                    

PartDistribution.cfg

This configuration file defines how the part numbers received in the product data are distributed to the operations. The syntax of each record is the following:

Condition Displayed OperationID Barcode(s)              [Sound] [ColorCodes]

regex     text      3 chars     text or <%regex:regex%> [sound@sound_index] [ColorCodes] [specKey@specMap_key]

Fields in the record must be separated by tab.

  • Condition - Generally it contains a part number. More part numbers can be combined using logical operators "+" (AND) and "!" (NOT). Each part number is evaluated as regex.
  • Display - How the part number is displayed on the client screen
  • OperationID - for example AB1
  • Barcode - A barcode or its substring, which is scanned on the station. If more barcodes are specified here, they are separated by tab.
  • Sound - A sound index defines the sound played on a station when the product is started. The sounds are defined by a parameter operation.name.sound[sound_index]
  • ColorCodes - for PartCheck#Sequenced_display_of_part_numbers.

If we need more than one condition in PartDistribution and the side effect of the logical AND operator + would bother us (match of the condition with any prefix) then we need to use \b at the end of the condition.

Example:

BM51\b+3M5T                DLP RHD               TD2               f@YE              b@BU

If we didn't use \b, any car containing part 3M5T and any part starting with BM51 would match the condition. However the \b at the end of the first condition matches with a word (part) boundary in car definition only thus it matches just with the complete part BM51 not with a part that just begins with BM51 .

plan_project.cfg

This configuration file defines all workplaces and its operations on a main assembly line and preassembly branches.


Operation data scripts

It is possible to create bash scripts which are executed by special events. The location of these scripts is defined by the Kernel configuration parameter

OperationDataScriptsDir = "/usr/local/plc/bin/operation_data_scripts"

It is its default value.

These scripts are most often used for a centralized printing of labels or creating and/or sending of messages or reports.

Following three types of the scripts can be used:

  • Operation scripts
  • Workplace scripts
  • Special events scripts


Operation scripts

These scripts are executed when the operation sends its data to the kernel. The Client parameter

Operation.name.SendDataToKernel = Yes

is needed. The name of the script needs to be same like an operation ID (for example /usr/local/plc/bin/operation_data_scripts/AB3).

The script is executed with following parameters:

  1. Product ID
  2. Operation ID
  3. Operation data
  4. Result
  5. Sequence number


Workplace scripts

These scripts are executed when the product is completed on the workplace (when an operation XY0 is OK reported to the Kernel). Nothing is needed to specify in the Client configuration.

The script is executed with following parameters:

  1. Product ID
  2. Operation ID

The name of the script needs to be same like a workplace ID (for example /usr/local/plc/bin/operation_data_scripts/AB).


Control barcodes scripts

These scripts are triggered when control barcode is scanned on client. Kernel searches for scrips in this order:

  1. <WPID>.<Barcode>
  2. <Barcode>
  3. BARCODE

First one only is started.

Script gets these parameters:

WPID="$1"
Barcode="$2"
Worker="$3"
AuthorizedBy="$4"
IP="$5"
Port="$6"


Special events scripts

There are some special scripts, which are executed by following events:

Event Name of the script Note
Start of assembly START_OF_ASSEMBLY When the product ID is scanned first time on any workplace
End of assembly END_OF_ASSEMBLY When the assembly is finished. It means the product is either:
  • Completed on the workplace which ends the assembly
  • The following product(s) finished its assembly
  • The rework procedure had been commited and the following product(s) finished its assembly
Rework requested REWORK_REQUESTED When the code PLCSENDREW was used on any workplace
Rework finished REWORK_FINISHED When the rework procedure was committed on a rework station
Rework cancelled REWORK_CANCELLED When the code PLCRMREW was used on any workplace

The script is executed with following parameters:

  1. Product ID

Using of soft links

If the script has a general feature, it is useful to use just a soft link named like the operation and it can point to the real script.

Personal tools