1. Introduction
This documentation describes ways and formats of communication between the MTS protocol module (an access module for connecting one or more MTS units to the MORSE network) and the MTS074 unit(s) on one side, and between the MTS protocol module and any possible counterpart across the MORSE network on the other side. In the following paragraphs the MTS protocol module is supposed to run within hardware of any MCU, e.g. in MR25, so “MR25” substitutes for the “MTS protocol module”.
2. Data format
2.1. Communication Principles
(Words in brackets are [protocol parameters], see section 4.)
Communication with MTS units is carried out according to the master – slave method where MR25 is always the master and MTS074 units act as slaves. A total of 8 MTS074 units can be connected to one MR25 via the RS485 interface. The addresses of MTS units always start from address 0.
The MR25 permanently keeps the status of MTS units connected to it in its memory and after every [input refresh period] the status is updated. This status is dispatched to the [destination address] (i.e. MORSE network destination address) every [link check period]. In addition to these regular transmissions, the status can be transmitted when a status change is detected. A change of status that invokes transmission can be configured in protocol parameters.
There are four possible ways of status data transfer to the [destination address]:
- only the regular transmissions of the current status take place every [link check period]
- an extra transmission is done whenever a change of any input value is detected (i.e. including values of analog inputs)
- an extra transmission is done after a change of any of the digital inputs
- only regular transmissions take place, but when any of the digital inputs changes value during the respective [link check period], the changed value is remembered and it is transmitted in the next regular transmission instead of the actual value. After the transmission, the first set of input values received from MTS units is then considered as initial for the changes recorded during the next [link check period].
2.1.1. Communication with MTS units
The MR25 can request various services from MTS (see 2.2. for detailed description). This communication is always done according to a “request- report” pattern. In case the MR25 does not receive any response during [MTS timeout], the request is repeated according to the set [No of repeats]. When the number of repeats is spent, the respective error report is transmitted to the [destination address].
2.1.2. Communication across the MORSE network
Standard USER DATA packets are used, so the full MORSE network functionality can be exploited. Concrete data formats can be seen in section 2.3.
In accordance with the communication philosophy of independence in Morse networks any user of the network can communicate with any MTS protocol module and receive the status, or set the digital outputs, of MTS units connected to a remote MR25 regardless of other users activities.
The two most common examples of communication with MTS units through the MORSE network follow.
Direct MTS-MTS data transfer
This is the simplest application of two MTS units communicating mutually by means of the MTS protocol modules through the MORSE network. The status of digital inputs from one MTS unit is transferred to digital outputs of the other unit and vice versa. The outputs serve as a mirror of inputs of the opposite MCU. Their respondence is checked during each data transmission towards the opposite MCU. If there is any difference (the change on any input is indicated), then the frame containing the last state of inputs is sent back and the obsolete state of outputs is re-created.
Two equal groups of MTS’ (each containing from 1 to 8 MTS) communicate through the MORSE network in this way.
One of the digital outputs can be chosen as the alarm one – all eventual errors (lost packets in the network, errors in MR25-MTS communication at the remote side) are transferred to this output. The [destination address] in protocol parameters of the MTS protocol module has to be set to its counterpart address.
Data transfer from MTS units to a control centre
In this case the [destination address] for all MR25s with connected MTS shall be the address of the MORSE network where the control centre is connected. The MARS-A protocol access module is the recommended interface for connection of a control centre to the MORSE network. Nevertheless different protocols can be used, depending on the control centre software. Data formats described in section 2.3. are valid for the MARS-A protocol.
2.2. MR25-MTS Communication
A description of packet formats can be seen in the following four paragraphs. The meaning of individual bytes is described in paragraph 2.2.5.
2.2.1. READ ALL service ( MTS status read)
READ ALL MR25 -> MTS (with example) | A/4 | S/4 | dummy/8 | dummy/8 | dummy/8 | sec1/8 | sec2/8 | 0 1 AA AA AA FF 01 READ ALL MTS -> MR25 | A/4 | V/4 | Dout/8 | Din/8 | fc1(dummy)/8 | fc2(dummy)/8 | 0 5 00 FF 00 00 | Ain1/8 | Ain2/8 | Ain3/8 | Ain4/8 | Ain5/8 | Ain6/8 | Ain7/8 | Ain8/8 | 00 00 00 00 00 00 00 00 | dummy/8 | sec1/8 | sec2/8 | AA AE 52 An example of MR25 - MTS communication (service READ ALL): 18:18:14.41|tx1 6 01AA AAAA FF01 //service request MR25-> MTS, address 0, number of service 1 18:18:14.43|rx1 16 0500 FF00 0000 0000 0000 0000 00AA AE52 //service report MTS->MR25, address 0, MTS version 5, all digital outputs are set to log. 0, all digital inputs read log. 1, all analog inputs read 0 value(no signal connected)
2.2.2. WRITE TO OUT service (set MTS digital outputs)
WRITE TO OUT MR25 -> MTS (with example) | A/4 | S/4 | Dout/8 | dummy/8 | dummy/8 | sec1/8 | sec2/8 | 0 2 01 AA AA 57 A9 WRITE TO OUT MTS -> MR25 | A/4 | V/4 | ack/8 | sec1/8 | sec2/8 | 0 5 06 0B F5 An example of MR25 - MTS communication (WRITE TO OUT): 18:23:49.59|tx1 6 0201 AAAA 57A9 // service request MR25->MTS, address 0, number of service 2, digital outputs value 01hex 18:23:49.61|rx1 4 0506 0BF5 // service report MTS->MR25, address is 0, version 5, ACK (write confirmation)
2.2.3 WRITE REG RAM service (write to RAM register),
WRITE REG EEP service (write to EEPROM register) WRITE REG RAM, S=3 WRITE REG EEP, S=5 MR25 -> MTS (with example) | A/4 | S/4 | regaddr/8 | regvalue/8 | dummy/8 | sec1/8 | sec2/8 | 0 3 0B 05 AA BD 43 MTS -> MR25 | A/4 | V/4 | ack/8 | sec1/8 | sec2/8 | 0 5 06 0B F5 An example of MR25 - MTS communication (WRITE REG RAM): 18:23:49.59|tx1 6 030B 05AA BD43 //service request MR25->MTS, address 0, number of service 3,RAM register address 0xB, write value 0x5 18:23:49.61|rx1 4 0506 0BF5 //service report MTS->MR25, address 0, version 5, ACK
2.2.4. READ REG RAM service (RAM register read)
READ REG EEP service (EEPROM register read) READ REG RAM, S=4 READ REG EEP, S=6 MR25 -> MTS (with example) | A/4 | S/4 | regaddr/8 | dummy/8 | dummy/8 | sec1/8 | sec2/8 | 0 4 0B AA AA 63 9D MTS -> MR25 | A/4 | V/4 | regvalue/8 | sec1/8 | sec2/8 | 0 5 0A 0F F1 An example of MR25 - MTS communication (READ REG RAM, monitoring transcript): 18:23:49.59|tx1 6 040B AAAA 639D //service request MR25->MTS, address 0, number of service 4, RAM register address 0xB 18:23:49.61|rx1 4 050A 0FF1 //service report MTS->MR25, address 0, version 5, RAM register value 0x0D
2.2.5. Meaning of individual bytes in packets during MR25 – MTScommunication
SNumber of service (lower 4 bites), see paragraph 2.2.6.VMTS version (lower 4 bites), see par. 2.2.7.DoutDigital outputs (bits 0-7 corresponding to outputs REL 1 to REL.8)DinDigital inputs (bits 0-7 corresponding with inputs D IN 1- 8)fc1
- frequency counter (only specific MTS versions), counts to 255, in MTS074/4 version the lower byte of counter to 65535 fc2
- frequency counter (only specific MTS versions), counts to 255, in MTS074/4 version the higher byte of counter to 65535
Ain1..Ain8Analog inputsregadrRegister address in ram (eeprom)regvalueValue of the particular register in ram (eeprom)dummyFilling byte (0xAA)ackConfirmation of write services (0x06)sec1Checksum byte (sum of all previous bytes)sec2Checksum byte complement (0 – sec1)
A | MTS address (upper 4 bites) |
2.2.6. Service numbers (S)
Serv.No. Brief description of service Abbreviation
0x1 | complete MTS status read | REQ_R_ALL |
0x2 | Digital outputs write | REQ_W_OUT |
0x3 | RAM register write | REQ_W_REG |
0x4 | RAM register read | REQ_R_REG |
0x5 | EEPROM register write | REQ_W_EEP |
0x6 | EEPROM register read | REQ_R_EEP |
0x7 | Complete MTS status data (see 2.3.2.) | REP_R_ALL |
0x8 | RAM register data (see 2.3.2.) | REP_R_REG |
0x9 | EEPROM register data (see 2.3.2.) | REP_R_EEP |
2.2.7. MTS versions (V):
Version No. | MTS designation | MIO plate configuration | Brief description of MTS configuration |
---|---|---|---|
0x1 | MTS074/1 | MIO10 | 6x D IN, 6x D OUT |
0x2 | MTS074/2 | MIO20 | 2x D IN, 2x D OUT, 8x A IN |
0x3 | MTS074/3 | MIO30 | 8x D IN, 4x D OUT, 1x A IN |
0x4 | MTS074/4 | MIO40 | 6x D IN, 4x D OUT, 4x A IN, 1x fc |
0x5 | MTS074/5 | MIO50 | 8x D IN, 8x D OUT, 5x A IN |
2.3. MR25 – MR25 Communication across the MORSE network
Transmission of a MORSE packet (of USER DATA type) from the MTS protocol module to any destination within the MORSE network can be invoked in two basic ways:
A – On the MTS protocol module’s own initiative
Such packets are always sent to the [destination address] set in protocol parameters. See section 2.1. for communication principles, paragraph 2.3.1. for respective data formats.
B – On request of remote user of the MORSE network
A remote user can ask for any of the MTS services. The service report is then sent back to the remote user address. See paragraph 2.3.2. for request/report data formats.
2.3.1. Data format for case “A”:
CONTROL WORD MTS STRUCTURE | A/4 | X/4 | N/4 | S/4 | MTS_STRUCT | where: CONTROL WORD 4bit group Possible Brief description Abbreviation of control values Word A ....... 0x0 ... Reserved X ....... 0x1 ... Data are sent after regular ..C_CHECK_TIMEOUT expiry of [link check period] 0x2 ... When a RF_CHECK message comes,the ..C_CHECK_IN received digital input states are written to own MTS outputs. Then the received output states are compared with own digital inputs. In case of any difference, the C_CHECK_IN message is sent to the [destination address] 0x3 ... Data are sent when the change of ..C_CHECK_REFRESH MTS status was detected (immedia- tely after the refresh) N ....... 0x1 to Number of MTS units connected 0x8 to MR25 S ....... 0xE ... Following data contain complete ..RF_CHECK (Number of status of all MTS units behind service) MR25 from MTS with address 0, see C_CHECK_IN 0xD ... Data structure same as at 0xE ..RF_CHECK_ERR (RF_CHECK).The last status before loss of communication with MTS is transmitted For other values - see 2.2.6.Service numbers MTS_STRUCT | V/8 | Dout/8 | Din/8 | fc1(dummy)/8 | fc2(dummy)/8 | | Ain1/8 | Ain2/8 | Ain3/8 | Ain4/8 | Ain5/8 | Ain6/8 | Ain7/8 | Ain8/8 | | Dummy/8 | Meaning of individual bytes in MTS STRUCT: V MTS version Dout Digital outputs(bites 0-7 correspond with outputs REL1 to REL8) Din Digital inputs (bites 0-7 correspond with inputs D IN 1- 8) fc1 1. frequency counter (only MTS074/4, otherwise dummy) fc2 2. frequency counter (only MTS074/4, otherwise dummy) Ain1..Ain8 Analog inputs dummy Filling byte (0xAA)
Note: The individual MTS STRUCT data sections are ranked in sequence from address 0 and their number correspond to the set number of connected MTS units in protocol parameters (the number of MTS can be found in Control Word – see the previous description).
2.3.2. Data format for case “B”:
CONTROL WORD DATA | A/4 | X/4 | M/4 | S/4 | request/report data | where: CONTROL WORD 4bit group Possible Brief description of control values Word A ....... 0x0 ... Reserved X ....... 0x4 ... Request/report data (to distinguish case "B" packets from case "A") M ....... 0x0 till Address of MTS connected to MR25 0x7 S ....... Service number - see 2.2.6. DATA
The request/report data formats are exactly the same as in MR25 – MTS communication, only the checksum bytes (sec1 and sec2) are not transmitted. Description of these formats is in section 2.2.
3. Communication example
– the remote user asks for the value of RAM register 0x0B of the first MTS connected to the local MR25:
Direction of Packet Comment Communication remote-->MR25 0404 040B AAAA 1.byte 04: request data 2.byte 04: MTS address 0 service number 4 3.byte 04: MTS address and service number 4.byte 0B: RAM register address 5.and 6.byte AA AA: dummy MR25 ---> MTS 040B AAAA 639D 1.byte 04: MTS address 0 service number 4 2.byte 0B: RAM register address in MTS 3.and 4.byte AA AA: dummy 5.and 6.byte 63 9D: sec1 and sec 2 MTS --> MR25 0205 07F9 1.byte 02: MTS address 0 MTS version MTS 074/2 2.byte 05: RAM register content 3.and 4.byte 07 F9: sec1 and sec2 MR25-->remote 0404 0205 1.byte 04: report data 2.byte 04: MTS address 0 service number 4 3.byte 02: MTS address 0 MTS version 2 4.byte 05: RAM register content
4. MTS protocol parameters
Settings are valid for all MTS units connected to one MTS protocol module.
(a) destination address
Morse network address (from user address space) where all spontaneously generated packets are sent to, typically RF_CHECK and error messages.
(n) number of MTS units
number of MTS units connected to the MTS protocol module. The addresses of connected MTS units must start from zero. It means that when just one MTS unit is connected n=1 and the MTS unit address must be 0.
(t) MTS timeout
time in milliseconds the MR25 waits for MTS unit response. The recommended value is 80 ms.
(r) No of repeats
number of repeats. In case the MR25 does not receive any response from the MTS within the timeout (t), the transmission is repeated according to the set number of repeats. The recommended value is 3.
(i) input refresh period
(in milliseconds) After expiry of this period the MR25 requests REQ_R_ALL service from all connected MTS units starting from address 0. It means that every refresh period the complete MTS status image kept in MR25 memory is refreshed. This parameter value determines the dynamic behaviour of the whole system, so it has to be chosen carefully. The typical value is 500 ms. In case 0 is specified there is no refresh and the MTS protocol module communicates with MTS units connected only on request from a remote user.
(l) link check period
(in second) After expiry of this period the MR25 transmits the complete status of all connected MTS units to destination address (a) (message C_CHECK_TIMEOUT). The actual status is either current (after the last refresh) or according to the (x) setting. In case 0 is specified there is no regular transmission.
(e) error Word
specifies in the higher byte the MTS unit address (0-7) and in the lower byte the number of output (0-7) on which the error messages coming from a remote MTS will be displayed (the alarm output). The MORSE system error messages coming to the MTS protocol module are also displayed on this output.
The alarm output is reset to 0 when a regular packet from the remote address is received. ATTENTION ! As after the link period expiry in the remote MR25 the last valid MTS status is transmitted, even in case that the MTS unit does not respond any longer, the alarm output is reset after receiving that message. After expiry of the refresh period in the remote MR25 a new attempt to read from the defective MTS unit fails, the error message is transmitted and the alarm output is set again.
In case a non-existing MTS address is specified or specification of output number differs from 0-7, there is no output for error indication.
(x) tx after refresh
conditions for MTS status transmission when a status change is detected after refresh:
(0) | none | no change transmissions |
(1) | all | new transmission after any change of any input |
(2) | digi | new transmission after a digital input change |
(3) | delay | changes of digital inputs are stored and transmitted when the link period expires (see section 2. for details) |
(o) send error messages
Switches on/off (yes/no) transmission of error messages
A careful approach is recommended when setting the time periods. It is important to think of system behaviour in case of some failure, e.g. when some MTS unit fails to respond or “noisy” input values are read (this can result in new packet transmission after every refresh period). Incorrect settings of MTS protocol parameters can cause overloading of the whole network!
Example: by mistake a larger number of MTS units(n) is set than the number of units actually connected. Consequently after every refresh period the MR25 asks for the status from non-existing MTS addresses and after the number of repeats (r) is spent it transmits an error message to the destination address (a). As the refresh period is typically very short (200 ms), there will be only very little space left in the network RF channel for other data transfer …
5. Error messages
Whenever the MTS protocol module detects a failure in communication with the connected MTS unit(s), or receives a packet through the MORSE network with invalid data format, it generates an error message packet. When such an error occurs during processing of a request from a remote user, the error message is sent to a remote user address. In all other situations the error message is sent to the configured [destination address].
Error messages transmitted from a MTS protocol module are MORSE network packets of PROT DATA type, with the format described below. If an error message is received by another MTS protocol module, the configured alarm output (if any) of the connected MTS is set. Error messages received by a control centre (through e.g. MARS-A protocol) have to be processed by control centre software.
Error message data format:
| 0x00/8 | 0x01/8 | 0x00/8 | NR/8 |
control_word – to distinguish error messages from possible different messages sent by PROT DATA type packet
0x0001 | |
N | MTS address (0xF for all MTS connected to MR25) |
R | error number (see following table) |
Error numbers: >
Error No. | Brief description | Abbreviation |
---|---|---|
0x1 | MTS status read error (after refresh period expiry) | ERR_R_ALL |
0x2 | The data from MTS came in unexpected size | ERR_R_DATA_SIZE |
0x3 | Wrong data format in request packet coming from MORSE network | ERR_RF_IN_FORMAT |
0x4 | Write service error in MTS (MR25 did not received ACK) | ERR_WRITE |
0x5 | Service request with non existing MTS address | ERR_NUM |
0x6 | Service request with MTS version not corresponding with version of the MTS of specified address | ERR_VER |
0x7 | Request for unknown service | ERR_UNKN_SERVICE |
0x8 | Not used | ERR_OUT_NUM |
0x9 | Control word error (the lower byte contains contain 0x04 (C_DATA_REQ)) | ERR_C_WORD |
…If the MTS repeatedly does not answer after refresh period expiry, the error message is sent immediately after failure of the first attempt to read the MTS status after every [link check period] expiry (not after every [input refresh period] expiry). In such a case the last valid MTS status (message RF_CHECK_ERR, service 0xD) is sent after [link check period] expiry and it is immediately followed by the error message (error 0x1).
6. The most important RAM and EEPROM register addresses
Remote access to these registers is possible by appropriate services, see section 2. for service description.
Register name | RAM | EEPROM | Values |
---|---|---|---|
MTS_ADDRESS | 0x68 | 0x77 | 0x00 – 0x70 |
COUNTER_low_byte | 0x71 ( fc1) | – | 0x00 – 0xFF |
COUNTER_high_byte | 0x72 ( fc2) | – | 0x00 – 0xFF |
7.Other publications describing MTS074:
Description of MTS074 – service manual, hardware description and description of individual versions of MTS074.