From PlcWiki

Current revision as of 09:21, 19 February 2021

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 (quality conditions)

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 (quantity conditions)

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

Quantity conditions are evaluated in sequence and the last matching rule is used to set plan. A condition usually looks like this:

  <condition>: <plan>

<condition> is a substring that is searched in product definition, i.e. it doesn't have to be the whole JIS part but only a substring of a part. If the condition is empty, it matches with every product. Conditions can be negated by prepending the exclamation mark !.

Unlike PartDistribution, these conditions are not evaluated as regular expressions.

If you need to use a regular expression, use this syntax:

  @Regex(<condition>): <plan>

The entire product definition (TAB separated parts) is used to match the regex. Use \b to match part boundaries.

There is also a special condition @PartDistribution, if you use it then you don't have to specify plan, it will be set according to count of the parts generated by the PartDistribution rules:

  @PartDistribution:

Another special condition @PartDistributionX2 sets the plan to double the count of the parts generated by the PartDistribution rules. This is useful for part checks that also store the serial numbers.

If the plan value is specified as a substring of a JIS part, you can use @Value(<prefix>) to set the plan accordingly.

Example (for JIS part e.g. AirbagTightPlan-6):

  @Value(AirbagTightPlan-):

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"
			}
		}
	},
	"stockOut": {
		"566665": [
			{
				"partId": "AXS-50465-5",
				"quantity": 2
			},
			{
				"partId": "QWZ-435435",
				"quantity": 1
			}
		]
	},
	"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:

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:

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.