Modbus protocol for MORSE 0.1 Description of the Modbus Protocol 0.1.1 Overview of the Most Common Modbus Protocol Functions 1. Function of the Modem in the MODBUS protocol. - transparent mode - cache mode - packet mode - time synchronisation - watchdog - phantom access - virtual station 1.1 Modem as MASTER 1.1.1 Modem MASTER in cache mode 1.1.2 Modem MASTER in Transparent Mode 1.1.3 Modem MASTER in Packet Mode 1.1.4 Modem MASTER and Time Synchronisation 1.2 Modem as SLAVE 1.2.1 Modem SLAVE in Cache Mode 22.214.171.124 Phantom Access 126.96.36.199 Virtual station 1.2.2 Modem SLAVE in Transparent Mode 1.2.3 Modem SLAVE in Packet Mode 1.2.4 Modem SLAVE and Time Synchronisation 2. Parameters of the Modbus Protocol 3. Examples and Explanations 3.1. Packet type. 3.2 Example of Reading Data in Cache Mode. 3.3 Examples of Packet Mode. 3.4 Basic Modbus Communication. 3.5 Sending a Short User Packet from Master to Modbus. 3.6 Sending a short user packet from Slave to Modbus. 3.7 Sending a long user packet from Master to Modbus. 3.8 Sending a long user packet from Slave to Modbus. 3.10 Automaster sends Herman's broadcast. 4. History The MODBUS protocol in its standard format contains one Master and a group of Slaves connected by an RS485 bus network. There can be a maximum of 255 Slaves - single-byte address). The standard Modbus is also limited to a max. address of 247. The Master cyclically polls individual Slaves and reads data from them. Mingled in with this are commands which the Master inserts between requests as is necessary. Each frame from the Master is either duly confirmed or contains data corresponding to the function of the frame. On the basis of this simple principle the Master determines the aliveness, and also non-functionality of individual Slaves. The order for polling Slaves is not defined. The Master can arrange the polling list as it likes. The Master does not have its own address. Modbus network with RS485 bus: master slave PLC PLC ___ | | | addresses: ______ +-------------------|___| 01 | | | ___ | PLC |--------------+ | | |______| +-------------------|___| 02 | ___ |RS485 | | 03 +-------------------|___| | In the following diagram the Modbus network is connected by the MORSE radio network. Slave PLC's are connected separately or in groups to the MORSE CU (communication unit, modem, radio), which locally substitutes the function of the Master PLC: [A] [B] [C] [D] master slave master slave PLC CU CU PLC ______ \|/........... \|/ | |RS232 _|_ : _|_ ___ slave | PLC |-----| | : | | RS485 | | addresses: |______| |___| : |___|----+----|___| (0):01 (m)ode:SLAVE : (m)ode:MASTER| ___ FF 691122FF : 69112201 | | | : +----|___| (1):02 address : (d)est:FF :..... \|/ : _|_ ___ : | | RS485 | | (0):03 : |___|----+----|___| : 69112203 | ___ : | | | : +----|___| (1):04 :..... \|/ _|_ ___ | | RS232 | | |___|---------|___| (0):05 69112205 period m(i)rror (p)eriod The Modbus is interrupted by the inserted radio network which mediates the connection in the three modes described below. The diagram illustrates the use of the terms Master and Slave in the following definition. Symbols [A],[B],[C],[D] are used for distinguishing levels in the communication hierarchy. Even if CU [B] also behaves like a Master with respect to CU [C] in the radio network for transparency we avoid this kind of labelling. Symbols in brackets such as m(i)rror label protocol parameters. An example of addresses is also given. The address of the master PLC [A] is the same as the lower byte of the MORSE address of CU slave [B]. The lower byte of the address of CU master [C] is the same as one of the addresses of the connected PLC [D] Slaves. For routing other PLC´s the "multiaddressing" function in menu (N)odes (e)dit is used. 0.1 Description of the Modbus Protocol Modbus is a typical example of a family of protocols determined for buses implemented on RS485. It uses a 256 byte frame equipped with a 16-bit CRC. Because Modbus distinguishes the types of transmitted data (bit, byte, word), types of frames are established for distinguishing these variations. The Modbus type of frame is described by the number of the function implemented by the frame. 0.1.1 Overview of the Most Common Modbus Protocol Functions Overview of Modbus commands for reading and writing from various parts of the PLC memory. unit for: function/8 start/16 (hex) number/16 ___________ | | 02 1bit | OUT |-> 0F --> bits | |-> |___________|-> | Analog | 04 1word | | 03 words | Registers | 17 words | | |___________| Description of individual functions: - 01 (Read Output Status) Reads output states (relays, transistor switches, etc.) from the Slave. The basic unit read by means of this function is one output - for us this means one bit. Of course as the protocol is able to transfer one byte as the smallest element output bits are combined into bytes. The Master can address more bits at once. It then obtains them stacked into several bytes of the reply. Typical forms of frames then look as follows: request | adr/8 | fce/8 | start/16 | number/16 | crc/16 | reply | adr/8 | fce/8 | cnt/8 | data/8 * cnt | crc/16 | adr - address of PLC on Modbus, this address must be unique within the whole bus. The address is the same for a request as for a reply. fce - function, which the PLC performs after receiving the frame start - start address of data (output), which is to be processed number - number of items (bits), which are to be processed cnt - number of frame data bytes data - actual data of the request aligned into 8 bits crc - security word Example: If we have the state of outputs in our PLC from the zero address 0x1480. The PLC has an address on the Modbus of 0x10. Using the function 01 first we read everything at once and then the second part only. Request for the first case: 1001 0000 0010 crc - we want 16 outputs from the zero position reply: 1001 0214 80 crc - all 16 outputs returned. It is necessary to point out that data is not aligned into an even number of bytes as is common in MORSE networks. Request for the second case: 1001 0008 0008 crc - we want 8 outputs from the eighth position reply: 1001 0180 crc - 8 outputs returned. As is seen outputs are organised in Intel format (little endian). - 02 (Read Input Status) It is absolutely identical to the previous function, but it reads inputs from the Slave PLC. The form of frames are also the same. - 03 (Read Holding Registers) 16 bit memory registers return from the PLC. These registers are general purpose. In our case they are used for cache and packet mode. The frames then look as follows: request | adr/8 | fce/8 | start/16 | number/16 | crc/16 | reply | adr/8 | fce/8 | cnt/8 | data/8 * cnt | crc/16 | adr - address of the PLC on the Modbus fce - function, which the PLC performs after receiving the frame start - start address of data (output), which is to be processed number - number of items (words), which are to be processed cnt - number of frame data bytes data - content of required registers aligned into 16 bits crc - security word Example: In our PLC from the previous example the contents of three registers from the zero address are 0x1480, 0x3450 and 0x4054. request: 1003 0000 0003 crc reply: 1003 0614 8034 5040 54 crc - again the frame is not aligned into an even number of bytes. - 04 (Read Input Registers) In principle this is the same as the function for reading registers. The difference of course is that it returns the states of analog inputs. - 05 (Force Single Output) It sets one output, i.e. one bit. As the binary output can only be set or deleted the forms of commands are very simple. request | adr/8 | fce/8 | start/16 | 0xFF00 | crc/16 | for setting 1 output | adr/8 | fce/8 | start/16 | 0x0000 | crc/16 | for deleting 1 output reply | adr/8 | fce/8 | start/16 | 0xFF00 | crc/16 | or | adr/8 | fce/8 | start/16 | 0x0000 | crc/16 | it is a simple copy of the request adr - address of the PLC on the Modbus fce - function, which the PLC performs after receiving the frame start - start address of data (output), which is to be processed crc - security word - 06 (Preset Single Register) Sets the content of one register = 1 word. It is a similar function to the previous one however the state of the register appears instead of the state of the bit. request | adr/8 | fce/8 | start/16 | data/16 | crc/16 | reply | adr/8 | fce/8 | start/16 | data/16 | crc/16 | again it is a simple copy of the request. adr - address of the PLC on the Modbus fce - function, which the PLC performs after receiving the frame start - start address of data which is to be processed data - content of written register crc - security word - 0F hex (Force Multiple Outputs) Simultaneous setting of more outputs. request | adr/8 | fce/8 | start/16 | number/16 | cnt/8 | data/8 * cnt | crc/16 | reply | adr/8 | fce/8 | start/16 | number/16 | crc/16 | adr - address of the PLC on the Modbus fce - function, which the PLC performs after receiving the frame. start - start address of data (output), which is to be processed. number - number of bits for writing cnt - number of bytes necessary for transmission of the addressed group of bits data - states of written outputs, words contain swapped bytes in the form L,H, L,H, L,H, ... crc - security word. - 10 hex (Preset Multiple Regs) Similar to the previous function it sets more registers at once. request | adr/8 | fce/8 | start/16 | number/16 | cnt/8 | data/16 * numb | crc/16 | reply | adr/8 | fce/8 | start/16 | number/16 | crc/16 | adr - address of the PLC on the Modbus fce - function, which the PLC performs after receiving the frame start - start address of data (output), which is to be processed number - number of words for writing cnt - number of bytes necessary for the transmission of the required group of words data - states of written registers crc - security word - 17 hex (READ/WRITE HOLDING REGISTERS) Joins the functions 03 read and 06 write. request | a/8 | f/8 | rst/16 | rno/16 | wst/16 | wno/16 | wcnt/8 | wdata/cnt*8 | |crc/16 | reply | a/8 | f/8 | cnt/8 | data/cnt*8 | crc/16 | a - slave address f - function READ/WRITE HOLDING REGISTERS rst - start of read area rno - number of registers of the read area wst - start of written area wno - number of registers of written area wcnt - number of bytes of data in the frame wdata - data that should be written If the Slave PLC does not understand something in a request/command it is obligated to return an exception. The exception should inform the Master about the situation in which it tried to work with either an unauthorised function for the given Slave or with data outside of the valid range for the given Slave PLC. - reply to the request or command entered incorrectly | adr/8 | 0x80+fce /8 | excode/8 | crc/16 | adr - address of the PLC on the Modbus fce - function, which develops the exception excode - exception number, specifies where exactly and what error occurred 1 - erroneous function number 2 - erroneous data address 3 - erroneous data content 5 - confirmed receipt of command, whose execution is slow 6 - rejection, Slave is busy with the function of a slower command crc - security word 1. Function of the Modem in the MODBUS protocol. The modem connected to Modbus has several function options (see below for a detailed description): - transparent mode In this mode data is transmitted as it was generated at the Master (or Slave in the case of a reply). It is only checked on a valid CRC and subsequently sent to the proper MORSE address. This is found by simple direct mapping of the Modbus address through the mask to the MORSE address. This mode does not check the content of transmitted data in any way. I.e. it is possible to transmit practically anything that meets the conditions of the correct CRC and address. This mode can only be recommended for applications for which the amount and what data will be transmitted is not known in advance. Another significant disadvantage are the Master Slave response speeds, which are directly proportionate to the transport of a packet through the network and back. - cache mode This mode comes from the assumption that most technology needs to gather data in one place (control centre) and only from time to time to send some command from the control centre. All data travelling in the direction of the control centre is memorised in the central modem's cache and from there immediately returned upon the Master's request, i.e.the central modem appears as a complete network of Slaves for the Master. Only commands for Slaves, changes, and from time to time updates in order to synchronise data in the cache and in the corresponding Slave are transmitted through the network. This saves about 90% of network capacity because it removes the transmission of data already contained in cache. An undisputed advantage is the fact that the response speed to a request to cache is of the order of milliseconds. Hence the Slave polling cycle is very fast. At this point of course a small defect surfaces - some of the PLC´s are not able to wait for a sufficiently long time for a reply - when they were designed calculations were not made with networks with a very long response (in comparison with conventional metallic wiring). This concerns the case when the Master is sending a command in the direction of the Slave. Then the response is longer - complete transport through the network and back. The moment the time runs out for such a PLC it starts to repeat the process even though the command has still not yet been delivered to the Slave. After several repeats it does wait for a reply, however it is the reply from first sending the command. The PLC stops repeating however the network is now teeming with the unnecessary repeating of commands and replies to them. For such an unfortunate PLC a draw bar exists which can be used to limit such a situation. By means of the parameter "(r)epeat discard" it is possible to set how many repeats should be discarded before it releases another into the network. The central modem is able to recognise a dead Slave. It keeps in memory times between individual updates or change packets and if such a time runs through the set value the corresponding Slave is declared as dead and the modem ceases to reply to requests to this Slave. Cache mode can be recommended for most applications where the volume of transmitted data does not exceed 50 bytes and the number of Slave stations is also under 100. (Aid: the volume of data can be greater but the product (volume_data * number_stations) should not exceed 5000, which is the maximum size of the cache). From the information above it is obvious that the cache mode removed unnecessary loading of the network when transmitting request from the Master to the Slave PLC´s because polling PLC´s is done locally between the modem and the PLC. Only commands and changes are then transferred through the network. - packet mode This mode only makes use of Modbus as a link layer. Data packets which contain information in the header for correct delivery within the MORSE network are transmitted (practically the same as in MORSE networks) between individual participants of this type of communication. The difference between the Master and the Slave ceases to exist in this mode. Hence it doesn't matter whether the Master is a modem or connected equipment in this communication. All participants can transmit packets without limits. For the Master the modem acts as a Slave and for the Slave the modem acts as Master. It is absolutely no problem to make a connection between two Master (Slave) PLC´s, which would not be possible with the general Modbus. Addressing passes from Modbus addresses to MORSE addresses. The original addresses are used only as link addresses and can be repeated within the MORSE network this even simplifies configuration. This mode is strongly recommended for heterogeneous networks where there are a large amount of different types of PLC´s and where there are high demands on variability (size and speed) of transmitted data. When operating in this mode there can also be spontaneous transformation of protocols. This can be used to relative advantage when connecting various pieces of technology mounted with PLC´s with various communication protocols. The packet mode also enables for example in the centre the use of communication with applications via the UDP/IP and Morse Application Server and on Slave stations besides the Modbus protocol the use of other protocols. Use of the packet mode and Application server saves significantly on invested resources because the need is dropped in most cases for fitting an expensive PLC Master, which generally only works as a data concentrator for the subsequently connected SCADA system. - time synchronisation This matter is not actually communication along the network but enables time to be synchronised between individual PLC´s and networks. Here the modem can be the source of time data or conversely the receiver. Probably the most common variation will be as follows: the central modem will be locked onto the time of the Master system. For other modems in the network it will be the source of time and other modems will then be the source of time for Slave PLC´s. - watchdog This element comes from the fact that the program in the Slave PLC does not have the possibility to learn whether communication has taken place or not. This is caused by the structure of the PLC and its firmware (Caution! Do not confuse with user software). In parametrising this mode the modem, in Master mode, will periodically write the agreed value (again a parameter) to a specific address in the PLC. - phantom access Phantom access can only be used in the mode when the modem is Slave and works with cache switched on. With the help of the phantom principle it is possible to approach cache without the addresses of individual Slaves. The whole cache appears to the Master system as a single Slave with a large pack of data. This principle is very advantageous for configuration with many Slave PLC´s in the network. Unnecessary requests on the small packs of data from individual Slaves drop out on the side of the Master system. The Master can read the whole cache using several small requests. Although the Master must know the organisation within the cache for this principle of activity. This is given by the structure of the data arriving from the Slave PLCs. - virtual station Similar to the phantom this element is also functional only for cache and for the Slave mode of the modem. This aid provides the superior Master system information about newly arrived messages from the network.On the basis of this information the Master can modify the sequence of polling in order to read data from cache only from addresses of stations that underwent change (change/update packet delivered). In this way it is possible to minimise polling from the side of the master system and thus significantly save on bus costs. The combination of cache, phantom and virtual station appears to be the most optimum. On the basis of information from the virtual station the Master makes a list of Slaves which underwent change and reads the necessary addresses for the phantom. Then using phantom it reads the necessary data all at once. Instead of many gradual requests now two requests will be sufficient. The first reads the contents of the virtual station and the second reads the necessary information from phantom. 1.1 Modem as MASTER The modem emulates the Master on the side of the Slave PLC. Here it is possible to connect a max. of 4 Slaves. Their addresses on RS485 should be unique within the MORSE-Modbus network because direct mapping using the MORSE->Modbus mask is used and vice versa (this rule does not apply to the packet mode). For certain modes it is also possible to use Art tables, however these are primarily determined for routing. According to the selected variations of operation the modem can periodically "lick" Slave PLCs and read data from them in cache and packet mode. A special case is transparent mode when requests to Slave PLCs are received without change from the central Master PLC via the network and replies to it are transferred without change via the network back to the central PLC. All modes mentioned can be switched on at once. 1.1.1 Modem MASTER in cache mode If the modem is parameterised to this mode it forms the Master for several connected Slave PLCs. The cache mode is based on the assumption that common technology more often than not concentrates data into one place (SCADA, Master PLC), whereas commands to the technology are more often than not sporadic. For correct operation program support is necessary even in connected Slave PLCs. The program in the PLC forms a so-called "communica-tion zone", into which data from technology necessary for the superior control process (SCADA, Master PLC) is stored. The order and types of data are not critical. The communication zone is a continuous part of the PLC memory for so-called Holding Registers (Modicon). These registers are generic memory cells which are accessible through the function of the Modbus protocol (different manufacturers have various names for this part of the memory, however Holding Registers is probably the most common). This zone is read cyclically by the modem (period of reading can be parameteri- sed). Modem [C] (see network diagram) forms a copy of the data from this zone and compares it with the latest data received (data received from a request to this "communication zone"). If the modem finds any difference between the copy and the latest data received it immediately sends this data to the central modem [B], where it is stored in cache. Data is also transmitted after a certain predefined time of forced updating has elapsed. This principle ensures that even if there is an accidental loss of a packet with change data all data is still transmitted after a certain time irrespective of its state. Hence data in the central modem is only as old as that period of forced updating. For optimum operation of the cache mode it is necessary to ensure that changes in the replicated (cache) area of memory are well-founded, using the user program in the PLC. This mainly means good handling of analog variables for example. It often occurs, thanks to various interference, that the signal from the sensor is full of induced clicks. If these spurious elements appeared in the communication zone the modem would regard every such change - fault as a signal for sending to the central station. In itself this wouldn't actually matter, however the fact that such transmission brings no useful data is certainly not trivial from the point of view of network loading. Program support in the PLC requires knowledge of the structure of transmitted data, because from the point of view of the modem it is all regarded as binary. Because Master [A] in the Modbus protocol has no address it is necessary to at least assign it a MORSE address. This is done with a parameter in the modem. It is possible to switch on time synchronisation and watchdog as additional accessories. The modem can also be operated with packet mode switched on. 1.1.2 Modem MASTER in Transparent Mode When setting the modem to this mode the modem is Master for the connected bus and determines who will have space on the bus. It is obligatory for all other devices to be Slaves. Otherwise this would lead to undefinable states and collisions. The Modbus protocol isn't able to use the multimaster mode. In transparent mode packets are transmitted via the network in the same form they were received from the Slave PLC. Of course the CRC is checked. If checking of the CRC fails the frame is discarded. The only condition here is that the frame received from bus 485 (to which Slave PLCs are connected) must be provoked by the frame sent to the bus. In practice this only means that if the modem does not send a command or request and still receives something from the bus, even if the CRC is checked to be alright, it considers it as random disturbance and disposes of the received frame.As the modem in the transparent mode does not carry out any other activity besides checking the CRC it is possible to send absolutely obscure functions and data through the network. A typical case is remotely reprogramming a Slave PLC. In order for the transparent mode to operate correctly it is necessary to ensure that addresses of connected Slaves are the same as MORSE addresses in the modem. Naturally this requires network multiaddressing to be switched on in the modem and correctly set local routing tables.Mapping of addresses MORSE -> Modbus is done with an eight bit mask, which trims the upper part of the MORSE address and remains a Modbus address which is used for sending to the 485 bus. Reverse mapping from Modbus addresses to MORSE is done in the same way. The upper part of the MORSE address is determined according to the mask and is connected to the Modbus address using a simple OR function. The complete MORSE address produced in this way is used for sending to the network (in MORSE this is termed the source address). As the modbus protocol does not use the Master system address it is necessary to inform the modem of it. Otherwise it is not possible to ensure correct delivery of data in the direction of the Master system. The MORSE network cannot operate in both directions without the addresses. This is ensured by the configurable parameter that determines this address. The modem then directs all authorised replies from the Slave PLCs to this address. It is a good idea to select a value outside of the designed range so that it doesn't lead to confusion, e.g. the designed network will have 34 participants set from one, so MORSE addresses will be in the range, for example, from 45230001 to 45230022 (34 is 22 in hexadecimal). Hence the address of the Master system can lie in the range from 45230023 to 452300FF. It is often better to select an address at the other end of the range in case of future expansion - if the division of network addresses actually allows this, i.e. the Master system could have a MORSE address of 452300FF in such an application. Of course the most common application case will be that of a modem + one Slave PLC. This situation is very simple for configuration because all that is necessary is to ensure that the address of the PLC conforms with the last byte of the MORSE address, set the correct mode in the modem, and the address of the Master system and its done. 1.1.3 Modem MASTER in Packet Mode Packet mode assumes the existence of two buffers in the Slave device for temporary storage of packets determined for transport through the network. These buffers are implemented as areas of general memory which are directly accessible via Modbus. The function which enables reading and writing to memory areas terms this area as Holding Registers (Modicon). One of these buffers is determined for sending to the network and the second for receiving from the network. The buffer determined for sending from Modbus to the MORSE network is called H2Nbuf (host to network buffer). Similarly the buffer for receiving from the MORSE network to Modbus is termed N2Hbuf (network to host buffer). Both directions are completely independent and can be operated asynchronously. Because the modem is a Master in the version described it is the one that determines the course of communication on the RS485 bus according to set parameters. Before launching into a detailed description of communication it is necessary to make the structure of the buffers clear. Both have a similar structure but they needn't have the same length. The minimum length of the buffer corresponds to the maximum length of the Modbus frame, i.e. 250 bytes (the lengths of headers and CRC are subtracted). The maximum length is not limited, however when using the MORSE system 1600 bytes, which is the maximum permitted packet length in MORSE networks, is sufficient. Structure of buffers: H2Nbuf: | H2Ndesc/16 | H2Nfr/modbusMRU | N2Hbuf: | N2Hdesc/16 | N2Hfr/modbusMTU | description of individual items: H2Ndesc stands for "host to net descriptor", and contains information necessary for transferring the packet via the Modbus: |ret/1|rep/1|No/2|res/1|rxsize/11| N2Hdesc (net to host descriptor) is similar to H2Ndesc: |ret/1|rep/1|No/2|res/1|txsize/11| ret - 0 - user pseudoframe, 1 - routing pseudoframe (reserved for Racom use) rep - repeat bit No - packet number res - reserved rxsize - size of pseudoframe including address and type in bytes txsize - size of pseudoframe including address and type in bytes N2Hfr - user pseudoframe H2Nfr - user pseudoframe modbusMRU - Maximum Receive Unit modbusMTU - Maximum Transmit Unit Memory addresses of individual blocks (H2Nbuf, N2Hbuf) are freely configurable in the modem according to the needs of the connected device. The pseudoframe contains the actual packet determined for transfer to/from the network. A header containing network information is concealed inside the pseudoframe. This is made up of the address, length and serial number. The header is located immediately behind the descriptor in the buffer. The structure of data and header of the pseudoframe is as follows: User pseudoframe: | T/8 | D/1 | R/4 | N/3 | A/32 | data | T - type of packet D - bit DTE, if it is 0, the sender is DCE, A is source address. Conversely if it is 1, the sender is DTE, A is destination address. R - reserved, must be zero N - network number (transmitted along the network). A - address in the network data - actual data of the pseudoframe Numbering of packets is not obligatory. The number is supplied to the target address and can serve for checking the order of the supplied packets (the MORSE network does not guarantee that the order will be kept precisely). The address is either the source address (DTE receives packet) or the destination address (DTE sends packet). The packet comes to the protocol via the CNI (Channel to Node Interface), which can transfer the user address space to MORSE address space, e.g. by means of a mask. The max. permitted length of data in the MORSE network layer is 1626 bytes. Longer packets are not defined in the system. The optimum packet size for the MORSE system is 200-400 bytes. The packet type is similar to packets in the MORSE system. a detailed description about them can be found in other documents (e.g. Mars-A). We can now take a look at how communication will take place. If a Slave wants to send a packet then the descriptor (H2Ndesc) in H2Nbuf is tested. If it is zero H2Nbuf is filled according to the description. In the first word there is the descriptor with the length, from the second word there is the actual transferred packet (user pseudoframe) with the header followed by the actual data. The Master (modem) constantly (over the set period of reading) checks the descriptor in H2Nbuf and if it is not zero it reads a packet from H2Nbuf and subsequently sets the descriptor in H2Nbuf to zero. In this way it tells the Slave device that it has taken the packet and inserted it into the Morse network for sending. The Slave can now fill H2Nbuf with another packet, etc. In the opposite direction - receiving from the network - the process is analogical however only the modem checks the descriptor before writing. If the modem finds out that the descriptor is not zero, i.e. the Slave has still not taken the previously delivered pseudoframe, it tries it again and again until the life of this frame expires. This frame is then discarded. However, if during the course of the delivery attempt a zero descriptor is found (Slave processed the frame) the normal transfer process starts running. As the maximum size of data transferable in one frame of the Modbus protocol is 256 bytes this packet needs to be read (written) using several frames (fragments) if it is necessary to transmit a longer packet through the buffers. 1.1.4 Modem MASTER and Time Synchronisation A lot of technology based on Modbus requires Slave PLCs to be time synchronous (real time). Modbus alone does not have any hardware for time synchronisation and so generally it is resolved at the program level. These transmissions of time information are unnecessary from the point of view of the MORSE network because the MORSE network itself allows real time to be found at any point with relatively negligible demands on capacity. To save the Modbus application programmer work and also network capacity a mode of time synchronisation was introduced between the Slave device and the modem. The modem as Modbus Master can work in two modes: it is able to provide real time or conversely to receive time and synchronise to it. In the first case when the modem is the source of time it writes time to a specific area of memory in the Slave PLC in the set interval. Functions for work with Holding registers are used as well, the same as in cache and packet mode. The program in the Slave PLC tests this area and if it finds out that it contains some data it takes it and uses it for time synchronisation. After successful processing it deletes the area. On the contrary if the modem is time synchronised from the Slave PLC this area is read and data contained in it is used for synchronising the modem. In this case it is useful if the program in the Slave PLC adjusts the time in this area as often as pos-sible. Only in doing this will there be no differences when synchronising. If the modem is synchronised it is enough to fill the zone with data about GMT, summer/winter time and milliseconds. The other items are ignored. The structure of time data provided by the modem is relatively extensive and so the Slave PLC can choose the most suitable data. Format of time data: | gmtsec/32 | R/1 | ts/1 | R/4 | msec/10 | sec/8 | min/8 | hour/8 | day/8 | | month/8 | year/8 | gmtsec - current time, GMT indicated in seconds from 1.1.1970 is used (Unix time) msec - milliseconds in the current second. ts - timesavings, switch for summer/winter time (1 - summer, 0 - winter time) Other items contain local time including correction of the time zone. sec - current second min - minutes hour - hours (0 - 23) mday - day of the month (1 - 31) mon - month (0 - 11) year - year (data in the year form - 1900) R - reserved 1.1.5 Modem MASTER and Watchdog Some critical control processes require information about the correct activity of the modem. As most PLCs, thanks to their internal firmware, grade communication on the serial port from the user program the user does not have a means of finding out if the modem is working correctly. In light of this a mode was introduced where the modem regularly writes defined data to a predefined location. The program in the Slave PLC tests this area and evaluates its state. If the program finds out that nothing was written into this area for longer than the set period it can switch to a state not requiring communication, or alternatively safely shut down the technology. The modem knows how to write into the area of free memory (Holding Registers) using the set bit mask. Time is also configurable in wide bands. Generally the watchdog mode runs as follows: the modem, for example, once every five seconds writes to the Slave PLC, e.g. to address 0x1000 the value 0x8000 (i.e. sets a higher bit in the given word). This address is also tested by the program in the PLC. If it finds it has written to a correct bit it deletes this bit and starts the timer, which is set to a time slightly greater than five seconds. The cycle repeats when writing occurs again. If the timer runs out it is an unmistakable sign that the correct bit was not written and this can be declared as a modem failure. 1.2 Modem as SLAVE Slave mode is essential for connecting to the Master system. According to the selected variations of operation the modem appears as a complete 485 network or communicates in packet mode when operation typically for the 485 network fades away. Typical applications use the Master as a data concentrator and hence the connected modem is the route to the remote Slave PLCs. It is important to note that in this mode the modem will be loaded several times more than any remote modem at a Slave PLC. All data to/from the network must pass through it. 1.2.1 Modem SLAVE in Cache Mode Slave modem [B] is connected to the Master PLC [A]. On its requests, which must be in accordance with replicated areas (supported by practically all reading functions), the modem returns replies the same as if Slave PLCs would be directly on the same segment of the bus. If the request is not correct an exception is returned. As the modem does not know what data is contained in cache it returns the same data to various types (functions) of requests with the same address, i.e. if the program in the Slave PLC positioned bit data (inputs/outputs) in a specific position in cache and the Master makes a request to this position like to a register this data is returned like the content of the registers. The situation is similar even in the case of a bit request to the position of a register. Commands and other write functions pass outside of cache and are directly transferred through the network to the Slave PLC [D]. The reply to these commands is also transferred directly. This results in a request on the Master system: it must be able to wait for a reply for a longer period than for replies from cache. Because memory for cache in modem [B] is limited, it is necessary to know in advance the amount of data from one Slave PLC and the number of them. (See help above). It is necessary to mention the fact that when starting the modem, either because of a power failure or when resetting the software the whole of the cache is initialised. In this case all data is lost and must be updated from Slave stations. Also all stations will be declared as dead. This is because of the need for clearly defined starting conditions. It is necessary to make allowances for this disadvantage during the design phase. In cache mode support tools are available for saving costs on the bus. As was previously mentioned above this concerns phantom access and virtual stations. Services connected with real time and packet mode are also available. 188.8.131.52 Phantom Access By switching on phantom access it is possible to move around the cache area without the use of Slave PLC addresses which are necessary under normal conditions. The principle comes from the fact that data in cache is arranged consecutively according to the addresses of individual Slaves. If a Slave is not occupied there is space in cache with zero content of the size the Slave would have occupied. By cancelling the rule that it is only possible to access the area in cache reserved for a certain Slave via its address and by establishing a linear address space through the whole cache we almost achieve the desired effect. It is also necessary to distinguish normal requests from requests to the phantom. This can be done in two ways. First by establishing a new address within the network which the phantom will listen to. It is obvious that this address cannot exist anywhere else in the network. The other method is to distinguish requests to the phantom by means of the start address of the request (see the description of Modbus frames). This principle is a little more complicated because the Master system must count offsets within cache from the phantom's initial address. When using the first principle counting of the offset drops out because cache is then set from the zero address. When using phantom access the Master system must read data irregardless of which Slave it belongs to. Its sorting is then only a matter of the ingenuity of the program in the Master system. The greatest advantage of this access to cache is the marked saving on bus costs. Furthermore there is also a significant increase in response time of the whole system. At the present time only the principle of a unique phantom address is supported, the other is still under development. 184.108.40.206 Virtual station By permitting this feature the Master obtains the ability of having a constant view of incoming messages from the network. Naturally this option is only supported in cache mode. Virtual station data are actually data fields whose individual items (bits) correspond to remote stations, i.e. the first bit corresponds to station number one, the second bit to number two, etc. When a packet has arrived from a remote station the modem ascertains the senders address and sets the respective bit in the virtual station's bit field to log. 1. If the Master reads anything from cache from the address of station which is sending the data the respective bit is again flipped back to log. 0. For example, data packets arrived from stations 5, 28 and 49. Data from the packets is stored in cache and the bits corresponding to the numbers of the stations (5, 28, 49) are set to 1. In one of the following requests the Master ascertains the state of the virtual station and can modify the polling list in such a way that it inserts the numbers of stations 5, 28, and 49 at the beginning of the whole cycle. Hence data from these stations is read first without unnecessary waiting until it is their turn in the polling cycle. The modem subsequently flips the corresponding bits and the whole process can be repeated. A virtual station appears as another member of the network for the Master system, i.e. it has its own address within Modbus. It also has a specific structure of data (see above). It is obvious that in this way it is possible to save on a lot of the time which data would wait in cache before the Master would read and process it. This again shows itself positively on faster system responses. 1.2.2 Modem SLAVE in Transparent Mode Transparent mode in the SLAVE modem does not differ greatly from that in the MASTER modem. Data is subject to the same checks on the CRC. Also the address of the remote Slave PLC is ascertained by the same mechanism. As the modem cannot anticipate the states of individual remote systems packets are transmitted from the network irregardless of whether they were called by the Master system or not. The Master system should be resistant to such cases where an unsolicited packet emerges from the network. The cause of such states can be a loss of confirmation and subsequent duplication of packets. This should not occur in a well tuned network. 1.2.3 Modem SLAVE in Packet Mode Packet transmission in SLAVE mode is based on the same principle as in the MASTER case. The difference now is that the modem does not determine movement on the bus but must wait until the Master addresses it. So, it stores the incoming packet from the network in a queue and sets its specified lifetime. The Master is obligated to call the modem on such a frequency that it manages to receive all incoming packets, otherwise the modem starts discarding packets. The Master reads N2Hdesc and ascertains its status. If it finds that the descriptor is not zero it counts how many times it is going to read the incoming packet. It then starts its own packet counting mechanism. If the packet is read it confirms it has been read correctly by writing a zero in the descriptor. The modem can prepare another packet. The Master proceeds in a similar manner if it needs to send a packet. First it reads descriptor H2Ndesc and makes sure that it is zero. It then starts to transfer the packet. Finally it records the descriptor as a signal that the packet as a whole is ready to be sent through the network. The modem processes the packet and sends it to the network. It then deletes the descriptor as confirmation for the Master that everything has been done. 1.2.4 Modem SLAVE and Time Synchronisation In this mode the modem is again capable of two versions of operation. It can operate as a source of real time or can be synchronised from the Master system. In the first case when the modem is a source of time the Master reads information, in the set interval, about the time from a specific area of modem memory. On the contrary if the modem is synchronised with time from the Master system this area is recorded and data in it is used for synchronising the modem. As with the MASTER modem it's enough to fill in data about GMT, summer time and milliseconds. If it is found that data will be recorded right at the start of a new second milliseconds do not need to be used and it can contain zeros. The structure of time data is similar to the case of the MASTER modem. 2. Parameters of the Modbus Protocol MODBUS parameters: (m)ode:MASTER (c)ache:OFF (p)acket:ON (t)rans:ON (a)utomaster:OFF (s)ervices (C)ache params (M)aster params (S)lave params (P)acket params (A)utomaster params (q)uit >> (m)ode:MASTER (c)ache:OFF (p)acket:ON (t)rans:ON - mode selection (a)utomaster:OFF - Slave can have the automaster function on, it then assumes the Master function when interrupting communication on RS458 >>C cache parameters: (v)irtual:0000 (p)hantom:0000 (l)ower address:0000h (h)igher address:0000h (q)uit >> Parameters for cash mode: (v)irtual:0000 - address of the location of the memory block for recording current messages from the Slave, 0000 = function off (p)hantom:0000 - address of the location of the memory block for one-off reading of the image of all Slaves, 0000 = function off (l)ower address:0000h - beginning of transferred section of memory in PLC (h)igher address:0000h - end of transferred section of memory in PLC >>M master parameters: (d)estination:69000031h m(i)rror:0s d(e)vice type:PLC slave addresses: (0):4h (1):5h (2):0h (3):0h (a)ddress mask:Fh (p)eriod:200ms (t)imeout:3000ms (q)uit >> Parameters for Master station - [C] in the introductory diagram: (d)estination:69000031h - address of centre in MORSE network, for cache and transparent modes, 00000000 = messages are sent back m(i)rror:60s - after this time the Master CU regularly passes the MORSE network message to the Slave CU d(e)vice type:PLC - choice between connected SEP technological unit and normal PLC slave addresses: (0):4h (1):5h (2):0h (3):0h - list of Slave stations included in the polling cycle (a)ddress mask:Fh - masked part of the MORSE address is used as a Modbus address (p)eriod:200ms - period for polling Slave stations (t)imeout:1000ms - max. time for waiting for a reply >>S slave parameters: RS485 (a)ddress:0h m(i)rror:0s (r)epeat discard:0 d(e)vice type:PLC (q)uit >> Parameters for Slave stations - [B] in the introductory diagram: RS485 (a)ddress:0h - address of Slave stations in the Modbus network, 01 to FF m(i)rror:120s - Slave CU waits for this time for a message from each Master CU, otherwise it discards it from the polling list (r)epeat discard:0 - number of repeats from Master PLC, which are discarded before one is sent to the radio network d(e)vice type:PLC - choice between connected SEP technological unit and normal PLC >>P packet parameters: (A)RT table No.:4 (N)2H buffer:1000 (H)2N buffer:2000 Warning! Both addresses should be nonzero. (q)uit >> Parameters for packet mode: (A)RT table No.:4 - selection of Art table for the transfer of MORSE addresses to Modbus addresses (N)2H buffer:1000 - Net to Host, which is MORSE Net to Modbus (H)2N buffer:2000 - Host to Net, which is Modbus to MORSE Net - addresses in memory, at which the respective buffer for storing data sent by the Modbus in packet mode starts. These addresses must be selected identically at all participants of the Modbus network. Here the term Net represents the connecting MORSE network or also the only CU connected to the RS485. >>A Modbus automaster: t(i)meout:0s master mode after switching: (c)ache:OFF (p)acket:OFF (t)rans:OFF (q)uit >> Parameters for Automaster mode: t(i)meout:0s - after this idle period on the RS485 the Slave with the (a)utomaster parameter switched on takes the Master task and continues in the mode determined by the following three parameters. Upon restoring the activity of the original Master the Slave returns to its task. >>s Modbus services: (t)ime sync:ON (m)ode:SENDER (p)eriod:10s time (a)ddress :3000h time sync (b)it:0000h (w)dog bit:0000h wd(o)g address:0000h wdog p(e)riod:0s (d)ebug address:69000011h (q)uit >> (t)ime sync:ON - switches on the function of transfer of time data between the Master and the Slave defined in "slave addresses (0)" (m)ode:SENDER - Master or Slave can be selected as SENDER (transmits time), and the other as RECEIVER (receives) (p)eriod:10s - period for transferring time data is only defined in Master time (a)ddress :3000h - address for saving time, Master and Slave time sync (b)it:0000h - special function (Toth) (w)dog bit:0000h - word periodically written to "slave addresses (0)" wd(o)g address:0000h - address of write to Holding Registers in Slave (0) wdog p(e)riod:0s - write period - parameters for watchdog are only set in Master (d)ebug address:69000011h - address for tuning purposes; all user packets, which came to the CU are sent to this address, to which, for example, Setr or async. link are connected 3. Examples and Explanations 3.1. Packet type. Brief description of the packet type for the user interface: |U/1|B/1|R/1|subt/5| U - link security bit (1 - secured packet) B - broadcast (multicast) bit (1 - broadcast packet) R - reserved subt - subtype subt=0x09 - USER DATA The basic type of packet for transporting data from the source to the destination. By setting the bit U=1 we obtain the mostly used packet type 0x89, it is secured user packet. subt=0x0A - PROT DATA This type of data is designed for data flow control in the user protocol. The service of both preceding types of packets in the MORSE network is equivalent. Packets are sent to the destination with the path and priority settings at the participants addresses. An error message is sent to the original sender if a packet is lost, but the packet carrying this error message can be, of course, lost as well, and in this case silently. subt=0x0Ch PACK ERROR REPORT MORSE error message. First word is the Error Number, the rest of the message holds more detailed information about the network error. Generation of these errors can be turned off and on for whole network. Some of these Error Numbers are here: 1 - PACKET_NOT_CONFIRMED 2 - STORE_TIMEOUT 3 - NO_CHANNEL_ASSIGNED 4 - ACCESS_TIMEOUT_ERROR 6 - WRONG_PACKET_FORMAT 7 - DEST_PROT_MISSING 8 - WRONG_PATH 9 - WIRE_LINK_FAIL subt=0x10 - SERVICE REQUEST Request for a MORSE service. subt=0x12 - SERVICE REPORT Response from the MORSE service. 3.2 Example of Reading Data in Cache Mode. The MASTER PLC sends requests to the connected CU MR25 and receives replies with data (left column). The CU provides data from its cache memory (right column). [A] [B] MASTER PLC interpreter CU (MR25) cache cache 01 02 00 08 00 08 CRC --> 79h 01 02 01 01 CRC | +-- 78h 2.word 01 03 02 56 78 CRC +------ 01h 01 01 01 0F CRC >O.K. >> 15:28:10.018| |69000014 69000021|S00I IN 409 6serv AAAA AAAA = Modbus Master protocol received data for sending for Slave 4 15:28:10.784 tx 8 | S00 0403 2000 0001 8F9F = Slave 4, do you have a free buffer H2N ? 15:28:10.788 rx;i 7 | S00 0403 0200 0074 44 = yes 15:28:10.789 tx 21 | S00 0410 2000 0006 0C30 0A09 0669 0000 14AA AAAA AA4C A0 = write a message 15:28:10.794 rx;i 8 | S00 0410 2000 0006 4B9E = I have written it 15:28:11.785 tx 8 | S00 0503 1000 0001 814E = Slave 5, do you have any data for me ? ... polling continues 15:28:11.788 rx;i 7 | S00 0503 0200 0049 84 = I don't 15:28:12.786 tx 8 | S00 0403 1000 0001 809F = 4, do you ? 15:28:12.790 rx;i 7 | S00 0403 0200 0074 44 = I don't For examples of the format of packets see article Sending a short user packet from Master to Modbus. 3.5 Sending a Short User Packet from Master to Modbus. Report AAAAAAAA is sent from Morse address 69000011 to address 69000014. In the Modbus network there is only one Slave with the address 04. 17:51:31.528 tx 8 | S00 0403 1000 0001 809F = packet 1 17:51:31.532 rx;i 7 | S00 0403 0200 0074 44 = packet 2 17:51:32.529 tx 8 | S00 0403 1000 0001 809F 17:51:32.533 rx;i 7 | S00 0403 0200 0074 44O.K. >> 17:51:32.640| |69000014 69000011|S00I IN 409 0serv AAAA AAAA 17:51:33.530 tx 8 | S00 0403 2000 0001 8F9F 17:51:33.533 rx;i 7 | S00 0403 0200 0074 44 17:51:33.534 tx 21 | S00 0410 2000 0006 0C30 0A09 8069 0000 14AA AAAA AA06 C6 = packet 3 17:51:33.540 rx;i 8 | S00 0410 2000 0006 4B9E = packet 4 17:51:34.531 tx 8 | S00 0403 1000 0001 809F 17:51:34.534 rx;i 7 | S00 0403 0200 0074 44 packet 1 - reading register | 04 | 03 | 1000 | 0001 | 809F | | adr| fce | start adr | number of words | CRC | in register read packet 2 - reply to reading | 04 | 03 | 02 | 00 00 | 7444 | | adr| fce | number | content | CRC | of bytes of bytes read read packet 3 - write to register in Slave 04 | 04 | 10 | 2000 | 0006 | 0C | 300A | 098069000014 | AAAAAAAA | 06C6| | adr| fce|start |number |number |H2Ndesc| header | data | CRC | |address|write |write | | user pseudoframe | |in reg.|words |bytes | content of written buffer | H2Ndesc - descriptor of Host to Net buffer 300A = 0011 0000 0000 1010 0 - user pseudoframe 0 - repeat bit 11 - packet number 0 - reserve 000 0000 1010 - size of user pseudoframe (10 bytes) header of user pseudoframe 098069000014 = 09hex 1000 0000 69000014hex 09hex - type of packet 1 - bit DTE -> address is destination 0000 - reserve 000 - network number 69000014hex - address, here destination packet 4 - reply to write | 04 | 10 | 2000 | 0006 | 4B9E | | adr| fce| start | number | CRC | | address| written | | in reg.| words | 3.6 Sending a short user packet from Slave to Modbus. Message BBBBBBBB is sent from the Morse address 69000014 to address 69000004. There is only one Slave in the Modbus network with address 04. 18:07:33.650 rx;i 8 | S00 0403 1000 0001 809F 18:07:33.651 tx 7 | S00 0403 0200 0074 44 18:07:34.651 rx;i 8 | S00 0403 1000 0001 809F 18:07:34.652 tx 7 | S00 0403 0200 0074 44s >>O.K. >> 18:07:35.652 rx;i 8 | S00 0403 1000 0001 809F 18:07:35.653 tx 7 | S00 0403 0200 0074 44 18:07:35.739| |69000004 69000014|S01I OUT 489 0serv BBBB BBBB 18:07:35.740| |69000004 69000014|S00I IN 489 7serv BBBB BBBB 18:07:36.653 rx;i 8 | S00 0403 1000 0001 809F = do you have data in N2Hbuf ? 18:07:36.654 tx 7 | S00 0403 0220 0AED 83 = yes, I have 10 bytes 18:07:36.657 rx;i 8 | S00 0403 1000 0006 C15D = send 2+10=12 bytes (including N2Hdesc) 18:07:36.658 tx 17 | S00 0403 0C20 0A09 8769 0000 04BB BBBB BB30 0D = I am sending 12 bytes 18:07:36.665 rx;i 11 | S00 0410 1000 0001 0200 0088 C1 = delete N2Hdesc 18:07:36.667 tx 8 | S00 0410 1000 0001 055C = deleted 18:07:37.654 rx;i 8 | S00 0403 1000 0001 809F = do you have data in N2Hbuf ? 18:07:37.655 tx 7 | S00 0403 0200 0074 44 = no 18:07:38.655 rx;i 8 | S00 0403 1000 0001 809F 18:07:38.656 tx 7 | S00 0403 0200 0074 44 3.7 Sending a long user packet from Master to Modbus. A message 404 bytes long is sent from Morse address 69000011 to address 69000014. There is only one Slave in the Modbus network with address 04. 17:50:19.456 tx 8 | S00 0403 1000 0001 809F 17:50:19.459 rx;i 7 | S00 0403 0200 0074 44s 17:50:20.457 tx 8 | S00 0403 1000 0001 809F 17:50:20.460 rx;i 7 | S00 0403 0200 0074 44 >> 17:50:20.834| |69000014 69000011|S00I IN 40409 0serv AAAA AAAA CFAC F1C2 1471 E0B5 EB8D 420F 0A6C 3CAB 5EC2 D591 6F5C 8501 7478 BF1A 2973 3B6F BC35 529F 3F99 9AD6 D4C8 73B7 0C3C 6020 F9F0 4FD2 D0DC 44D5 C0CE 8039 F652 877E 2F0C 4FC9 05E3 9DBA 18CB A06F 2708 EC21 714E AC63 ADFB 1FDC FA68 9F24 0701 8601 7EA5 C236 0A7B 7CAF 823B B99E 85AA D9EE 16AF 0C1A 8445 E443 3D47 F320 A6BC 3916 0433 2E9D 914A BCC5 4A7A 586A 3FBD 7084 D6A6 F38E CA05 C9FB 2C2E 3336 E57E E89D 4BA8 3575 2EFD C4C9 49AB 2DBB 099C 34A3 6885 BB17 9E46 62B1 20A2 662D 4801 1235 43B7 02F5 78FE CD4C 26B1 7238 E462 D8CB 7E61 FECB 78D2 89D5 5AE4 528A 77C1 593C 6DD3 BF14 B579 D09D 8730 5648 CDEA 2D3A F50B 0E82 DA36 5495 31F7 EE96 F2F8 76D2 0E30 FD88 8B58 7ACA 3F89 7211 70D0 0FEE 0418 5DD3 FBBB 01E2 43A0 D057 BCA2 29D5 5BC1 2DCA B246 19A2 82E1 357C D46D 5CA8 6DD9 F414 7F6D EA6A A460 9D94 0C79 26E5 B038 0B10 A2AF 8CB5 131A 582D 0CDD DCE6 AF62 DC5C 2017 709B 0F7A 7BD4 FEF9 0861 B808 0C51 45BC 3551 70D7 498E EAFB 37E7 3086 9583 6143 F0A5 16F3 805F 455D 3E67 A265 D444 A55A E685 0B7B A0C4 AC63 E2ABO.K. >> = sent data enter S00, where Modbus is 17:50:21.458 tx 8 | S00 0403 2000 0001 8F9F = do you have H2Nbuf free ? 17:50:21.461 rx;i 7 | S00 0403 0200 0074 44 = yes 17:50:21.464 tx 255 | S00 0410 2053 007B F633 36E5 7EE8 9D4B A835 752E FDC4 C949 AB2D BB09 9C34 A368 85BB 179E 4662 B120 A266 2D48 0112 3543 B702 F578 FECD 4C26 B172 38E4 62D8 CB7E 61FE CB78 D289 D55A E452 8A77 C159 3C6D D3BF 14B5 79D0 9D87 3056 48CD EA2D 3AF5 0B0E 82DA 3654 9531 F7EE 96F2 F876 D20E 30FD 888B 587A CA3F 8972 1170 D00F EE04 185D D3FB BB01 E243 A0D0 57BC A229 D55B C12D CAB2 4619 A282 E135 7CD4 6D5C A86D D9F4 147F 6DEA 6AA4 609D 940C 7926 E5B0 380B 10A2 AF8C B513 1A58 2D0C DDDC E6AF 62DC 5C20 1770 9B0F 7A7B D4FE F908 61B8 080C 5145 BC35 5170 D749 8EEA FB37 E730 8695 8361 43F0 A516 F380 5F45 5D3E 67A2 65D4 44A5 5AE6 850B 7BA0 C4AC 63E2 ABA5 7A = write the last part of the data to H2Nbuf 17:50:21.492 rx;i 8 | S00 0410 2053 007B 7BAE = written 17:50:21.494 tx 175 | S00 0410 2000 0053 A611 9A09 8069 0000 14AA AAAA AACF ACF1 C214 71E0 B5EB 8D42 0F0A 6C3C AB5E C2D5 916F 5C85 0174 78BF 1A29 733B 6FBC 3552 9F3F 999A D6D4 C873 B70C 3C60 20F9 F04F D2D0 DC44 D5C0 CE80 39F6 5287 7E2F 0C4F C905 E39D BA18 CBA0 6F27 08EC 2171 4EAC 63AD FB1F DCFA 689F 2407 0186 017E A5C2 360A 7B7C AF82 3BB9 9E85 AAD9 EE16 AF0C 1A84 45E4 433D 47F3 20A6 BC39 1604 332E 9D91 4ABC C54A 7A58 6A3F BD70 84D6 A6F3 8ECA 05C9 FB2C 2EAD 9A = write the next part of the data from the end (here the beginning of the data including the header of the user pseudoframe) 17:50:21.514 rx;i 8 | S00 0410 2000 0053 8BA1 = written 17:50:22.459 tx 8 | S00 0403 1000 0001 809F 17:50:22.462 rx;i 7 | S00 0403 0200 0074 44 3.8 Sending a long user packet from Slave to Modbus. The message is sent from the Morse address 69000014 to address 69000004. There is only one Slave in the Modbus network with address 04. 18:17:30.241 rx;i 8 | S00 0403 1000 0001 809F 18:17:30.242 tx 7 | S00 0403 0200 0074 44s 18:17:31.243 rx;i 8 | S00 0403 1000 0001 809F 18:17:31.243 tx 7 | S00 0403 0200 0074 44 18:17:32.097| |69000004 69000014|S00I IN 40489 2serv AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA ABBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF = data enters port S00, where Modbus is 18:17:32.243 rx;i 8 | S00 0403 1000 0001 809F = do you have data in N2Hbuf for the Master? 18:17:32.244 tx 7 | S00 0403 0211 9AF8 7F = yes, I have 0x19A bytes 18:17:32.248 rx;i 8 | S00 0403 1051 007D D0AF = send 0x7D bytes 18:17:32.250 tx 255 | S00 0403 FACC CCCC DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEEE EEFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFE6 63 = first part of data (from end) sent 18:17:32.278 rx;i 8 | S00 0403 1000 0051 80A3 = send 0x51 bytes 18:17:32.280 tx 167 | S00 0403 A211 9A09 8269 0000 04AA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBB BBBC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CCCC CC59 3D = next part of data sent 18:17:32.303 rx;i 11 | S00 0410 1000 0001 0200 0088 C1 = delete N2Hdesc 18:17:32.305 tx 8 | S00 0410 1000 0001 055C = N2Hdesc deleted 18:17:33.245 rx;i 8 | S00 0403 1000 0001 809F 18:17:33.245 tx 7 | S00 0403 0200 0074 44 18:17:34.245 rx;i 8 | S00 0403 1000 0001 809F 18:17:34.246 tx 7 | S00 0403 0200 0074 44 3.9 Automaster sends Herman's packet. The Slave switched to the Automaster mode sends an imitation "Herman's" packet generated from the MORSE main menu using the mth. command. There is only one other Slave in the network with address 04. 0403 1000 0001 809F 06:52:00.388 rx;i 7 | S00 0403 0200 0074 44h 06:52:01.373 tx 8 | S00 0403 1000 0001 809F 06:52:01.389 rx;i 7 | S00 0403 0200 0074 44 Send type :09 69000005h> 06:52:01.784| |69000005 69000025|S00I IN 25589 6serv 0410 2092 007B F600 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0022 93 = packet enters SCC0 where Modbus is 06:52:02.374 tx 255 | S00 0410 2092 007B F600 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0022 93 = write 0xF6 bytes of data to Slave memory 06:52:02.527 rx;i 8 | S00 0410 2092 007B 2A52 = written 06:52:02.528| |69000025 69000005|S00I OUT 8 89 0serv 0410 2092 007B 2A52 = acknowledgement of the transfer of the packet is sent to src address 69000025 06:52:03.375 tx 8 | S00 0403 1000 0001 809F 06:52:03.390 rx;i 7 | S00 0403 0200 0074 44 3.10 Automaster sends Herman's broadcast. The Slave switched to the Automaster mode sends an imitation "Herman's" broadcast generated from the MORSE main menu using the mtH. command. The packet spreads through the MORSE network like a broadcast, in Modbus as a direct packet. Upon acknowledgement in Modbus a return message to the MORSE network is not generated. In the example it is the only other Slave in the network with address 04. 07:05:53.204 tx 8 | S00 0403 1000 0001 809F 07:05:53.220 rx;i 7 | S00 0403 0200 0074 44H 07:05:54.205 tx 8 | S00 0403 1000 0001 809F 07:05:54.221 rx;i 7 | S00 0403 0200 0074 44 Send type :49 69000005h> 07:05:55.206 tx 8 | S00 0403 1000 0001 809F 07:05:55.214| |F31E4335 69000025|S00I IN 25589 1serv brc 0410 2092 007B F600 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0022 93 = brc packet inserted in SCC0 07:05:55.222 rx;i 7 | S00 0403 0200 0074 44 07:05:56.207 tx 255 | S00 0410 2092 007B F600 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0022 93 = write to Slave memory, packet is sent to Modbus network 07:05:56.361 rx;i 8 | S00 0410 2092 007B 2A52 = written = acknowledgement message not generated for src address 69000025 07:05:57.208 tx 8 | S00 0403 1000 0001 809F 07:05:57.224 rx;i 7 | S00 0403 0200 0074 44 4. History This description is valid for sw version 574 from 20.5.2002.