Kernel configuration
From PlcWiki
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 .
The syntax of custom product color definition is as follows (_name_ is just an identifier, operation ID is ignored):
Condition ColorName OperationID Priority Foreground Background regex @ProductColor(_name_) 3 chars 0-100 fg color bg color
plan_project.cfg
This configuration file defines all workplaces and its operations on a main assembly line and preassembly branches.
specs.json
Additional structured specification that cannot fit into parts. The specification is located in the specMap record. There each operation has its own record. Inside the operation record there can be a record addressed by a part ID or a spec key. If none such record is present, $default record can be used.
Example:
{
"user": "martin.prokop@clever.cz",
"owner": "clever.cz",
"created": "2020-03-17T15:54:37.223+01:00",
"defaultLng": "cz",
"cleaUrl": "http://demo.clever.cz/clea/",
"specMap": {
"BB0": {
"$default": {
"$ref": "/specStore/visualCheck/BB0"
}
},
"A18": {
"21251": {
"$ref": "/specStore/visualCheck/A18_21251"
},
"$default": {
"$ref": "/specStore/visualCheck/A18"
}
}
}
"specStore": {
...
}
}
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:
- Product ID
- Operation ID
- Operation data
- Result
- 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:
- Product ID
- 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:
- <WPID>.<Barcode>
- <Barcode>
- 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:
|
| 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:
- 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.
