View source

== (Automated start using RFID tags and smart watch confirmation) ==


Implementation documentation

 v. 1.2 - 2021-01-25

version note: Workplace tags implemented


== '''1. General description''' ==


The main purpose of the AutoStart feature is to start a product on a workplace without its scanning from a paper BoM, but using a smart watch for the confirmation, that an operator registered the new product and is going to work on it.
The product is registered on a workplace by a reading of an RFID tag by an RFID reader (antenna). When the tag is read, the CLEVER Client sends a notification to a smart watch and is waiting for the confirmation back. The product is announced to an operator on the smart watch display and by a smart watch vibration. The operator touches the smart watch to confirm his readiness. The smart watch sends a confirmation back to CLEVER Client and the product is started.


== '''2. Marriage workplace''' ==


In the very beginning of the assembly line, the marriage workplace needs to be configured. It assigns the RFID tag (mounted on each trolley) to the product (cockpit ID). That workplace is configured in a standard CLEVER Client.

'''See an important alternative mentioned at the end of this chapter.''' 

An operator scans the paper BoM to start the product (a standard feature). When the RFID tag is read by a reader, the tag ID is assigned to the started product. An operation “RFID reading” (type Serial) is needed there.

To avoid a situation, when the operator scans the product ID latter than the RFID tag comes to the reader, it is possible to buffer that operation. In that case the order of these events can be opposite. At first the tag is read (and its ID is buffered) and then the operator scans the product ID. The tag ID is taken from the buffer and assigned to the product.

'''Following parameters are important for the RFID reading (marriage) operation:'''


{| class="wikitable" border="1"  cellpadding="2"
! Parameter
! Value
|-
| Send Data To Kernel
| Yes
|-
| Buffer Enabled
|Yes
|-
| Tolerance Over Plan
| 0
|-
| Default quantity condition
| 1
|}


'''Example of the Clea settings of the marriage operation:'''

[[File:Screenshot_2021-01-27_11-43-15.png‎]]

[[File:Screenshot_2021-01-27_11-49-15.png]] '''IMPORTANT''': The marriage workplace plays an absolutely key role for the entire functionality of the AutoStart system. The 100% reliably working process here is absolutely needed. It is necessary to focus on that workplace from a very beginning of the implementation.'''

[[File:Screenshot_2021-01-27_11-49-46.png]] '''ALTERNATIVE''': Manual scanning of a trolley barcode instead of a RFID reading can be used for the marriage purpose as well. That way gives even a higher reliability of the marriage process. In that case, the barcode content needs to be a fixed prefix “RFID_” and then the tag RFID ID. For example “RFID_D6F92803”. The barcode format can be whichever alphanumeric code, like QR, Datamatrix, Cokde39,… '''



==''' 3. Settings for CLEVER Client '''==

CLEVER Client version required: 2101190928 or higher.

The driver RFID_IDENTCONTROL.drv is needed in the /usr/local/plc/etc/drivers folder.
It is possible to update each station to the latest Client version by the following command:

 yum update -y --disablerepo \* --enablerepo plc_client plc_client_bins plc_client_drivers plc_client_langs

Each workplace, which will use the AutoStart feature, needs to be configured according to following instructions. The workplaces are configured either individually, or using a workplace tags (described below).

=='''3.1. Workplace parameters'''==

1.
2.
3.
3.1
=='''3.1.1. Product ID'''==

This setting is specific for each plant and depends on a pattern of the product ID.  It needs to accept the RFID tag suffix:

{| class="wikitable" border="1"  cellpadding="2"
! Parameter
! Value
|-
| Product ID Select Pattern
| ^(<current settings>)(RFID_.+)?$
For example
^(3120[12]\d{9})(RFID_.+)?$
|-
|}





=='''3.1.2. Next Product'''==
In case the RFID tag comes to the reader earlier, then the previous product is finished, it is necessary to store the product id to a queue. The queued product ID is taken from the queue, when the previous product is finished. This is the moment, when the start signal is sent to the smart watch in this case.
Because the product ID needs to be queued only in case it is received from the RFID tag conversion, the queueing is defined on the RFID device:

 workplace.device.rfid_identcontrol.settings.NextProductID.Queued = true

If the product ID is scanned manually for an assembly sheet, it mustn’t be queued:


{| class="wikitable" border="1"  cellpadding="2"
! Parameter
! Value
|-
| Queue Next Product ID
| No
|-
|}


=='''3.1.3. Queued product timer'''==

This timer is started when the RFID tag is registered and the previous product is not yet finished. I.e. it starts when the product ID is queued and the Client is waiting for the operator to finish the previous product to send the start request to the smart watch (new-order-ready).

{| class="wikitable" border="1"  cellpadding="2"
! Parameter
! Value
|-
| Queued Product Timer Expiration
| 50
|-
| Queued Product Timer Expired Display Message 
| Examples:
*Use a hand scanner for the next cockpit
*Avisar a ACT, Verificar con el escáner de mano
*Pro další kokpit použijte ruční skener
|-
| Queued Product Timer Warning
| 10
|-
| Queued Product Timer Warning Display Message 
| Examples:
*You have last several seconds to finish
*Le quedan los últimos 10 segundos para validar la orden
*Máte posledních pár sekund na dokončení... 
|}


=='''3.1.4. Product start signal timer'''==

This timer is started, when the new-order-ready signal is sent to the smart watch. The client is waiting for the confirmation signal from the smart watch.

{| class="wikitable" border="1"  cellpadding="2"
! Parameter
! Value
|-
| Product Start Signal Timer Expiration
| 50
|-
| Product Start Signal Timer Expired Display Message
| Examples:
*Use a hand scanner for the next cockpit
*Avisar a ACT, Verificar con el escáner de mano
*Pro další kokpit použijte ruční skener
|-
| Product Start Signal Timer Warning
| 10
|-
| Product Start Signal Timer Warning Display Message 
| Examples:
*You have last several seconds to confirm
*Le quedan los últimos 10 segundos para validar la orden
*Máte posledních pár sekund na potvrzení... 
|}



=='''3.1.5. Example of a configuration in Clea:'''==



[[File:Screenshot_2021-01-27_14-05-17.png]]



=='''3.2.Usage of workplace tags'''==


This is a new feature in Clea. Clea version required: 164.210124.14S or higher.
The workplace tags provide a possibility to define the workplace parameters just once for a group of workplaces. In our case the workplaces on the main assembly line, which will use the AutoStart option, will be the group.

Each workplace can have one or more workplace tags. The tags are indicated in a bottom of the workplace box in Clea:  


[[File:Screenshot_2021-01-27_14-11-44.png‎ ]]


To assign the tag to a workplace, click to the maintenance tool icon [[File:Screenshot_2021-01-27_14-13-36.png]]. You will open a dialog:


[[File:Screenshot_2021-01-27_14-16-03.png]]

By the checkbox, you can assign/unassign the tag to the station.
If you click to the tag code [[File:Screenshot_2021-01-27_14-18-04.png]] , you can define the tag parameters. The parameters are accessible from tag code directly on the workplace box as well. See a screenshot on a following page:


[[File:Screenshot 2021-01-27 14-24-08.png]]


=='''3.3. Settings of Client devices'''==

(application CLEVER Client settings on terminals in Clea):


[[File:Screenshot 2021-01-27 14-27-37.png]]

The devices need to be defined for each station individually.


=='''4. Client events sent to smart watch'''==

When and what is sent to the Aucobo system (smart watch):


[[File:Screenshot 2021-01-27 14-43-59.png]]

=='''5. Settings for CLEVER Kernel'''==

CLEVER Kernel version required: 2101190929 or higher

=='''5.1. Client output data register'''==

It is necessary to register Client output data events. This registration will create event files to the defined PMC dirQ.
The Client output data register is configured internally by a Clever administrator.
File: /usr/local/plc/etc/client_output_data_register/aucobo

Content:

 /usr/local/plc/var/pmc/krnl2aucobo_dirq:^(requestProductStartSignal|productQueued|timerExpired)$

=='''6. PMC dataflow'''==

=='''6.1. Clever [[File:Screenshot 2021-01-27 14-50-45.png]] Aucobo'''==

Client output data are transformed by a PMC mustache module to Aucobo format and sent to Aucobo REST interface. 

 
[[File:Screenshot_2021-01-27_14-52-49.png‎]]


Configuration of PMC dataflow is done internally by a Clever administrator.
For the settings, Clever administrator needs to know:
*IP address of the Aucobo server
*Login credentials for Aucobo REST interface

=='''6.2. Aucobo [[File:Screenshot 2021-01-27 14-50-45.png]] Clever'''==

The confirmation signal is received by a Clever REST interface and stored to a PMC dirq. Then it is forwarded to the Kernel.
Configuration of PMC dataflow is done internally by a Clever administrator.

[[File:Screenshot_2021-01-27_15-02-40.png]]

=='''7. Clever REST interface'''==

The Clever REST interface is installed and configured internally by a Clever administrator.

=='''8. Trolley database'''==

It is possible to define colors for the trolleys. The trolley color is sent to the smart watch, so the operator is able to recognize on which trolley the announced product is placed. If same colors follow each other, then the smart watch confirmation is disabled and it is necessary to use the hand scanner. It avoids a misleading of the operator to handle an incorrect trolley (product).
The trolley database is available in Clea:

[[File:Screenshot_2021-01-27_15-07-13.png]]

Clea version required: 163.200911.10S or higher