menu

Scope of this article

This article describes a data protocol which several devices and software modules of KOMET Brinkhaus use for an online data exchange of messages and data streams.

This protocol is opened here, to allow you an easy inclusion of KOMET hardware into your measuring infrastructure.

Usage of the protocols

The below described protocol is used by:

  • The transmission layer between software modules for data acquisition and data processing of the KOMET product ToolScope. This leads to the fact, that you can connect to an always open server socket on the ToolScope and retrieve its measuring data.   

    You can decouple and read measuring data digitally from your device. This possibility is especially meant for the integration of your own monitoring- and control algorithm.

  • The remote access driver of the ToolScope (which reads sensor data from other instances).
  • The software TSVNCC, which is installed on an HMI (and which is able to read data from the control).

Control connection protocol

The ToolScope offers a TCP/IP server as open socket on the port 2100. After you connected to this socket, you have a control connection. With commands on this connection you can e.g. request the start of a data connection and retrieve messages from the ToolScope.

Command "EnableTCPonlyConnection"

For communicating only over one TCP connection, send "EnableTCPonlyConnection" followed by „enter“.

The ToolScope will now send "activeTCPonlyConnection" followed by „enter", if the ToolScope version supports this function and set it to true. Older versions of the ToolScope will not react to the command. It is recommanded to wait ~500 ms (depending on the connection speed) after sending the "EnableTCPonlyConnection" command. If there is no answer assume that the ToolScope did not activate the function for some reason.

While it is possible to switch into this mode while receiving data, it is no recommended doing so.

Command "SendDataDescription"

The format of the measuring data can be requested via this TCP/IP-connection by sending „SendDataDescription“ followed by „enter“.

The ToolScope now sends back „GetDataDescription“, followed by „enter“. Hereafter it will send a data description in form of a table. The table has rows and columns. The information in each column describes a column in a later transmitted real time data stream.

The rows are encoded as follows:

  • Type of data source (general) - possible contents: "Machine control" / "Analog inputs" / ...
  • Axis name - possible contents: "Spindle" / "X" / "Y", "Z"
  • Signal name - possible contents: "Torque" / "Trigger" / "Program" / ...
  • Signal unit - possible contents: "Nm" / "mm" / "0/1" / ...
  • Signal type - possible contents: "Double" / "String32" / ...
  • Empty line
  • Empty line

Command "StartUDPTransfer"

To be able to receive the actual measuring data, a UDP-connection is necessary. This will be initialised by sending „StartUDPTransfer“ (followed by „enter“) followed by a port number as ASCII-Text (followed by „enter“) via the control connection. This port number can be freely chosen. The ToolScope will now send the running measuring data as UDP-datagram to this port number of your computer.

Command "StopUDPTransfer"

After this command, you have to transmit "enter".
The UDP transfer, which was opened from the control connection is stopped. If other control connections started UDP streams to a different location, their streams are not affected.

Command "StartCommandLoopback"

After this command, you have to transmit "enter".

This command, when sent into a control connection, configures the ToolScope who gets this command to send all from monitoring methods to drivers, which come from one of the open control connections, in this connection, too.

This is a very powerful possibility of receiving events from the monitoring methods in realtime. It enables to directly listen on the internal "message bus" of a ToolScope. All messages from the monitoring methods to the PLC are transmitted by this system. If you listen here, you can e.g. more commands as you regularly get into a machines PLC. The PLC messages (breakage alarm, wear alarm, etc.) are only a subset of the information which is transmitted on the bus.

Commands are formated like this:

  • String "PRIO", followed by an priority which always has for numeric digits, followed by an underscore

    This leads to the fact that all command strings have a prefix with a priority. If you have 20 unprocessed commands, you can sort your array of commands with a standard string sorting algorithm. Afterwards the command with the highest priority is the fiest in your array.
  • Markers, followed by an argument; if there is a marker after an argument, this argument is followed by an underscore

    Defined markers:
    • ACTION: alarm number of a message

      The numbering code is the same as the PLC message numbering codes as they are described in the service manual.
       
    • CHANNEL: channel number of the monitoring method which generated the alarm

      Counting starts at channel "1"
       
    • CONTROLCHANNEL: channel number of the control channel to which the monitoring channel belongs, which generated the alarm

      Counting starts at channel "1"
       
    • OVERRIDE: override value which was calculated by a ToolScope channel

      The override is transmitted in percent. "100" means "100%". Only channels, which have the task to calculate override values (such as AFC), transmit this command.
       
    • TOOL: tool name which is linked with the command (mostly: currently used tool)

      The argument type of "TOOL" is "String". See below, how strings are encoded.
       
    • TIME: time stamp in milliseconds since "epoch" (1970/1/1)

      This time stamp is mostly not the time stamp where the command string was generated. Indeed it is mostly the time stamp at which the data was measured which resulted in the command.
       
    • TARGETVALUE: target value for an AFC

      The value is given in the unit of the sensor signal which the AFC monitors.
       
    • PFACTOR: P-factor of the control for an AFC.
       
    • MAXIMUMLIMIT: Maximum limit of a monitored value

      The value is given in the unit of the sensor signal which the corresponding monitoring method.
       
  • Strings are encoded in a special way.

    Letters from [a-z, A-Z, 0-9] are written directly. All other characters are written as a 16bit unicode codepoint. If a unicode letter consists of several codepoints, they are written one after the other.

    If such a 16bit-codepoint has to be encoded, a starting minus ("-") is written. Then comes 'A'+lowest 4bits, 'A'+bits 4..7, 'A'+bits 8..1, 'A'+bits 12..15. After parsing such a character, you have to begin again with the check of the next digits. If it is between [a-z, A-Z, 0-9], treat it as direct letter, otherwise as codepoint. If instead of a letter a '_' comes or the string ends, the argument is read completely.

Examples:

  • PRIO00012_ACTION19_TIME1490687349801

    Monitoring has been switched on.
     
  • PRIO00007_ACTION9_CHANNEL2_CONTROLCHANNEL1_TIME1490688324127_tool-ECAA-ICAATechnicalDictionary-OCAA26-ECAA-JCAA-KDAA-ACAA7007

    Monitoring channel 2, which is obviously part of control channel 1 tells that a monitoring has been started. The tool identifier is "$(TechnicalDictionary.26$): 7007". There "$(TechnicalDictionary.26$)" is our language independent code which becomes "Tool" in English. So the tool identifier when the monitoring was started was "Tool: 7007".
     
  • PRIO00000_ACTION1_CHANNEL1_CONTROLCHANNEL1_TIME1490693890592_TOOL-ECAA-ICAATechnicalDictionary-OCAA26-ECAA-JCAA-KDAA-ACAA7006

    Monitoring channel 1, which is obviously part of control channel 1 tells that a tolerance range has been violated. The tool identifier is "$(TechnicalDictionary.26$): 7006". There "$(TechnicalDictionary.26$)" is our language independent code which becomes "Tool" in English. So the tool identifier when the monitoring was started was "Tool: 7006".

Command "StopCommandLoopback"

After this command, you have to transmit "enter".
The command loopback, which was opened from the control connection is stopped. If other control connections started command loopbacks, their streams are not affected.

Data stream format

The UDP data comes in UDP packets. The frequency is the data processing frequency of the ToolScope. The packet size is dependant on the number of channels and the type of channels.
Each transmitted numeric value is stored as IEEE-double and takes 8 bytes.
Each transmitted String is stored as zero.terminated string in a fixed array width of 32 bytes.
The values are stored column by column in a row in the packet as they were described by the answer on the command "SendDataDescription".

If communication over only one TCP connection i active, the data are send via a TCP packet with the same format as the UDP packet.
Before every TCP packet with data will the ToolScope send "GetData" followed by a "enter"