Payload is an array containing the measured values. The list can contain multiple types of objects. Each type belongs to a specific event coming from the SINUMERIK Connector.
Consider that the order of the objects inside the list is determined by the time the data arrives.
The following example shows JSON objects in Payload:
"Payload":[<arrayofHFTimestamp|HFData|LFData|HFBlockEvent|HFCallEvent|ExternalDataobjects>]
HF Block Event
HF-Block objects provide reference to the original NC program. However, only G-code which affects movement will be considered. This object delivers further information of a given executed G-code.
When multiple files are recorded for a single job, the last HF Block Event object of the previous file will be repeated on the beginning of the new file.
The following table shows the HF Block Event structure:
Field name |
JSON datatype |
Valid from output version |
Description |
|---|---|---|---|
HFProbeCounter |
Integer |
0.6 |
Position clock cycle. Aka.: tick E.g.: 3214 |
SeekOffset |
Integer |
0.6 |
NC code line number. E.g.: 1421 |
Channel |
Integer |
0.6 |
Id of the channel for this block event. E.g.: 1 |
SelectedTool |
String |
0.6 |
Id of the programmed tool. E.g.: 2 |
ActiveTool |
String |
0.6 |
Id of the active tool. E.g.: 0 |
GCode |
String |
0.6 |
Original NC code that was executed. There is no guarantee that all parts of the NC code in a given line is recorded. The NCK optimizes the NC code. It can remove/add/modify NC code lines during the preprocessing. E.g.: G91 G64 X0.01 F1000. Lines in the NC code, that were not affecting movement, will be missing from the recording. |
IpoGC |
String |
0.6 |
The effective G-code in the first G-code group. E.g.: G91 |
ipoReadError |
String |
0.6 |
OBSOLETE |
laBuf |
String |
0.6 |
Number of blocks that are available in the look-ahead buffer. Corresponds to what can be read from the Synchronous Action variable $AC_IPO_BUF. E.g.: 5 |
Consider the syntax of the HF Block Event:
{
"HFBlockEvent":
{
"HFProbeCounter": <integer>,
"Channel": <integer>,
"SeekOffset": <integer>,
"SelectedTool": <integer>,
"ActiveTool": <integer>,
"GCode": <string>,
"IpoGC": <string>,
"laBuf": <integer>
}
}
The following example shows a possible structure of the HF Block Event:
{
"HFBlockEvent": {
"HFProbeCounter": 234432,
"Channel": 1,
"SeekOffset": 3,
"SelectedTool": 0,
"ActiveTool": 0,
"GCode": "M5",
"IpoGC": "G0",
"ipoReadError": null,
"laBuf": 5
}
}
HF Call Event
An HF-Call object is generated every time the program level is changed. It means that every start and end of subprograms and cycles are documented in this object type. The main program starts with the level zero and only the next eight steps downward are reported. The objects also contains the first 51 signs of the program path or the line number from the program. If the CPU load of the SINUMERIK CNC is high, the path is given in a reduced form, which will be marked by three consequent dots ("...") at the end of the path.
In some cases, like below, no object will be generated (NC-Code):
FOR LOOPCOUNT = 1 TO 10
SUB_PROGRM_CALL
ENDFOR
In the jump back to the main program, the line number does not change and so it will not be reported.
When multiple files are recorded for a single job, the last HF-Call object of the previous file will be repeated on the beginning of the new file.
The following table shows the HF Call Event structure:
Field name |
JSON datatype |
Valid from output version |
Description |
|---|---|---|---|
HFProbeCounter |
Integer |
0.6 |
Position clock cycle. Aka.: tick E.g.: 3214 |
SeekOffset |
Integer |
0.6 |
NC code line number of the subprogram. E.g.: 1421 |
Channel |
Integer |
0.6 |
Id of the channel for this block event. E.g.: 1 |
CallStackLevel |
Integer |
0.6 |
Call stack level. It is determined by line number changes and therefore it may be incomplete. E.g.: 1 |
Path |
String |
0.6 |
Path of the actual subprogram. E.g.: /_N_SPF_DIR/_N_AUTO_CYCLE_SPF |
Consider the syntax of the HF Call Event:
{
"HFCallEvent":
{
"HFProbeCounter": <integer>,
"Channel": <integer>,
"SeekOffset": <integer>,
"CallStackLevel": <integer>,
"Path": <string>
}
}
The following example shows a possible structure of the HF Call Event:
{
"HFCallEvent": {
"HFProbeCounter": 4350616,
"Channel": 1,
"SeekOffset": 5,
"CallStackLevel": 1,
"Path": "/_N_SPF_DIR/_N_AUTO_CYCLE_SPF"
}
}
HF Timestamp
The timestamp is received for certain cycle values only. The corresponding pair of CYCLE(=HFProbeCounter) value and received timestamp is recorded in this separate JSON structure.
The following table shows the HF Timestamp structure:
Field name |
JSON datatype |
Valid from output version |
Description |
|---|---|---|---|
Time |
String |
0.9 |
Timestamp received from the SINUMERIK CNC. The timestamp is provided in an ISO-8601 time format: yyyy-MM-ddThh:mm:ss[.mmm]TZD Timestamp values are always defined in UTC time zone. E.g.: 2020-03-05T00:37:59.623Z |
HFProbeCounter |
Integer |
0.9 |
Position clock cycle. Aka.: tick E.g.: 3214 |
Consider the syntax of the HF Timestamp:
{
"HFTimestamp":
{
"Time": <string>,
"HFProbeCounter": <integer>
}
}
The frequent timestamp values in the following example enable the calculation of relative timestamps for each HF data records more precisely:
{ "HFTimestamp": { "Time": "2023-04-28T09:43:07.583Z", "HFProbeCounter": 32170165 } }
HF Data
The measured signal values for the defined HF data are always in an array. The order of the values match exactly to the order of the SignalListHFData array in the header of the recorded files. Every signal value in the array belongs to exactly one HFProbeCounter value. The CYCLE(=HFProbeCounter) is always the first data in the array.
Consider that values may contain null values if the signal is not available on Sinumerik side or not configured in the SINUMERIK Connector.
Consider the syntax of the HF Data:
{
"HFData": [
[<number>]
]
}
Example
Assuming that the following signal set for recording was configured: DES_POS|1, DES_POS|2, in the header part of the recorded file the configuration can also be found:
{
"Header": {
"SignalListHFData": [
{
"Name": "Cycle",
"Type": "INTEGER",
"Axis": "CYCLE",
"Address": "CYCLE"
},
{
"Name": "CommandedAxisPosition",
"Type": "DOUBLE",
"Axis": "X1",
"Address": "DES_POS|1"
},
{
"Name": "CommandedAxisPosition",
"Type": "DOUBLE",
"Axis": "Y1",
"Address": "DES_POS|2"
}
]
}
}
Consider that the example does not contain the complete header. the important parts are shown for the better understanding of the HF data structure.
The measured data will be written as follows:
{
"HFData": [
[1008284, 0.390625, 0.506592],
[1008285, 0.390712, 0.506643]
]
}
The two elements of the HFData array belong to two subsequent cycles. They themselves are also arrays, as multiple values have been recorded in that cycle. The first element of these measurement arrays is the CYCLE(=HFProbeCounter). Therefore, we can conclude, that the HFProbeCounter's value, at the time of the first measurement, was 1008284.
The second and third values belong to the signals we wanted to record. The second value belongs to DES_POS|1, the third to DES_POS|2. This can also be seen in the header of the recording as well, which is shown in the previous picture. Therefore, we can conclude, that the values of DES_POS|1 and DES_POS|2 are 0.390712 and 0.506643 in the first measurement respectively.
LF Data
LF data is defined by the user of the SINUMERIK Data Recorder application. Each LF data group on the SINUMERIK Data Recorder user interface will appear in the output file in a separate list of LF data objects.
Field name |
JSON datatype |
Valid from output version |
Description |
|---|---|---|---|
HFProbeCounter |
Integer |
0.6 |
Position clock cycle. Aka.: tick E.g.: 3214. Only available for SINUMERIK LF signals, not present for FANUC signals. |
timestamp |
String |
0.6 |
Timestamp field, that is automatically set the moment SINUMERIK Data Recorder application receives an LF variable value. This timestamp is not related to the time settings on SINUMERIK CNC side. It is based on the Industrial Edge system time.. E.g.: 2020-02-24T19:03:47.396Z[Etc/UTC] |
address |
Integer |
0.6 |
Id of the channel for this block event, e.g.: 1. |
value_type |
String |
0.6 |
Type of the data, e.g.: Double. Its value is always “String” since application version 1.0.0 to keep backward compatibility. |
value |
String |
0.6 |
Real value of the LF variable. It can be a text, e.g.: /_N_SPF_DIR/_N_AUTO_CYCLE_SPF or a real/integer number like 213.5671 |
Consider the syntax of the LF Data:
{
"LFData": [
{
"HFProbeCounter": <Integer>,
"timestamp": <string>,
"address": <string>,
"value_type": <string>,
"value": <string>
},
]
...
]
}
The following example shows a possible structure of LF data:
{
"LFData": [
{
"HfProbeCounter": 6284582,
"timestamp": "2020-02-24T19:03:47.396Z[Etc/UTC]",
"address": "recordingServoCounter",
"value_type": "Int",
"value": "6284582"
},
{
"HfProbeCounter": 6284582,
"timestamp": "2020-02-24T19:03:47.396Z[Etc/UTC]",
"address": "vaCurr[u1,1]",
"value_type": "Double",
"value": "0.000000"
},
{
"HfProbeCounter": 6284582,
"timestamp": "2020-02-24T19:03:47.396Z[Etc/UTC]",
"address": "numMachAxes[u1] ",
"value_type": "UInt",
"value": "4"
},
{
"HfProbeCounter": 6284582,
"timestamp": "2020-02-24T19:03:47.396Z[Etc/UTC]",
"address": "progName[u1] ",
"value_type": "String",
"value": "_N_CAPTURE_MPF"
}
]
}
External Data
The content of external data field under output file header is always an empty array. The reason to keep it in output file is to keep backward compatibility.
Consider the syntax of the External Data:
{
"Header" :
"SignalListExternalData": [ ]
}