UDP datagram protocol does not provide a reliable connection inherently -- thus the 7526 and its controller/server machine provide the reliability (detection of missing or duplicated packets) via a modified 1283 protocol. These modifications also allow the 7526 to operate in a non-polled mode.
The modified 1283 protocol implements two separate message types: unsolicited and command/responses (hereafter 'commands'). Commands and their responses are completed synchronously; a second command is not issued to a terminal until the response to the first command is received or a timeout occurs. Unsolicited messages from the terminal can occur at any time. These messages include transactions, download requests (DC1) and 'I-am-here' (DC2) messages.
Note:
This use of the DC2 character is different from its use in the standard 1283 protocol where it represents a request for download of a terminal's operating system (e.g. 7527 requesting load of Extended Terminal Services).Using standard 1283 protocol, transaction and commands are distinguished via the polling mechanisim. The terminal controller specifically requests transaction data by issuing a poll; since the DCT always responds with data or NAK (or DC1 to request a download), polls are immediately concluded and commands may therefore be issued at any time.
Eliminating polls and allowing unsolicited messages means that there is no longer any method by which the terminal controller can determine if data received from the terminal is transactions data or a response to a command. Furthermore, it is possible for transaction data to be queued ahead of a command response, prohibiting the data collection controller software from reading the command response it expects. These potential problems are overcome as described below under "Logical Channels".
The poll, however, is also the means used by a 7526/RS-485 terminal to request a load of the RAM files in the case that they are not present in the terminal. Since polling is not used by the 7526/Ethernet terminal, the following mechanism is used to ensure that files are loaded when necessary.
When the controller first starts up, it issues J9 commands to all terminals that are configured in the TCP/IP network. If a terminal is already powered on and in range, it will receive the message. In response the terminal will send an ACK response to the controller. The controller should then perform its startup sequence with the terminal. One step in that sequence should be to send an A1X command to the terminal. This command tells the terminal it is allowed to send unsolicited messages. It is at this time that the terminal would send DC1 to the controller if it requires RAM files to be loaded or a DC3 to simply indicate that it received the A1X.
If a terminal was not powered on at the time that the controller software started up, the terminal will send the DC2 message when it is powered on. The controller and terminal would then engage in the startup sequence.
The intial set-up of the 7526 for Ethernet connection includes setting its IP address, the IP subnet mask, and the IP address of a default router. The terminal does not know the IP address or UDP socket of the controller/server, and hence cannot send DC1 or DC2 characters out requesting download or indicating that it has started. It learns the IP address and open socket number of the controller/server from the first packet to arrive which is properly addressed to its own IP address and UDP socket number 7500. The 7526 also will check the controller/server's IP address and UDP socket each time it receives a packet and will respond (and send unsolicted transactions) to the last address given it by a controller/server. Each time the 7526 learns that it has a new controller/server sending it commands, it will send a DC2 transaction (a DC2 character wrapped in a transaction record) to the controller/server.
The 7526-E will only request a file load when the RAM files are missing or are not complete and therefore are needed. This avoids a file reload each time the 7526-E is powered off and on again. In addition to the terminal's ability to request a download, the data collection controller can choose to reload the RAM files at any time - usually at the request of someone operating the data collection controller.
To implement the two logical channels over the single TCP/IP line, an additional header is added to the front of each message which specifies its type as either the command or unsolicited. Only one header character is added. All 7526/Ethernet traffic on the TCP/IP network must have this additional header character. The convention of ASCII 'X' for transactions and other unsolicited terminal messages has been established. The controller responses to these unsolicited messages must also use this character. An ASCII 'C' is used for commands initiated by the controller and the terminal responses to those commands.
The data collection controller must use the header byte to determine what type of message it has received. The terminal does the same. Without the header the messages look the same as they do in the standard 1283 protocol.
Present 1283 Protocol Modified 1283 Protocol Command 'C' Command Response 'C' Response Poll Eliminated Transaction 'X' Transaction from terminal ACK (acknowledge receipt of tx) 'X' ACK from controller
The host command 'A' is already used to put terminals In Service (A1) or Out of Service (A0). This controlled whether or not terminal users were able to run transaction programs to create transactions. These commands have been expanded to include the following possible values:
A0X - Disable Transmission of Unsolicited Messages (flow control off) A1X - Enable Transmission of Unsolicited Messages (flow control on)These commands fall into the 'command' category and are thus preceded with the 'C' header character. However, the A0X command is unique in that it does not elicit a response from the 7526 terminal. The A0X command can be used in the case where a terminal sends a transaction and the controller is not ready for it. This could occur right after the controller sent out a command to that terminal but before the response from the terminal came back. The following sequence illustrates this case:
==> C 5 Command to beep the terminal <== X transaction Terminal sent up transaction at same time ==> C A0X Controller does not want transactions now ==> X NAK Transaction NAKed so that terminal will later resend it <== C ACK Response to the beep command by the terminalIn the above sequence, there are really two outstanding commands to the terminal at the time that the C A0X is issued. Since the A0X will not generate a terminal response, the controller can be sure that the C ACK that is received later is for the beep command.
The A0X and A1X cross the boundary between the command channel and the unsolicited channel which is why these commands have characteristics of both. They are initiated by the controller which is true of all commands. However, they do control the flow in the unsolicited channel. The protocol has been set up such that if an A0X or A1X command is lost, no transactions would be lost and no synchronization problems would result.
Commands A0X and A1X toggle an internal terminal state flag called the 'transaction flow control' flag. When a terminal is first powered on, this flag defaults to off. Only when the controller sends an A1X command will the flag be turned on. At that time the terminal can begin sending transactions, if it has any, or request a download of RAM files, if it needs one.
Note:
The unsolicited DC2 message is not governed by the transaction control flag. Whenever the terminal is powered off or loses communications with the controller and then regains it, it will send an unsolicited DC2 message to the controller to let it know that it is now communicating again.When an A1X command is received by the terminal, the flag is turned on. If no transactions are waiting to be sent and the terminal does not need a download, nothing more is done. If a download is needed, the terminal sends an unsolicited DC1 message to the controller. If there are transactions in the transaction queue, the first one is sent to the host, even if it has already been sent before (see below for more about this situation).
When an A0X command is received by the terminal, the flag is turned off. This does not cause any immediate action to take place in the terminal; rather, it determines what the terminal will do when the next transaction release command is received or when the next transaction is generated in the terminal.
When the terminal generates a transaction, what happens next depends on the flow control flag and whether there are transactions currently in the terminal's transaction queue. If there are transactions in the queue, the new one is added to the end of the queue. Otherwise, if the flow control flag is on, this transaction is sent to the controller. If the flow control flag is off, this transaction is stored in the terminal's transaction queue.
When a transaction is successfully released in the terminal and there are transactions in the terminal still waiting to be sent, the flow control flag determines what to do next. If this flag is on, the first transaction in the queue is sent. If this flag is off, nothing is done with any of the buffered transactions.
If the terminal has just sent a transaction to the controller and that transaction has not yet been released, and then the terminal receives an A0X command followed some time later by an A1X command with no transaction release in between, the same transaction is sent to the controller again when the A1X command is received.
If, however, a transaction release command is received after the A0X is received but before the A1X, then the transaction is released from the terminal. When the A1X is received, that released transaction will not be resent because it no longer exists. In this instance, the next transaction sent to the controller is the next one in the queue following the one that was just released - if there are any.
Below is a description of transaction data/response flow, including the actions in some error conditions. As used below, <== means 'from' the terminal and ==> means 'to' the terminal.
The initial state of these examples has the controller ready for unsolicited transactions, and the terminal's flow control flag is on. No transactions are currently in the queue and a new transaction has just been generated at the terminal.
<== Xtransaction Transaction is sent by the terminal ==> XAck Transaction received at controller, but must not be released from the terminal yet. or ==> XNak Transaction received but the checksum failed. This is an implicit request for the terminal to resend the transaction provided an A0X command was not issued by the controller in the mean time.If at this point the terminal generates more transactions, they are queued in the terminal behind the one that is waiting to be released.
When the controller has successfully stored the transaction and is ready to release it, the controller sends the transaction release command (CMD K) which specifies the sequence number of the transaction being released: nnnnn. The terminal will respond to the release with ACK or NAK indicating whether the release was successful (sequence number matches the first transaction in the queue).
==> CKnnnnn Release transaction with sequence number 'nnnnn' <== CAck Sequence number was correct; transaction is released or <== CNak Sequence number was not correct or other error occurred with the release. Transaction remains in the terminal. Controller should resend release or send A1X to have the first transaction sent again.The sequence number in the CMD K normally must match that of the first transaction in the queue in order for it to be released. However, if the sequence number in the CMD K is set to 'XXXXX' then the first transaction in the queue should be released no matter what.
If the release is successful and there are other transactions waiting in the terminal, and the flow control flag is on, the first will be sent and the above scenario will be repeated.
If the release was not successful, the terminal will not do anything with the transaction unless it receives one of the following commands:
- Another release command - will try to process as before - An A0X command - the terminal will turn off its flow control flag but will still leave the first transaction in the buffer for when A1X is next sent from the controller - An A1X command - the first transaction will be sent to the controller againEach time a transaction is sent to the controller, the terminals starts an internal timer in case it does not receive CMD K in response for that transaction. If no response is received before the timer expires, the transaction will be resent (provided an A0X command was not received by the terminal in the meantime).
If no ACK or NAK is received for the transaction, and a transaction release is received before the timer expires, the transaction will still be released from the terminal and operation continues as normal.
Likewise, when no response is received for a transaction and an A0X command is received followed some time later (but within the Timer A host communications timeout period) by a transaction release, the transaction is still released and operation continues as normal.
The 7526 takes the sequence number from the received command and puts it into the response message. This allows the controller/server to determine that the response received is indeed the one for the last command/request that it sent out.
The sequence number in the command or transaction also allows the receiver to determine if the message received is a duplicate. If it is a duplicate, the receiver can resend the last response or simply generate a new response.
The message sequence number maintained by both sides should start at 1. The value 0 is used for messages that do not get a response. The message sequence number increments for every unique message. These statements apply to both the terminal side and the PC side.
The message sequence number is an unsigned long (32-bit) integer which increments for every unique message sent. The sequence number is transmitted in network byte order in the message (meaning highest-order byte first -- Intel-based controller/server machines will need to reverse the order of the bytes before transmitting or checking the values).
Whenever the PC software (e.g. DCC/2) starts up it will set to 1 the message sequence number that it will send out for every terminal. A message sequence number of 1 has special meaning for a terminal. When the terminal sees that message number, it is will reset its 'last message number from PC' value for all command type to 1 as well. The PC side will keep the message sequence number at 1 until it receives a response to that message from the terminal. In this way, the PC knows when the terminal has reset its message sequence number to 1.
With the above PC rules, the terminal can determine a duplicate using a very simple set of rules. Let's assume the terminal is maintaining a value called 'lastPCseq' which is initialized to 1 on a cold-start. There are 4 situations when the 7526 terminal will change the 'lastPCseq' value:
No Response ACK/NAK Response Other Response ---------------------------------------- Command Command Command OK to Reprocess? ----------- ---------------- -------------- ---------------- 0 2 1 - Status Yes AnX 4 3 - ROM Vrsn Yes *4 5 6 - Features Yes 8 7 - TOD Yes 9B 9A - File Stat Yes 9C 9F - Part of File Yes 9D F - Storage Query Yes 9E J9 - Term Config Yes * Response 9G L - Loopback Yes to time A MA - CFR status Yes request B MB - Init CFR No C NA - Start val file Yes D Q - Read user Var Yes E G I IM K MC MD NB NC ND O P R VThe 7526 saves the last response (ACK/NAK) for each of those commands in the 'ACK/NAK Response' column. For all but one of the commands in the 'Other Response' column its simply lets them be processed as if they were not duplicates. For the one exception, the MB command, the 7526 saves its last response text and resends it.
For MB and all the commands with the ACK/NAK response, the 7526 saves
When the message is received by the terminal, if it is determined not to be a duplicate, the command is processed and the 1000 is taken from the input message and is put into the Ack message that is sent back to the controller/server.
Back on the controller/server side, it is waiting for the response to the beep command -- up to some timeout period. If, during this period, it receives response messages from the terminal 1.2.3.4, it will only consider the response message to be the one for the beep command if it has 1000 as the message number. It is possible that the controller/server might receive response messages from terminal 1.2.3.4 for which it had previously timed out on when waiting for the response. All of these messages would have sequence numbers earlier than 1000. These should all be thrown away by the controller/server.
As for terminal-initiated messages, only transaction messages expect a response from the conroller/server. Note these terminal-initiated messages are on the X channel described earlier in this document.
The use of the message sequencing number for a transaction is the mirror situation to what was just described for the beep command. Suppose terminal 1.2.3.4 needs to send a transaction to the controller/server and its outgoing-message-sequence-number is currently 500. The terminal will put that sequence number into the transaction message and send it to the controller/server.
When the transaction message is received by the controller/server, it takes the 500 from the input message and puts it into the ACK message that it sends back to the terminal.
Back on the terminal side, when the terminal receives messages from the controller/server it will only consider a message to be a response to the transaction if it contains the message sequence number 500. Any message on the X channel with a sequence number other than 500 would be ignored.
One exception to the above is that any message sent from either side for which a response is not set, the message number should not be incremented, a value of 0 should instead be used for the message number in this case. The following example illustrates why this is necessary (the elapsed time in this scenario is 0.3 seconds):
If the controller/server sends out a beep command with the message number 1000 to terminal TERMA at the same time the terminal sent an I-am-here message (DC2) due to the fact that it had just powered on. When the controller/server receives the I-am-here message it is still waiting for the response to the beep - but it is also supposed to send an A1X command to the terminal to tell it that it is allowed to send transactions. The A1X command is not responded to by the terminal so it should be able to send it out right away. It will send the A1X but it should not increment the message sequence number because the controller/server is still waiting for the response to the beep. When the terminal receives the beep command, it returns the ACK response with the message number 1000. When that response gets back to the controller/server it is able to match up the message number 1000 in the message with the value it is maintaining. Because the A1X did not increment this message number, it matches and the beep command completes successfully. From the controller/server side, the following commands, which do not receive responses, should always use 0 for the message sequence number:
The UDP datagram formats are::
SSSS, C, STX, addr, addr, text, CS1, CS2, ETX
SSSS, C, STX, text, CS1, CS2, ETX
SSSS, C, ACK SSSS, C, NAKWhere: