In this chapter you will find a list of all attributes you need to create a RAP file.
ID | Title | Descpription/Example |
Type | necessary/optional |
A | id | internal ID of the module/device | String | necessary |
B | version | module/device version | String | necessary |
C | comment | internal comment, e.g. for explanations | String-Array | optional |
D | screencomment | Preset comment for the device type, which is displayed in the comment column of the application’s device information table; can be changed by the user for each device. | String | necessary |
E | size | Width of the expansion module; can be used, for example, to determine whether there is enough space on the DIN rail | String | optional |
F | devicetype | Positioning type of the device; determines at which position a device can be inserted (please enter in capital letters)
BASE Connect unit; must be positioned first LEFT module can only be positioned left of the Connect unit RIGHT module can only be positioned right of the Connect unit LEFT_EDGE module can only be positioned on the far left RIGHT_EDGE module can only be positioned on the far right LEFT_RIGHT module can be positioned left or right of the base unit RIGHT_LEFT module can be positioned left or right of the base unit VIRTUAL virtual device – is automatically placed into the virtual device area. |
String | necessary |
G | producttype | Unit number of the KUNBUS product line | Num | necessary |
E | input / output / memory | Actual operating data (‘ attributes’) of the device which are modified during operation; a data declaration consists of the following values (E. 1 to E. x) described below. Both input, output and memory array must be present in the file – but allowed to be blank ([]) | Objekt-Array | necessary |
E.1 | name | Name of the value WICHTIG: blanks in the name will be replaced by underscores when reading the file! Avoid blanks as far as possible. |
String | necessary |
E.2 | type | DIN61131 data type; e.g. BOOL, BYTE, WORD; in capital letters | String | necessary |
E.3 | range | Validity area of the value input; depending on the type, plausibility checks or predefined drop-down lists are generated from this. Each’ range’ entry consists of two subentries following this pattern:
“range”:{ Available type/values combinations, see E.3.1 to E.3.3 |
Object | necessary |
E.3.1 | Range type 01: loop |
Creates a drop-down list from the loop values defined in the ‘values’ array, e.g. “values”: [0,10,1.5]
Creates a drop-down list with values from 0 to 10 with step size 1.5 ( 0, 1.5, 3, 4.5, 6 … etc.) |
– | – |
E.3.2 | Range type 02: tooltip_loop |
Creates a normal text input field that displays the valid value range in a tooltip when touched with the mouse; the value range is checked after input and generates an error message if entered incorrectly. | – | – |
E.3.3 | Range type 03:
list |
Generates a drop-down list from the value constants defined in the values array::
“values”: [ The entries in front of the “|” symbol are displayed as readable text in the dropdown box, the entries behind the “|” symbol are exported as actual work value. |
– | – |
F | default | Default value of the attribute; Important: please make sure that it is within the value range defined with’ range / values’! When using ‘list’ range type the value must be after the ‘ |’ separator!! | String | necessary |
G | unit | Text string that describes the unit of the attribute value; appears in the’ Unit’ column of the editing table; if its left blank, the data type is displayed as a unit. | String | optional |
H | tags | Any arbitrary descriptive text tags of the attribute; however, at least the attribute area (‘ input / output / memory’) and the’ type’ of the attribute (bool, byte, word etc.) must be specified, separated by commas!
Note: The range and type of the attribute are stored redundant in the tags for easier and more efficient processing of the RAP file. THEY SHOULD NOT BE IN CONTRARY TO THE TECHNICAL AREA/TYPE DETAILS! |
String | necessary |
I | edit | Edit mode of the attribute; determines which part can be entered or changed by the user; valid here are values between 0-4
neither name nor value of the attribute can be edited Value line is not displayed in the edit table (for constant, unchangeable values that should not be displayed to the user) |
String | necessary |
J | order | Sort order, i. e. relative position in the edit table display; here any numeric values with gaps can be entered, which then lead to an ascending sorting, e. g. 10,20,25,99 etc. NOTE: please do not use values twice, otherwise the sorting will lead to unpredictable results. | No. | necessary |
K | offset | Memory offset of the attribute; first attribute of the device starts at’ 0′; in order to ensure correct continuous assignment of the offsets, please enter the appropriate offset distance to the next attribute depending on the value type (‘ type’ entry, e. g. BYTE), Example:
“name”: “Input01”, Input01 occupies the bytes 0 and 1 as WORD value; the offset of Input02 therefore starts with byte 2.… etc. |
No. | necessary |
L | multi | Integer value from 1 to n; generates the desired number of multiple attributes from the attribute (primarily to save redundant data entry for many similar or related values); a sequential number is appended to the name of the attribute, for example:
“name”: “Input01”, … creates attributes Input01_1 to Input01_3 Important: If no “multi” value is set, the default value is 1. If no multi value is defined for BOOL values, the multi value is automatically fixed to’ 8′ when reading RAP files internally, in order to set them to byte limits. A multi value in the file overwrites this default setting – make sure to define only multiples of’ 8′!! |
No. | optional |
M | active | true or false; defines whether an attribute value is taken into account at all when reading the RAP file or not. This enables you to completely deactivate attribute values. | Bool | optional |
N | export | true or false; determines whether or not the attribute value in the Export column of the editing table is selected for export by default. | Bool | optional |
O | colorEdit | Hex color code between #000000 and #ffffff; sets an individual background color for the editable input field; if this value does not exist, the default value from the config.json file is used. („colors“:{colorEdit … | Hex-color | optional |
P | colorReadOnly | Hex color code between #000000 and #ffffff; sets an individual background color for a NON-editable (read only) input field; if this value does not exist, the default value from the config.json file is used. („colors“:{colorReadOnly … | Hex-color | optional |
Q | colorTextEdit | Hex color code between #000000 and #ffffff; sets an individual text color for the editable input field; if this value does not exist, the default value from the config.json file is used („colors“:{colorTextEdit … | Hex-color | optional |
R | colorTextReadOnly | Hex color code between #000000 and #ffffff; determines an individual text color for a NON-editable (read only) input field; if this value does not exist, the default value from the config.json file is used. („colors“:{colorTextReadOnly … | Hex-color | optional |
S | Variant-specific | To create a variant hierarchy (see 4.) the following additional entries are required after an input / output entry:
“variants”: [ The variants “id” will be displayed in future versions of’ PiCtory’ for variant selection. Here you should enter a descriptive text which must be UNIQUE. „isDefault“ specifies the default variant after the RAP file has been imported into PiCtory. Please pay attention to the defined rules and consider them when setting ‘isDefault’. PiCtory currently applies the rules only if the user changes the variant manually and cannot resolve contradictions with ‘isDefault’ entries! Within the “data” array, the ‘normal’ input/output attributes are entered again, as they would be done without variants. PLEASE NOTE: by using variants, the type of an input/output entry changes from array to object (rectangular brackets to curly brackets), e.g. “input”: [ … to “input”: { … |
Array | optional |
T | lang | To enable internationalization of the value display, the names (labels) of the working values are used as pointers to the corresponding national designations. If a label entry begins with the prefix:’ lang_’, it is interpreted as a pointer. Without this prefix, the value is stored in the display as specified..
Example: internationalization area “lang”:{ Rendering in the value editor if German language is set: Eingang: 8 |
Object | optional |
rules
|
Contains the RAP file variants for both input and output entries and can be used to create a logical link between input and output variants by specifying’ rules’. This causes’ PiCtory’ to automatically’ synchronize’ the linked variants, for example, as soon as a variant is selected. Example:
“rules”: { In this example, the 0th input and the 0th output variant, as well as the 1st input and the 1st output variant are linked. If the user changes the input to variant 1,’ PiCtory’ automatically changes the output to variant 1. If output is then reset to 0, the input automatically jumps back to 0. |
Object | optional | |
include | To integrate data definitions created by external configuration tools, the contents of an input, output and memory block can also be read from an external file at runtime (where’ PiCtory’ reads in a RAP file). A corresponding block has to be encoded like this:
“input”: Note the following points: The contents of the include file must be in JSON format.; it replaces the „input“ object-block {} completely, that means, it is NOT only added into the object block at the place of the “include” entry. This means that the include file for a normal (non-variant) content must contain the square brackets of the array, Example: [ And in case of a variant definition, it must look like this: { |