34 KiB
34 KiB
WORD version: !03-VM/45 - HENKEL - VM Auto Changeover/adjuntos/Vetro_communication_v0.2.docx
Concepts:
!03-VM/45 - HENKEL - VM Auto Changeover/adjuntos/Vetro AUTEFA Communication Alpla BG IBSS_V3.pptx
Map: !03-VM/45 - HENKEL - VM Auto Changeover/adjuntos/Changeover process map v1.xlsx
Prod: !03-VM/45 - HENKEL - VM Auto Changeover/adjuntos/AlplaProd_Articles - VM.xlsx
Functional Description
Project: Alpla Bowling Green UK IBSS
Vetro interface Communications FDS
Order No: A3015032
DRAFT V0.2 – not binding
# 1. Abbreviations
| | |
|---|---|
|Abbreviation|Meaning|
|M/C|Machine No.|
|PLC|Programmable Logic Controller|
|TLO|Tray Loader Outfeed|
|LST|Loading Station|
|ULST|Unloading Station|
# 2. History and comments
| | | | |
|---|---|---|---|
|Date|Author|Version|Changed|
|2020-01-08|OSW|0.0|Initial Draft|
|2020-01-15|OSW|0.1|Small modifications after meeting with Vetro in Friedberg|
|2020-02-24|OSW|0.2|Product types added, Export Line PLC added|
|||||
|||||
|||||
|||||
|||||
# 1. Production Setup and VETRO Communication The master HMI (Human machine interface), located near the tray loaders is used to setup the different tray loaders as well as to view the production targets, current status, storage capacity, fault messages etc. ## 1.1. Production targets and Line selection TLO21,22, 23, 24, 25, 26, 27, 28 are individually controlled by their own PLC’s. The Safety PLC on the filler side (SCO) is communication with each trayloader VETRO PLC’s will establish the TCP socket connection (=active connection establishment) I.e. VETRO PLC = client, AUTEFA PLC = server
The production targets are provided by Alpla[OU(1] in batches. These targets are received by AUTEFA via VETRO. At the start of production and every time the target for any line is changed by ALPLA, VETRO will send this target production information (Tg 010) to AUTEFA system. This information is also displayed on the HMI. For each line a separate telegram is used and consist of the following information - Active batch target - Active batch bottle type - Next batch target A provision is provided on the screen to manually enter the batch targets. The information about bottles already unloaded will be displayed for each product giving a clear idea about the production status at that point of time. For all telegrams which are triggered by the VETRO line PLC’s: It is expected that the telegram is sent from that VETRO line PLC’s that controls this line. This corresponds to the “Filling line” number in the telegram data content. E.g. a telegram Tg010 for line 1 is expected to arrive from the VETRO line PLC of line 1 and must contain “1” in the telegram data field “Filling line”. ## 1.2. Tray loader assignment Each tray loader can be assigned to any of the five or six lines of the multilane table (depending on left or right side) and various bottle types. Initially this setup has to be done by the operator in the tray loader setup screen. In the drop down boxes the list is provided and the required product / line are to be selected. The selection however will not take effect immediately. This information is sent to VETRO via Tg 020. Only if the conditions on the filler lines etc. are ok, a confirmation is sent back and then the changes take effect. From the tray loader side even before a request is sent the following two conditions should be fulfilled. - The loading area must be free i.e. the any stack in the tray loader should be in fully assembled condition. - The robot grippers must be open. (Possibility of old type of bottles when gripper closed) The selection will then remain valid till it is again necessary to change the product/line for that tray loader.
## 1.3. End of batch The batch target from VETRO is a floating target after compensating for the bottles that are taken out between the tray loader and filler for any reason. Every time the robot drops bottle on the filler line, either from the trays or from the blow moulder conveyors the bottles dropped are counted. Before a new tray is unloaded, this count is proved. Only if all bottles of the new tray are within that floating target, unloading is continued. Otherwise a telegram (Tg030) is sent to VETRO to inform end of batch. The purpose here is not to over-supply the filler with bottles. If there is a next batch target available, the tray loader can automatically take next batch as actual batch and continue to unload. OR VETRO can send a telegram Tg050 to confirm that next batch is now actual batch (optional) In absence of next batch target, the tray loader will assume end of production and switch to loading mode if blow moulder is running.
# 2. Telegram Definition: AUTEFA <-> VETRO Ethernet Communication ## 2.1. Overview This document describes the implementation of the telegram exchange between AUTEFA PLCs and the VETRO bottle conveyor system for the following kind of telegram transfer: The data transfer between the AUTEFA PLCs and the VETRO-system will be implemented using standard Ethernet TCP / IP “socket” communication protocol. Telegram length is always 100bytes due to requirements on VETRO side (Allen Bradley PLC, T_COMM blocks). ### 2.1.1. General Concepts of the AUTEFA Telegram Exchange Standard The following general concepts have to be followed within the AUTEFA standard: - Both sides can initiate a telegram transfer. Every data telegram will be answered by an acknowledge telegram. ## 2.2. Telegram Overview For each standard telegram the Telegram structure is defined as: |#|byte|type|Description| |---|---|---|---| |0|40|Message_header|PLC header (defined in chapter 2.4)| |---|---|---|---| |40|nnn||Data area: each telegram has a different structure and size.| |---|---|---|---|
For example: Tg005_Life_Counter_Info | | | | | |---|---|---|---| |#|byte|type|Description| |0|40|Message_header|PLC header| |40|2|INT 1|Counter value from 3 to 32527| The sending telegram has a structured data area. Tg006_Life_Counter_Info_Ack | | | | | |---|---|---|---| |#|byte|type|Description| |0|40|Message_header|PLC header| |40|2|INT 1|Counter value from 3 to 32527| The responding telegram has a structured data area. For project specific telegrams, the data areas for requesting telegram and acknowledge telegram must be defined. ## 2.3. Definitions ### 2.3.1. Telegram communication Each data telegram sent has to be answered by a reply telegram from the receiving station (receiver) for acknowledgement of the transmission and, as far as necessary, for sending the requested reply data. A reply telegram has the same “PLC header” (see below) as the send telegram, only the ‘response telegram type number’ will be ‘send telegram type number’ + 1 and the error field can have an error information. ### 2.3.2. Telegram timing/error conventions A message is not completed until the corresponding positive reply telegram is received. Therefore, no action, which depends on the telegram reply, may be started, before the positive answer telegram has been received. The meaning of the error numbers has to be defined. In case of an error number in a telegram, the both stations shall display - the error number and - a corresponding error text at the operator display. The receiver shall send a reply telegram within typically ca. 100 milliseconds. In case of a timeout - typically 10 seconds - at the sending station (sender) waiting for a reply telegram from the receiver, the sender will repeat the exact same telegram again and again. After 3 times repeating the same telegram, an error message will be shown at the operator stations. The telegram will be repeated until a positive reply telegram is received or an abortion by operator or program control is carried out. In repeated telegrams the telegram header shall not be changed (also no timestamp change). ### 2.3.3. Repeated Telegram Sending Stability The receiver must be able to receive and process the same telegram contents for the same physical transaction more than 1 time (repeated telegram send stability). Such a repeated sending of the same telegram content must not lead to data confusion within the receiver and must be replied with an “OK” reply telegram, as far as the telegram content is logically error free. ### 2.3.4. Data Formats and Format Conversions Notes concerning data formats and format conversions: - All data is transmitted exclusively in WORD or DOUBLE WORD format.
Any floating point number data is transmitted as ‘mantissa adapted’ WORD integer format. - The WORD items are aligned to WORD boundary. - The DOUBLE WORD items are aligned to DOUBLE WORD boundary (multiple of 4). If additional items of type word must be added, do not change that alignment, but rather add two words if necessary. - Any needed conversion of data format, as for example Least-Significant-Bit / Most-Significant-Bit (LSB / MSB) conversions, swap of bytes within WORDs or DOUBLE WORDs will be done at the VETRO side. ## 2.4. Telegram Headers and their Usage A telegram and the reply telegram consist of different parts: - the Ethernet TCP / IP “socket” header (frame), - the message header and - the telegram content data. The Ethernet TCP / IP “socket” header is built by the PLC firmware. The message header and the telegram content data are built by the AUTEFA and VETRO application software, respectively. ### 2.4.1. Ethernet TCP / IP “socket” header and socket connection usage For the specification / explanation and the usage of Ethernet TCP / IP “socket” telegrams refer to separate standard documentations, e.g. the international standardization documents, the book “TCP/IP Illustrated, Volume 1, The Protocols” by W. R. Stevens. Both communication partner sides must be able to dynamically “reactivate” a broken socket connection by automatically establishing a new socket connection as soon as needed. This automatic reactivation must operate even in the case of an ‘unreported’ break down of a socket connection (unreported: no socket connection ‘close’ information is given). The AUTEFA PLC is client and is trying to reconnect to the TCP/IP-Socket-Server automatically once the connection has been closed. For each pair of communication partners such a socket connection has to be established. ### 2.4.2. Message header |Byte-Offset|Length (Bytes)|Type|Name|Description| |---|---|---|---|---| |0|2|word|message_length|Length of the complete transmission in bytes| |2|2|word|endian_format|Always number 4321 (decimal).
If receiver gets something else, another endian (little/big endian) format must be assumed and the receiver has to swap bytes accordingly| |4|2|word|telegram_number|telegram number| |6|2|word|task|1 = execute telegram service,
3 = reinitialize telegram service,
4 = ping telegram service| |8|4|dword|error_number|error number (only used in reply)| |12|16|8 x word|send_client_ID|Client ID of sending PLC (same in response):
type, floor, area, sub_area,
row, sub_row, layer, sub_layer| |28|12|6 x word|timestamp|transmission time:
year, month, day, hour, minute, second| The format of the integer values for transmission is defined as standard net order, i.e. big endian. That means, that the byte order according to byte significance from low address to high is most significant byte first, i.e. transmission of hex4321 for a number hex4321. (Note: Other possible byte orders are little endian hex1234, e.g. on Intel or DEC Alpha, or PDP endian, i.e. hex3412). Note: The double word items are aligned to double word boundary (multiple of 4). If additional items of type word must be added, do not change that alignment, but rather add two words if necessary. The complete length is fixed to 100 bytes in all telegrams. Unused data is filled with zeros. The message header is used to specify - the telegram number - status / error codes - a “virtual” client identifier of the sending PLC client - the telegram transmission sends timestamp. The receiver must mirror - the telegram number + 1, - the client id and - the transmission time stamp of the message header when sending a reply telegram. This mirroring is needed to correctly identify and assign each reply telegram to the corresponding send telegram. The sender must always check the message header of the reply telegram for correspondence (identity) with the sending telegram, to avoid any confusion with reply telegrams of earlier sent telegrams.
Remark: error numbers in header are not used here in the telegrams between VETRO and AUTEFA #### 2.4.2.1 Client ID Each - machine or - transport unit or - passive storage location is identified with a so called client ID that is unique within a plant. The client ID’s are used to define positions for the machines or transport units or storage locations. The client ID’s are used - within the telegram header to identify the physical unit for which the telegram was sent and - within the telegram content to identify transport sources and targets. A PLC, which controls several machine units may send telegram using several client ID’s – one client ID for each machine. All operations are referred to these client ID’s.
The client id structure is always the same in all telegram s and has a total length of 16 bytes. The standard structure of a client id is as follows: | | | | |---|---|---| |Length|Type|Description| |2|word|sending unit: type| |2|word|sending unit: floor| |2|word|sending unit: area| |2|word|sending unit: sub area| |2|word|sending unit: row| |2|word|sending unit: sub row| |2|word|sending unit: layer| |2|word|sending unit: sub layer| A client id example: [201 / 1 / 1 / 0 / 1 / 0 / 0 / 0].
#### 2.4.2.2 Client ID’s for Alpla Bowling Green project 1> Client ID’s for telegrams sent by VETRO PLC’s | | | | | | |---|---|---|---|---| |Len|type|Description|Sending unit|Id| |2|word|sending unit: type|VETRO PLC|92| |2|word|sending unit: floor|Not used|1| |2|word|sending unit: area|Not used|1| |2|word|sending unit: sub area||0 = VETRO Master
10 = Filler line 0
11 =Filler line 1
12 =Filler line 2
13 =Filler line 3
14 =Filler line 4
15 =Filler line 5
16 =Filler line 6
24 =Export line 24| |2|word|sending unit: row|Not used|0| |2|word|sending unit: sub row|Not used|0| |2|word|sending unit: layer|Not used|0| |2|word|sending unit: sub layer|Not used|0| Example: Client ID of VETRO Conveyor Line 3 PLC: [92 / 1 / 1 / 13 / 0 / 0 / 0 / 0].[OU(2]
2> Client ID’s for telegrams sent by AUTEFA master PLC | | | | | | | |---|---|---|---|---|---| |Len||type|Description|Sending unit|id| |2||word|sending unit: type|AUTEFA MASTER|91| |2||word|sending unit: floor|Not used|1| |2||word|sending unit: area|Not used|1| |2||word|sending unit: sub area|Not used|0| |2||word|sending unit: row|Not used|0| |2||word|sending unit: sub row|Not used|0| |2||word|sending unit: layer|Not used|0| |2||word|sending unit: sub layer|Not used|0| Example: Client ID of SCO [91 / 1 / 1 / 0 / 0 / 0 / 0 / 0].[OU(3]
## 2.5. Telegram - Detailed Description for TG100-TG101 ### 2.5.1. Tg100_Request Info Time (VETRO à AUTEFA) - Agreed that we do not use Tg100 /101 between AUTEFA / VETRO as VETRO also uses a network time server ### 2.5.2. Tg101_ Info Time (AUTEFA à VETRO) Tg101 not used – see above
## 2.6. Telegram - Detailed Description for TG005-TG006 ### 2.6.1. Tg005_Life_Counter_Info (VETRO à AUTEFA) Trigger: - Telegram to be sent by VETRO at pre-determined regular interval in seconds. Output Functions: - To check live connection between AUTEFA & VETRO. - Life counter is increased by 1 VETRO side till it reaches value of 32527 and then reset to value 3, from where it continues further increments again. |#|Byte|Data|Format|Comment| |---|---|---|---|---| |0|40|HEADER|Message_header|See: definition “message header”| |40|2|Life Counter Value|INT 1|Counter value from 3 to 32527| |42||||telegram length in bytes| ### 2.6.2. Tg006_Life_Counter_Info_Ack (AUTEFA à VETRO) · Telegram to be sent by AUTEFA to acknowledge the reception of a Tg005_Life_Counter_Info. - The received life counter is increased by 1 AUTEFA side till it reaches value of 32527 and then reset to value 3, from where it continues further increments again. |#|Byte|Data|Format|Comment| |---|---|---|---|---| |0|40|HEADER|Message_header|See: definition “message header”| |40|2|Life Counter Value|INT 1|Counter value from 3 to 32527| |42||||telegram length in bytes| ## 2.7. Telegram - Detailed Description for TG010-TG011 ### 2.7.1. Tg010_Production_Info (VETRO à AUTEFA) Trigger: - Telegram to be sent by VETRO at beginning of production OR Every time, target for any product is changed OR When product changed on a line. For each production line individual Tg010 will be sent. Output Functions: - AUTEFA to check/compare which TL is assigned to that line + product and transfer the information to that TL. |#|Byte|Data|Format|Comment| |---|---|---|---|---| |0|40|HEADER|Message_header|See: definition “message header”| |40|2|Filling line|INT 1|selected filling line number
11 to 16 (line 1 =11; line 6 =16)| |42|2|Batch number Line|INT|Batch number line
11 to 16, 24 (line 1 =11; line 6 =16; export line = 24)| |44|2|Batch number|INT|Batch number
(value from 10 to 32700)| |46|2|Active_Batch_Target_1000|INT 1|active batch target - 1000's
Target number of bottles for actual batch (thousands)
0 for option to end batch| |48|2|Active_Batch_Target_Units|INT 1|active batch target - Units
Target number of bottles for actual batch (units)
0 for option to end batch| |50|2|Active_Batch_Bottle_Type|INT 1|active batch bottle code
bottle code:
refer to 2.7.2.1
0 for option to end batch| |52|2|Next Batch number Line|INT|Next Batch number line
11 to 16, 24 (line 1 =11; line 6 =16, export line =24)| |54|2|Next Batch number|INT|Next Batch number
(value from 10 to 32700)
VETRO will send “0” only| |56|2|Next_Batch_Target_1000|INT 1|next batch target - 1000's
Target number of bottles for next batch (thousands)| |58|2|Next_Batch_Target_Units|INT 1|next batch target - Units
Target number of bottles for next batch (units)| |60|2|Next_Batch_Bottle_Type|INT 1|next batch bottle code
bottle code:
active batch bottle code
bottle code:| |62|2|Next Batch +1 number Line|INT|Next Batch +1 number line
11 to 16, 24 (line 1 =11; line 6 =16, export line =24)| |64|2|Next Batch +1 number|INT|Next Batch number
(value from 10 to 32700)
VETRO will send “0” only| |66|2|Next_Batch+ 1_ Target_1000|INT 1|next batch+1 target - 1000's
Target number of bottles for next batch (thousands)| |68|2|Next_Batch+1 _Target_Units|INT 1|next batch +1 target - Units
Target number of bottles for next batch (units)| |70|2|Next_Batch+1_Bottle_Type|INT 1|next batch +1 bottle code
bottle code:
refer to 2.7.2.1| |72||||telegram length in bytes| Batch numbering was split from previous DINT into two INT formats: 1st INT show Line for VETRO batch number 2nd INT is created / incremented by VETRO (per line) using numbers 10 to 32700 (then jumping back to 10): At “Next Batch number” and “Next Batch+1 number” VETRO will send “0” only. Therefore, for Database purpose AUTEFA could use 1 to 9 here as dummy numbers (per line) as these are not used in the batch number counting loop.
Option, to be chosen by VETRO / ALPLA project team (instead of Tg30 from AUTEFA): A special Tg10 from VETRO could also initiate the end of a batch: For this purpose VETRO has to send 0 in Active_Batch_Target_1000, Active_Batch_Target_Units and Active_Batch_Bottle_Type While Filling line, Batch number Line and Batch number still need to represent the batch which should be ended.
### 2.7.2. Tg011_Production_Info_Ack (AUTEFA à VETRO) · Telegram to be sent by AUTEFA to acknowledge the reception of a Tg010_Production_Info. - If there has been a product change and no TL has been assigned to that line then error code will be sent in Tg 11 |#|Byte|Data|Format|Comment| |---|---|---|---|---| |0|40|HEADER|Message_header|See: definition “message header”| |40||||telegram length in bytes| #### 2.7.2.1 Bottle definitions
nn in Bottle type defines the colour code (see below) | | | | |---|---|---| |Bottle type|name|Screen| |99|empty|E| |1nn|H13|H13| |2nn|H14|H14| |3nn|H15|H15| |4nn|SP12|SP12| |5nn|SP01|SP01| |6nn|SP02|SP02| |7nn|SP05|SP05| |8nn|SP14|SP14| |9nn|SP17|SP17| |10nn|SP26|SP26| |11nn|H96|H96| |12nn|Harmony Futura LF 04B|LF04| |13nn|Harmony Futura LF 10B|LF10| |14nn|Beluga 197 oz|BEL| #### 2.7.2.2 Color definitions | | | | |---|---|---| |Color|name|Screen| |01|4% Yellow w/ White Liner|| |02|H13all Blue|| |03|Bee Sting Yellow|| |04|Blue|| |05|Blue 85|| |06|Dark Blue|| |07|Electrasol Orange|| |08|Gain Green|| |09|Green|| |10|HDU Green|| |11|HEB Green|| |12|Kirkland Pearl Blue|| |13|Lavender 2583C|| |14|Mountain Green|| |15|Opacity Orange w/liner|| |16|Orange|| |17|Pearl Blue|| |18|Pearl Green|| |19|Pearl Red|| |20|Pure Blue|| |21|Purple|| |22|Red|| |23|Silver|| |24|Suavitel Blue|| |25|Suavitel Green (2%)|| |26|Sunlight Yellow|| |27|White|| |28|Wisk Red||
## 2.8. Telegram - Detailed Description for TG020-TG021 ### 2.8.1. Tg020_Request_Change_Prod_Line (AUTEFA à VETRO) Telegram to be sent by AUTEFA to request a change of product / line relation for a particular tray loader. Only after confirmation from VETRO the change will be affected. For each tray loader individual Tg020 will be sent. Trigger: When a new product has been assigned for the filling line by the operator. OR a new TL has been automatically / manually assigned an existing product in case of failure in originally selected TL. AUTEFA also sends a Tg20 after a bottle import from multilane was requested (Tg80) and a tray loader is assigned. Output functions: With Tg 21 confirmation VETRO will get ready to accept these bottles on the particular line.
|#|Byte|Data|Format|Comment| |---|---|---|---|---| |0|40|HEADER|Message_header|See: definition “message header”| |40|2|Filling_Line|INT 1|selected filling line number
11 to 16 (line 1 =11; line 6 =16)| |42|2|Tray_Loader|INT 1|related tray loader
21 = TLO 21
22 = TLO 22
23 = TLO 23
24 = TLO 24
25 = TLO 25
26 = TLO 26
27 = TLO 27
28 = TLO 28| |44|2|Bottle_Type|INT 1|bottle code:
*| |46||||telegram length in bytes|
### 2.8.2. Tg021_Confirm_Change_Prod_Line (VETRO à AUTEFA) Telegram to be sent by VETRO to confirm the changeover of product / line relation. |#|Byte|Data|Format|Comment| |---|---|---|---|---| |0|40|HEADER|Message_header|See: definition “message header”| |40|2|Accept|INT 1|Accept change
0 = not accepted
1 = accepted| |42|2|VETRO active tray loader|INT1|Tray loaders 21-28| |44|2|Error code|INT1|Error code
( 0 = no error)
1 = conveyors not in automatic
2 = bottle type mismatch
3 = no bottles required| |46||||telegram length in bytes|
## 2.9. Telegram - Detailed Description for TG030-TG031 ### 2.9.1. Tg030_End_Of_Batch (AUTEFA à VETRO) NOT TRIGGERED- see below To inform end of batch for particular product. AUTEFA to reset its unloading counter simultaneously. If target for next batch is not available and blow moulder conveyors are running TL will treat this as end of production and immediately switch to loading mode. Trigger: Event is described in chapter 1.3 Option, to be chosen by VETRO / ALPLA project team: Instead of AUTEFA sending a Tg30 to end a certain batch, we could hand over the batch end control to VETRO to use a certain Tg10.
Refer to Tg10!
AUTEFA could support both versions.
AUTEFA and VETRO will keep the structure for Tg30/31 in PLC program to keep the option for ending a batch by Tg30 still open. Output functions: VETRO to trigger Tg50 if next batch is required otherwise TL can go into loading mode if blow moulder is running. | # | Byte | Data | Format | Comment | |-----------------------------------|--------------|-------------------|------------------------------|----------------------------------| | 0 | 40 | HEADER | Message_header | See: definition “message header” | | 40 | | 2 | Filling_Line | INT 1 | selected filling line number | | 11 to 16 (line 1 =11; line 6 =16) | | 42 | 2 | Batch number Line | INT | Batch number line | | 11 to 16 (line 1 =11; line 6 =16) | | 44 | 2 | Batch number | INT | Batch number | | (value from 10 to 32700) | | 46 | 2 | Bottle_Type | INT 1 | bottle code: | | | | ****** to be clarified ****** | | | | | | 48 | 2 | Tray_Loader | INT 1 | related tray loader | | Tray loaders 21-28 | | 50 | | | | telegram length in bytes | Batch numbering format changed – refer to Tg010.
### 2.9.2. Tg031_Ack_End_Of_Batch (VETRO à AUTEFA) Telegram to be sent by VETRO to confirm the reception of Tg030. |#|Byte|Data|Format|Comment| |---|---|---|---|---| |0|40|HEADER|Message_header|See: definition “message header”| |40||||telegram length in bytes|
## 2.10. Telegram - Detailed Description for TG040-TG041 ### 2.10.1. Tg040_Line_Speed_Update (VETRO à AUTEFA) Line Speed updates, depending on filler speed and VETRO conveyor speeds. For each production line, individual Tg040 will be sent. Trigger: VETRO to trigger Tg 040 when change in speed is required for any of the filling lines depending on filler running speed. Output function: Depending on this signal, AUTEFA to use corresponding speed and acceleration and deceleration values, ramps for the robots and TL tray conveyor etc. Low speed signal and no ready signal to drop bottles from filling line + blow moulder conveyor ready to pick means TL to go into loading mode. |#|Byte|Data|Format|Comment| |---|---|---|---|---| |0|40|HEADER|Message_header|See: definition “message header”| |40|2|Filling_Line|INT 1|selected filling line number
11 to 16 (line 1 =11; line 6 =16)| |42||Line_Speed|INT1|selected line speed
Values from 0 to 100 in steps of 10| |||||telegram length in bytes|
### 2.10.2. Tg041_Ack_ Line_Speed_Update (AUTEFA à VETRO) Telegram to be sent by AUTEFA to confirm the reception of Tg040. |#|Byte|Data|Format|Comment| |---|---|---|---|---| |0|40|HEADER|Message_header|See: definition “message header”| |40||||telegram length in bytes|
## 2.11. Telegram - Detailed Description for TG050-TG051 ### 2.11.1. Tg050_Activate_Batch (VETRO à AUTEFA) To inform next batch is actual batch. Trigger: In response to Tg030. Output function: AUTEFA to move counter of next batch to current batch & start unloading. | # | Byte | Data | Format | Comment | | ----------------------------------- | ------------ | ---------- | ---------------------------- | -------------------------------- | | 0 | 40 | HEADER | Message_header | See: definition “message header” | | 40 | | | | | | 2 | Filling_Line | INT 1 | selected filling line number | | | 11 to 16 (line 1 =11; line 6 =16) | | | | | | 42 | | Line_Speed | INT1 | selected line speed | | Values from 0 to 100 in steps of 10 | | | | | | | | | | telegram length in bytes | Batch numbering format changed – refer to Tg010.
### 2.11.2. Tg051_Ack_ Activate_Batch (AUTEFA à VETRO) Telegram to be sent by AUTEFA to confirm the reception of Tg050. |#|Byte|Data|Format|Comment| |---|---|---|---|---| |0|40|HEADER|Message_header|See: definition “message header”| |40||||telegram length in bytes| ## 2.12. Telegram - Detailed Description for TG060-TG061 ### 2.12.1. Tg060_Request_Bottles_Unloaded (VETRO à AUTEFA) Request number of bottles unloaded Trigger: VETRO could request any time status is required for a particular filling line. | # | Byte | Data | Format | Comment | |-------------------------------------------|------|-------------------|----------------|----------------------------------| | 0 | 40 | HEADER | Message_header | See: definition “message header” | | 40 | 2 | Filling_Line | INT 1 | selected filling line number | | 11 to 16 (line 1 =11; line 1 =16, bagger) | | 42 | 2 | Batch number Line | INT | Batch number line | | 11 to 16 (line 1 =11; line 6 =16) | | 44 | 2 | Batch number | INT | Batch number | | (value from 10 to 32700) | | 46 | | | | Telegram length in bytes | Batch numbering format changed – refer to Tg010.
### 2.12.2. Tg061_Bottles_Unloaded (AUTEFA à VETRO) Telegram to be sent by AUTEFA to confirm the reception of Tg060 and transmit the number of unloaded bottles of the active batch. | # | Byte | Data | Format | Comment | |---------------------------------------------------------|----------------------------|-----------------------------|---------------------------------|----------------------------------| | 0 | 40 | HEADER | Message_header | See: definition “message header” | | 40 | | 2 | Active_Batch_Unloaded_1000 | INT 1 | active batch unloaded - 1000's | | unloaded number of bottles for actual batch (thousands) | | 42 | 2 | Active_Batch_Unloaded_Units | INT 1 | active batch unloaded - Units | | unloaded number of bottles for actual batch (units) | | 44 | 2 | Filling_Line | INT 1 | selected filling line number | | 11 to 16 (line 1 =11; line 6 =16) | | | | | | | | 46 | 2 | Batch number Line | INT | Batch number line | | 11 to 16 (line 1 =11; line 6 =16, bagger) | | 48 | 2 | Batch number | INT | Batch number | | (value from 10 to 32700) | | 50 | | | | telegram length in bytes | Batch numbering format changed – refer to Tg010. 2020-01-14: osw Number of bottles unloaded minus ejected bottles at BT1 / 2.
# 1. Production Setup and VETRO Communication The master HMI (Human machine interface), located near the tray loaders is used to setup the different tray loaders as well as to view the production targets, current status, storage capacity, fault messages etc. ## 1.1. Production targets and Line selection TLO21,22, 23, 24, 25, 26, 27, 28 are individually controlled by their own PLC’s. The Safety PLC on the filler side (SCO) is communication with each trayloader VETRO PLC’s will establish the TCP socket connection (=active connection establishment) I.e. VETRO PLC = client, AUTEFA PLC = server
The production targets are provided by Alpla[OU(1] in batches. These targets are received by AUTEFA via VETRO. At the start of production and every time the target for any line is changed by ALPLA, VETRO will send this target production information (Tg 010) to AUTEFA system. This information is also displayed on the HMI. For each line a separate telegram is used and consist of the following information - Active batch target - Active batch bottle type - Next batch target A provision is provided on the screen to manually enter the batch targets. The information about bottles already unloaded will be displayed for each product giving a clear idea about the production status at that point of time. For all telegrams which are triggered by the VETRO line PLC’s: It is expected that the telegram is sent from that VETRO line PLC’s that controls this line. This corresponds to the “Filling line” number in the telegram data content. E.g. a telegram Tg010 for line 1 is expected to arrive from the VETRO line PLC of line 1 and must contain “1” in the telegram data field “Filling line”. ## 1.2. Tray loader assignment Each tray loader can be assigned to any of the five or six lines of the multilane table (depending on left or right side) and various bottle types. Initially this setup has to be done by the operator in the tray loader setup screen. In the drop down boxes the list is provided and the required product / line are to be selected. The selection however will not take effect immediately. This information is sent to VETRO via Tg 020. Only if the conditions on the filler lines etc. are ok, a confirmation is sent back and then the changes take effect. From the tray loader side even before a request is sent the following two conditions should be fulfilled. - The loading area must be free i.e. the any stack in the tray loader should be in fully assembled condition. - The robot grippers must be open. (Possibility of old type of bottles when gripper closed) The selection will then remain valid till it is again necessary to change the product/line for that tray loader.
## 1.3. End of batch The batch target from VETRO is a floating target after compensating for the bottles that are taken out between the tray loader and filler for any reason. Every time the robot drops bottle on the filler line, either from the trays or from the blow moulder conveyors the bottles dropped are counted. Before a new tray is unloaded, this count is proved. Only if all bottles of the new tray are within that floating target, unloading is continued. Otherwise a telegram (Tg030) is sent to VETRO to inform end of batch. The purpose here is not to over-supply the filler with bottles. If there is a next batch target available, the tray loader can automatically take next batch as actual batch and continue to unload. OR VETRO can send a telegram Tg050 to confirm that next batch is now actual batch (optional) In absence of next batch target, the tray loader will assume end of production and switch to loading mode if blow moulder is running.
# 2. Telegram Definition: AUTEFA <-> VETRO Ethernet Communication ## 2.1. Overview This document describes the implementation of the telegram exchange between AUTEFA PLCs and the VETRO bottle conveyor system for the following kind of telegram transfer: The data transfer between the AUTEFA PLCs and the VETRO-system will be implemented using standard Ethernet TCP / IP “socket” communication protocol. Telegram length is always 100bytes due to requirements on VETRO side (Allen Bradley PLC, T_COMM blocks). ### 2.1.1. General Concepts of the AUTEFA Telegram Exchange Standard The following general concepts have to be followed within the AUTEFA standard: - Both sides can initiate a telegram transfer. Every data telegram will be answered by an acknowledge telegram. ## 2.2. Telegram Overview For each standard telegram the Telegram structure is defined as: |#|byte|type|Description| |---|---|---|---| |0|40|Message_header|PLC header (defined in chapter 2.4)| |---|---|---|---| |40|nnn||Data area: each telegram has a different structure and size.| |---|---|---|---|
For example: Tg005_Life_Counter_Info | | | | | |---|---|---|---| |#|byte|type|Description| |0|40|Message_header|PLC header| |40|2|INT 1|Counter value from 3 to 32527| The sending telegram has a structured data area. Tg006_Life_Counter_Info_Ack | | | | | |---|---|---|---| |#|byte|type|Description| |0|40|Message_header|PLC header| |40|2|INT 1|Counter value from 3 to 32527| The responding telegram has a structured data area. For project specific telegrams, the data areas for requesting telegram and acknowledge telegram must be defined. ## 2.3. Definitions ### 2.3.1. Telegram communication Each data telegram sent has to be answered by a reply telegram from the receiving station (receiver) for acknowledgement of the transmission and, as far as necessary, for sending the requested reply data. A reply telegram has the same “PLC header” (see below) as the send telegram, only the ‘response telegram type number’ will be ‘send telegram type number’ + 1 and the error field can have an error information. ### 2.3.2. Telegram timing/error conventions A message is not completed until the corresponding positive reply telegram is received. Therefore, no action, which depends on the telegram reply, may be started, before the positive answer telegram has been received. The meaning of the error numbers has to be defined. In case of an error number in a telegram, the both stations shall display - the error number and - a corresponding error text at the operator display. The receiver shall send a reply telegram within typically ca. 100 milliseconds. In case of a timeout - typically 10 seconds - at the sending station (sender) waiting for a reply telegram from the receiver, the sender will repeat the exact same telegram again and again. After 3 times repeating the same telegram, an error message will be shown at the operator stations. The telegram will be repeated until a positive reply telegram is received or an abortion by operator or program control is carried out. In repeated telegrams the telegram header shall not be changed (also no timestamp change). ### 2.3.3. Repeated Telegram Sending Stability The receiver must be able to receive and process the same telegram contents for the same physical transaction more than 1 time (repeated telegram send stability). Such a repeated sending of the same telegram content must not lead to data confusion within the receiver and must be replied with an “OK” reply telegram, as far as the telegram content is logically error free. ### 2.3.4. Data Formats and Format Conversions Notes concerning data formats and format conversions: - All data is transmitted exclusively in WORD or DOUBLE WORD format.
Any floating point number data is transmitted as ‘mantissa adapted’ WORD integer format. - The WORD items are aligned to WORD boundary. - The DOUBLE WORD items are aligned to DOUBLE WORD boundary (multiple of 4). If additional items of type word must be added, do not change that alignment, but rather add two words if necessary. - Any needed conversion of data format, as for example Least-Significant-Bit / Most-Significant-Bit (LSB / MSB) conversions, swap of bytes within WORDs or DOUBLE WORDs will be done at the VETRO side. ## 2.4. Telegram Headers and their Usage A telegram and the reply telegram consist of different parts: - the Ethernet TCP / IP “socket” header (frame), - the message header and - the telegram content data. The Ethernet TCP / IP “socket” header is built by the PLC firmware. The message header and the telegram content data are built by the AUTEFA and VETRO application software, respectively. ### 2.4.1. Ethernet TCP / IP “socket” header and socket connection usage For the specification / explanation and the usage of Ethernet TCP / IP “socket” telegrams refer to separate standard documentations, e.g. the international standardization documents, the book “TCP/IP Illustrated, Volume 1, The Protocols” by W. R. Stevens. Both communication partner sides must be able to dynamically “reactivate” a broken socket connection by automatically establishing a new socket connection as soon as needed. This automatic reactivation must operate even in the case of an ‘unreported’ break down of a socket connection (unreported: no socket connection ‘close’ information is given). The AUTEFA PLC is client and is trying to reconnect to the TCP/IP-Socket-Server automatically once the connection has been closed. For each pair of communication partners such a socket connection has to be established. ### 2.4.2. Message header |Byte-Offset|Length (Bytes)|Type|Name|Description| |---|---|---|---|---| |0|2|word|message_length|Length of the complete transmission in bytes| |2|2|word|endian_format|Always number 4321 (decimal).
If receiver gets something else, another endian (little/big endian) format must be assumed and the receiver has to swap bytes accordingly| |4|2|word|telegram_number|telegram number| |6|2|word|task|1 = execute telegram service,
3 = reinitialize telegram service,
4 = ping telegram service| |8|4|dword|error_number|error number (only used in reply)| |12|16|8 x word|send_client_ID|Client ID of sending PLC (same in response):
type, floor, area, sub_area,
row, sub_row, layer, sub_layer| |28|12|6 x word|timestamp|transmission time:
year, month, day, hour, minute, second| The format of the integer values for transmission is defined as standard net order, i.e. big endian. That means, that the byte order according to byte significance from low address to high is most significant byte first, i.e. transmission of hex4321 for a number hex4321. (Note: Other possible byte orders are little endian hex1234, e.g. on Intel or DEC Alpha, or PDP endian, i.e. hex3412). Note: The double word items are aligned to double word boundary (multiple of 4). If additional items of type word must be added, do not change that alignment, but rather add two words if necessary. The complete length is fixed to 100 bytes in all telegrams. Unused data is filled with zeros. The message header is used to specify - the telegram number - status / error codes - a “virtual” client identifier of the sending PLC client - the telegram transmission sends timestamp. The receiver must mirror - the telegram number + 1, - the client id and - the transmission time stamp of the message header when sending a reply telegram. This mirroring is needed to correctly identify and assign each reply telegram to the corresponding send telegram. The sender must always check the message header of the reply telegram for correspondence (identity) with the sending telegram, to avoid any confusion with reply telegrams of earlier sent telegrams.
Remark: error numbers in header are not used here in the telegrams between VETRO and AUTEFA #### 2.4.2.1 Client ID Each - machine or - transport unit or - passive storage location is identified with a so called client ID that is unique within a plant. The client ID’s are used to define positions for the machines or transport units or storage locations. The client ID’s are used - within the telegram header to identify the physical unit for which the telegram was sent and - within the telegram content to identify transport sources and targets. A PLC, which controls several machine units may send telegram using several client ID’s – one client ID for each machine. All operations are referred to these client ID’s.
The client id structure is always the same in all telegram s and has a total length of 16 bytes. The standard structure of a client id is as follows: | | | | |---|---|---| |Length|Type|Description| |2|word|sending unit: type| |2|word|sending unit: floor| |2|word|sending unit: area| |2|word|sending unit: sub area| |2|word|sending unit: row| |2|word|sending unit: sub row| |2|word|sending unit: layer| |2|word|sending unit: sub layer| A client id example: [201 / 1 / 1 / 0 / 1 / 0 / 0 / 0].
#### 2.4.2.2 Client ID’s for Alpla Bowling Green project 1> Client ID’s for telegrams sent by VETRO PLC’s | | | | | | |---|---|---|---|---| |Len|type|Description|Sending unit|Id| |2|word|sending unit: type|VETRO PLC|92| |2|word|sending unit: floor|Not used|1| |2|word|sending unit: area|Not used|1| |2|word|sending unit: sub area||0 = VETRO Master
10 = Filler line 0
11 =Filler line 1
12 =Filler line 2
13 =Filler line 3
14 =Filler line 4
15 =Filler line 5
16 =Filler line 6
24 =Export line 24| |2|word|sending unit: row|Not used|0| |2|word|sending unit: sub row|Not used|0| |2|word|sending unit: layer|Not used|0| |2|word|sending unit: sub layer|Not used|0| Example: Client ID of VETRO Conveyor Line 3 PLC: [92 / 1 / 1 / 13 / 0 / 0 / 0 / 0].[OU(2]
2> Client ID’s for telegrams sent by AUTEFA master PLC | | | | | | | |---|---|---|---|---|---| |Len||type|Description|Sending unit|id| |2||word|sending unit: type|AUTEFA MASTER|91| |2||word|sending unit: floor|Not used|1| |2||word|sending unit: area|Not used|1| |2||word|sending unit: sub area|Not used|0| |2||word|sending unit: row|Not used|0| |2||word|sending unit: sub row|Not used|0| |2||word|sending unit: layer|Not used|0| |2||word|sending unit: sub layer|Not used|0| Example: Client ID of SCO [91 / 1 / 1 / 0 / 0 / 0 / 0 / 0].[OU(3]
## 2.5. Telegram - Detailed Description for TG100-TG101 ### 2.5.1. Tg100_Request Info Time (VETRO à AUTEFA) - Agreed that we do not use Tg100 /101 between AUTEFA / VETRO as VETRO also uses a network time server ### 2.5.2. Tg101_ Info Time (AUTEFA à VETRO) Tg101 not used – see above
## 2.6. Telegram - Detailed Description for TG005-TG006 ### 2.6.1. Tg005_Life_Counter_Info (VETRO à AUTEFA) Trigger: - Telegram to be sent by VETRO at pre-determined regular interval in seconds. Output Functions: - To check live connection between AUTEFA & VETRO. - Life counter is increased by 1 VETRO side till it reaches value of 32527 and then reset to value 3, from where it continues further increments again. |#|Byte|Data|Format|Comment| |---|---|---|---|---| |0|40|HEADER|Message_header|See: definition “message header”| |40|2|Life Counter Value|INT 1|Counter value from 3 to 32527| |42||||telegram length in bytes| ### 2.6.2. Tg006_Life_Counter_Info_Ack (AUTEFA à VETRO) · Telegram to be sent by AUTEFA to acknowledge the reception of a Tg005_Life_Counter_Info. - The received life counter is increased by 1 AUTEFA side till it reaches value of 32527 and then reset to value 3, from where it continues further increments again. |#|Byte|Data|Format|Comment| |---|---|---|---|---| |0|40|HEADER|Message_header|See: definition “message header”| |40|2|Life Counter Value|INT 1|Counter value from 3 to 32527| |42||||telegram length in bytes| ## 2.7. Telegram - Detailed Description for TG010-TG011 ### 2.7.1. Tg010_Production_Info (VETRO à AUTEFA) Trigger: - Telegram to be sent by VETRO at beginning of production OR Every time, target for any product is changed OR When product changed on a line. For each production line individual Tg010 will be sent. Output Functions: - AUTEFA to check/compare which TL is assigned to that line + product and transfer the information to that TL. |#|Byte|Data|Format|Comment| |---|---|---|---|---| |0|40|HEADER|Message_header|See: definition “message header”| |40|2|Filling line|INT 1|selected filling line number
11 to 16 (line 1 =11; line 6 =16)| |42|2|Batch number Line|INT|Batch number line
11 to 16, 24 (line 1 =11; line 6 =16; export line = 24)| |44|2|Batch number|INT|Batch number
(value from 10 to 32700)| |46|2|Active_Batch_Target_1000|INT 1|active batch target - 1000's
Target number of bottles for actual batch (thousands)
0 for option to end batch| |48|2|Active_Batch_Target_Units|INT 1|active batch target - Units
Target number of bottles for actual batch (units)
0 for option to end batch| |50|2|Active_Batch_Bottle_Type|INT 1|active batch bottle code
bottle code:
refer to 2.7.2.1
0 for option to end batch| |52|2|Next Batch number Line|INT|Next Batch number line
11 to 16, 24 (line 1 =11; line 6 =16, export line =24)| |54|2|Next Batch number|INT|Next Batch number
(value from 10 to 32700)
VETRO will send “0” only| |56|2|Next_Batch_Target_1000|INT 1|next batch target - 1000's
Target number of bottles for next batch (thousands)| |58|2|Next_Batch_Target_Units|INT 1|next batch target - Units
Target number of bottles for next batch (units)| |60|2|Next_Batch_Bottle_Type|INT 1|next batch bottle code
bottle code:
active batch bottle code
bottle code:| |62|2|Next Batch +1 number Line|INT|Next Batch +1 number line
11 to 16, 24 (line 1 =11; line 6 =16, export line =24)| |64|2|Next Batch +1 number|INT|Next Batch number
(value from 10 to 32700)
VETRO will send “0” only| |66|2|Next_Batch+ 1_ Target_1000|INT 1|next batch+1 target - 1000's
Target number of bottles for next batch (thousands)| |68|2|Next_Batch+1 _Target_Units|INT 1|next batch +1 target - Units
Target number of bottles for next batch (units)| |70|2|Next_Batch+1_Bottle_Type|INT 1|next batch +1 bottle code
bottle code:
refer to 2.7.2.1| |72||||telegram length in bytes| Batch numbering was split from previous DINT into two INT formats: 1st INT show Line for VETRO batch number 2nd INT is created / incremented by VETRO (per line) using numbers 10 to 32700 (then jumping back to 10): At “Next Batch number” and “Next Batch+1 number” VETRO will send “0” only. Therefore, for Database purpose AUTEFA could use 1 to 9 here as dummy numbers (per line) as these are not used in the batch number counting loop.
Option, to be chosen by VETRO / ALPLA project team (instead of Tg30 from AUTEFA): A special Tg10 from VETRO could also initiate the end of a batch: For this purpose VETRO has to send 0 in Active_Batch_Target_1000, Active_Batch_Target_Units and Active_Batch_Bottle_Type While Filling line, Batch number Line and Batch number still need to represent the batch which should be ended.
### 2.7.2. Tg011_Production_Info_Ack (AUTEFA à VETRO) · Telegram to be sent by AUTEFA to acknowledge the reception of a Tg010_Production_Info. - If there has been a product change and no TL has been assigned to that line then error code will be sent in Tg 11 |#|Byte|Data|Format|Comment| |---|---|---|---|---| |0|40|HEADER|Message_header|See: definition “message header”| |40||||telegram length in bytes| #### 2.7.2.1 Bottle definitions
nn in Bottle type defines the colour code (see below) | | | | |---|---|---| |Bottle type|name|Screen| |99|empty|E| |1nn|H13|H13| |2nn|H14|H14| |3nn|H15|H15| |4nn|SP12|SP12| |5nn|SP01|SP01| |6nn|SP02|SP02| |7nn|SP05|SP05| |8nn|SP14|SP14| |9nn|SP17|SP17| |10nn|SP26|SP26| |11nn|H96|H96| |12nn|Harmony Futura LF 04B|LF04| |13nn|Harmony Futura LF 10B|LF10| |14nn|Beluga 197 oz|BEL| #### 2.7.2.2 Color definitions | | | | |---|---|---| |Color|name|Screen| |01|4% Yellow w/ White Liner|| |02|H13all Blue|| |03|Bee Sting Yellow|| |04|Blue|| |05|Blue 85|| |06|Dark Blue|| |07|Electrasol Orange|| |08|Gain Green|| |09|Green|| |10|HDU Green|| |11|HEB Green|| |12|Kirkland Pearl Blue|| |13|Lavender 2583C|| |14|Mountain Green|| |15|Opacity Orange w/liner|| |16|Orange|| |17|Pearl Blue|| |18|Pearl Green|| |19|Pearl Red|| |20|Pure Blue|| |21|Purple|| |22|Red|| |23|Silver|| |24|Suavitel Blue|| |25|Suavitel Green (2%)|| |26|Sunlight Yellow|| |27|White|| |28|Wisk Red||
## 2.8. Telegram - Detailed Description for TG020-TG021 ### 2.8.1. Tg020_Request_Change_Prod_Line (AUTEFA à VETRO) Telegram to be sent by AUTEFA to request a change of product / line relation for a particular tray loader. Only after confirmation from VETRO the change will be affected. For each tray loader individual Tg020 will be sent. Trigger: When a new product has been assigned for the filling line by the operator. OR a new TL has been automatically / manually assigned an existing product in case of failure in originally selected TL. AUTEFA also sends a Tg20 after a bottle import from multilane was requested (Tg80) and a tray loader is assigned. Output functions: With Tg 21 confirmation VETRO will get ready to accept these bottles on the particular line.
|#|Byte|Data|Format|Comment| |---|---|---|---|---| |0|40|HEADER|Message_header|See: definition “message header”| |40|2|Filling_Line|INT 1|selected filling line number
11 to 16 (line 1 =11; line 6 =16)| |42|2|Tray_Loader|INT 1|related tray loader
21 = TLO 21
22 = TLO 22
23 = TLO 23
24 = TLO 24
25 = TLO 25
26 = TLO 26
27 = TLO 27
28 = TLO 28| |44|2|Bottle_Type|INT 1|bottle code:
*| |46||||telegram length in bytes|
### 2.8.2. Tg021_Confirm_Change_Prod_Line (VETRO à AUTEFA) Telegram to be sent by VETRO to confirm the changeover of product / line relation. |#|Byte|Data|Format|Comment| |---|---|---|---|---| |0|40|HEADER|Message_header|See: definition “message header”| |40|2|Accept|INT 1|Accept change
0 = not accepted
1 = accepted| |42|2|VETRO active tray loader|INT1|Tray loaders 21-28| |44|2|Error code|INT1|Error code
( 0 = no error)
1 = conveyors not in automatic
2 = bottle type mismatch
3 = no bottles required| |46||||telegram length in bytes|
## 2.9. Telegram - Detailed Description for TG030-TG031 ### 2.9.1. Tg030_End_Of_Batch (AUTEFA à VETRO) NOT TRIGGERED- see below To inform end of batch for particular product. AUTEFA to reset its unloading counter simultaneously. If target for next batch is not available and blow moulder conveyors are running TL will treat this as end of production and immediately switch to loading mode. Trigger: Event is described in chapter 1.3 Option, to be chosen by VETRO / ALPLA project team: Instead of AUTEFA sending a Tg30 to end a certain batch, we could hand over the batch end control to VETRO to use a certain Tg10.
Refer to Tg10!
AUTEFA could support both versions.
AUTEFA and VETRO will keep the structure for Tg30/31 in PLC program to keep the option for ending a batch by Tg30 still open. Output functions: VETRO to trigger Tg50 if next batch is required otherwise TL can go into loading mode if blow moulder is running. | # | Byte | Data | Format | Comment | |-----------------------------------|--------------|-------------------|------------------------------|----------------------------------| | 0 | 40 | HEADER | Message_header | See: definition “message header” | | 40 | | 2 | Filling_Line | INT 1 | selected filling line number | | 11 to 16 (line 1 =11; line 6 =16) | | 42 | 2 | Batch number Line | INT | Batch number line | | 11 to 16 (line 1 =11; line 6 =16) | | 44 | 2 | Batch number | INT | Batch number | | (value from 10 to 32700) | | 46 | 2 | Bottle_Type | INT 1 | bottle code: | | | | ****** to be clarified ****** | | | | | | 48 | 2 | Tray_Loader | INT 1 | related tray loader | | Tray loaders 21-28 | | 50 | | | | telegram length in bytes | Batch numbering format changed – refer to Tg010.
### 2.9.2. Tg031_Ack_End_Of_Batch (VETRO à AUTEFA) Telegram to be sent by VETRO to confirm the reception of Tg030. |#|Byte|Data|Format|Comment| |---|---|---|---|---| |0|40|HEADER|Message_header|See: definition “message header”| |40||||telegram length in bytes|
## 2.10. Telegram - Detailed Description for TG040-TG041 ### 2.10.1. Tg040_Line_Speed_Update (VETRO à AUTEFA) Line Speed updates, depending on filler speed and VETRO conveyor speeds. For each production line, individual Tg040 will be sent. Trigger: VETRO to trigger Tg 040 when change in speed is required for any of the filling lines depending on filler running speed. Output function: Depending on this signal, AUTEFA to use corresponding speed and acceleration and deceleration values, ramps for the robots and TL tray conveyor etc. Low speed signal and no ready signal to drop bottles from filling line + blow moulder conveyor ready to pick means TL to go into loading mode. |#|Byte|Data|Format|Comment| |---|---|---|---|---| |0|40|HEADER|Message_header|See: definition “message header”| |40|2|Filling_Line|INT 1|selected filling line number
11 to 16 (line 1 =11; line 6 =16)| |42||Line_Speed|INT1|selected line speed
Values from 0 to 100 in steps of 10| |||||telegram length in bytes|
### 2.10.2. Tg041_Ack_ Line_Speed_Update (AUTEFA à VETRO) Telegram to be sent by AUTEFA to confirm the reception of Tg040. |#|Byte|Data|Format|Comment| |---|---|---|---|---| |0|40|HEADER|Message_header|See: definition “message header”| |40||||telegram length in bytes|
## 2.11. Telegram - Detailed Description for TG050-TG051 ### 2.11.1. Tg050_Activate_Batch (VETRO à AUTEFA) To inform next batch is actual batch. Trigger: In response to Tg030. Output function: AUTEFA to move counter of next batch to current batch & start unloading. | # | Byte | Data | Format | Comment | | ----------------------------------- | ------------ | ---------- | ---------------------------- | -------------------------------- | | 0 | 40 | HEADER | Message_header | See: definition “message header” | | 40 | | | | | | 2 | Filling_Line | INT 1 | selected filling line number | | | 11 to 16 (line 1 =11; line 6 =16) | | | | | | 42 | | Line_Speed | INT1 | selected line speed | | Values from 0 to 100 in steps of 10 | | | | | | | | | | telegram length in bytes | Batch numbering format changed – refer to Tg010.
### 2.11.2. Tg051_Ack_ Activate_Batch (AUTEFA à VETRO) Telegram to be sent by AUTEFA to confirm the reception of Tg050. |#|Byte|Data|Format|Comment| |---|---|---|---|---| |0|40|HEADER|Message_header|See: definition “message header”| |40||||telegram length in bytes| ## 2.12. Telegram - Detailed Description for TG060-TG061 ### 2.12.1. Tg060_Request_Bottles_Unloaded (VETRO à AUTEFA) Request number of bottles unloaded Trigger: VETRO could request any time status is required for a particular filling line. | # | Byte | Data | Format | Comment | |-------------------------------------------|------|-------------------|----------------|----------------------------------| | 0 | 40 | HEADER | Message_header | See: definition “message header” | | 40 | 2 | Filling_Line | INT 1 | selected filling line number | | 11 to 16 (line 1 =11; line 1 =16, bagger) | | 42 | 2 | Batch number Line | INT | Batch number line | | 11 to 16 (line 1 =11; line 6 =16) | | 44 | 2 | Batch number | INT | Batch number | | (value from 10 to 32700) | | 46 | | | | Telegram length in bytes | Batch numbering format changed – refer to Tg010.
### 2.12.2. Tg061_Bottles_Unloaded (AUTEFA à VETRO) Telegram to be sent by AUTEFA to confirm the reception of Tg060 and transmit the number of unloaded bottles of the active batch. | # | Byte | Data | Format | Comment | |---------------------------------------------------------|----------------------------|-----------------------------|---------------------------------|----------------------------------| | 0 | 40 | HEADER | Message_header | See: definition “message header” | | 40 | | 2 | Active_Batch_Unloaded_1000 | INT 1 | active batch unloaded - 1000's | | unloaded number of bottles for actual batch (thousands) | | 42 | 2 | Active_Batch_Unloaded_Units | INT 1 | active batch unloaded - Units | | unloaded number of bottles for actual batch (units) | | 44 | 2 | Filling_Line | INT 1 | selected filling line number | | 11 to 16 (line 1 =11; line 6 =16) | | | | | | | | 46 | 2 | Batch number Line | INT | Batch number line | | 11 to 16 (line 1 =11; line 6 =16, bagger) | | 48 | 2 | Batch number | INT | Batch number | | (value from 10 to 32700) | | 50 | | | | telegram length in bytes | Batch numbering format changed – refer to Tg010. 2020-01-14: osw Number of bottles unloaded minus ejected bottles at BT1 / 2.