182
PR-23 instrucon manual
12.5 Collecng data via Ethernet
The main purpose of the Ethernet connection is to collect measurement data from the
instrument. For this data acquisition, you’ll need to have suitable software on your
computer. One solution is to get the software package from K-Patents. The package
contains a ready-to-use data acquisition program for Windows 2000/XP/Vista.
However, if you need a tailored system, you can also program a downloading facility
yourself following the speciications below.
Note: K-Patents guarantees that the speciications are correct, but cannot assume any
responsibility or provide support for other software than the unmodiied K-Patents
software.
12.5.1 Communicaon protocol
The communications protocol is based on UDP/IP to port 50023. It is a client/server
protocol, where the DTR is the server and thus only sends information when the client
(i.e. your computer) requests it. The server should answer to all requests within ive
seconds (5000 ms) from the request, usually the response time is below 100 ms.
Request format
The client to server communication, i.e. the requests sent from your computer to the
DTR, is in binary format. The request packets contain the following binary data (all
integers are in the network order, MSB irst):
− 32-bit integer: packet number
− 32-bit integer: request ID
− (any): request data (depends on the request)
− (any): ill-in data
Important: The maximum size of the message is 1472 octets (bytes).
The packet number is echoed back by the DTR, but not processed in any way. The
packet numbers do not have to be sequential, any 32-bit value is valid.
The request ID is a 32-bit value that identiies the requested function, for example
sensor information. See Section 12.5.2 for request IDs.
The request data consists of 0 to 1464 octets of additional data associated with the
request.
The ill-in data can be used to increase the number of octets in a message. Any num-
ber of NULL characters (0x00) may be added to the end of the request as long as the
total size of the message does not exceed the maximum of 1472 octets. This may be
useful, for example, if the client implementation uses ixed-length packets.