MTS

https//www.racom.eu/eng/support/protocols_docum/mpgbc170a_mts.html

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]:

  1. only the regular transmissions of the current status take place every [link check period]
  2. an extra transmission is done whenever a change of any input value is detected (i.e. including values of analog inputs)
  3. an extra transmission is done after a change of any of the digital inputs
  4. 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

  1. frequency counter (only specific MTS versions), counts to 255, in MTS074/4 version the lower byte of counter to 65535 fc2
  2. 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.

©  2024 RACOM s.r.o. All Rights Reserved.