Configures a remote message.

 The object describes a data message to or from another system. We can
 communicate with other ProviewR systems or with foreign systems in
 different ways, according to Transport type.

 The RemTrans object must be hierarchically placed directly under the
 RemNode object. The message data is fetched from, or stored into an object
 that is the only child of the RemTrans object.

 For certain messages, you can allow a limited number of buffered messages,
 both for sending and receiving.Buffered sending is used when we don't have
 connection to the remote node. Buffered receive is used if the final user of
 data is not fast enough to treat several incoming messages.

 For certain transports you can use built in acknowledgement for messages.
 Generic class that defines a specific message to or from a specific
 remote node on a specific protocol. Should be placed below the
 RemNode-object. The size of a message to be sent is specified in the
 RemTrans-object. The data to be sent however resides in a buffer that
 is configured as a child to the remtrans-object. When a message is to
 be sent, data of the length specified in the remtrans-object is fetched
 from the buffer. Sometimes however a header of some length is added to
 the message.

• RemoteConfig
• RemnodeALCM
• RemnodeModbus
• RemnodeMQ
• RemnodeRK512
• RemnodeSerial
• RemnodeTCP
• RemnodeUDB
• RemnodeWMQ

Optional description.

 For most transports this is only documentation.
 For ALCM sending messages you must store receiving task
 name (6 characters) here.
 For ALCM receive you store message id (6 characters) here.

Message address. Used different for different transports.

ALCM
Not used

PAMS
[0] - Class (0 - 255)
[1] - Type (0 - 255)
[2] - Processnumber for receiver (Only if we are sending)

DMQ
[0] - Class (0 - 255)
[1] - Type (0 - 255)
[2] - Processnumber for receiver (Only if we are sending)
[3] - Used in DMQ to control delivery mode for outgoing
      messages:
0 Use delivery modes WF_DQF and SAF
1 Use delivery modes NN_MEM and DISC
2 Use delivery modes WF_DQF and DISC
The WF_DQF delivery mode delivers the message to the remote
recovery journal and blocks for verification or timeout.
The NN_MEM delivery mode delivers the message to the
destination queue and doesn't wait for any verification at all.
The SAF function puts the message in the local recovery journal
if the link is down. When using SAF, DMQ handles the
retransmission meaning that we (ProviewR) can forget the
message and treat it as sent. This works on DMQ 3.2 but is not
supported in the earlier version 3.0.
The DISC function tells DMQ to discard the message if it isn't
deliverable. Can be used with WF_DQF along with the remote
buffering mechanism.
For a deeper description of delivery modes, consult the DMQ
documentation.

3964R - VNET
[0] - First 3 letters of Trans name / Task name in RAD50
[1] - Next 3 letters of Trans name / Task name in RAD50

3964R
Not used.

RK512
[0] - Address High byte (0 - 255)
[1] - Address Low byte (0 - 255)

TCP/ip and UDP/ip
[0] - Message address part 1 (0 - 65535)
[1] - Message address part 2 (0 - 65535)

QCom
[0] - Message address (0 - 255)

MODBUS
[0] - Slave address
[1] - Function code

Serial
[0] - Ascii number (decimal) for termination character #1
[1] - Ascii number (decimal) for termination character #2
[2] - Ascii number (decimal) for termination character #3
[3] - Used to set the use of 7 or 8 bit character length. Set a value
      of 1 to use 7 bits and a value of 0 to use 8 bits.

MQTT
[0] - Message address
[1] - Message address
[3] - 1 specifies retain for published messages.

RabbitMQ
[0] - Message address
[1] - Message address
[2] - Delivery mode. 2 is persistent, otherwise transient.
[3] - First bit: keep all messages. Second bit: keep message order.

Direction. Receive (1) or Send (2).

Number of Bytes in message data. For outgoing messages this
parameter must be set, either statically in the development
system or dynamically via an application, before sending the
message. For incoming messages this parameter is set by the
transport when each message is received and shows the received
length of this message.

Each message can be logged to file by specifying a LoggLevel.
0: No logging.
1: Logging of time, message lenght and status when an error
   has occured.
2: Logging of time, message lenght and status for every message.
3: Logging of time, length, status and the first 48 bytes
   in hexadecimal code.
4: Logging of time, length, status and the whole message
   in hex code.

The log-file is configured with a LoggConfig object with
Identity set to 90.

If MaxBuffers is > 0, send messages will be stored if the connection
is down, and resent when the connection is up again.

MaxBuffers is the maximum number of stored messages.

In Remote UDP, when the message is outgoing, a value > 0 indicates
that the message should be sent with wanted acknowledge.

 When set, old messages in the outgoing buffer are replace by new ones.
 This can be used for cyclic transactions and ensures that the outgoing buffer
 is not filled with obsolete messages in times of bad network.
 Only implemented for QCom.

Current number or stored messages.
For incoming messages this indicates the number of messages waiting
to be taken by the PLC-process. For outgoing messages it tells the
number of buffered messages waiting to be acked.

Size of data receiving object, or data sending object.
RemTrans can't handle messages bigger than this. Messages
exceeding this size will be discarded.
The attribute is updated by the transport and should be left
blank in configuring.

Status of last transaction.

1: Success.
3: Receive data has been buffered.
0: Send failure.
2: Data length exceeds buffer object size.
4: Receive data has been lost.
6: Waiting for acknowledgement on message with auto ack.

Transaction time for last received or sent/buffered message.

Number of successful transactions since start or restart.

Number of messages sent/received through buffering since start
or restart.

Number of received messages that were lost because they
couldn't be buffered.

Number of send failures.

Flag for new data in data-object.

When we receive a new message, it is stored into the data-object.
Then the DataValid is set. The next message can not be stored
before the final user has treated this message, and then reset the
DataValid signal. When using RemTransRcv in the PLCprogram,
this is handled automatically.

When the original sender want to send a new message, he fills in
the data, and then sets DataValid. The Remote transport will
search for DataValid set, and send the message and then Reset
the DataValid. Next message shouldn't be filled into the data
object before the DataValid is reset. When using RemTransSend
in the PLC-program, this is handled automatically.

C struct name for the message.
When a StructName and StructFile is supplied, the content of
buffer object can be interpreted and displayed in accordance with
this struct from System/Communication/RemTrans in rt_xtt.

C include file that contains the struct specified in StructName.
Default directory is $pwrp_inc.