List of Available JSON Attributes

A

id

Internal ID of the module/device

String

necessary

B

version

Modules / devices can exist in different versions (all versions have the same ID, but differ in the version number).

String

necessary

C

comment

Internal comment, e.g. to explain the file content

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 the position where a device can be inserted (please enter in capital letters).

BASE Base unit; must be positioned first.

LEFT Device can be positioned only LEFT of the base unit.

RIGHT Device can be positioned only RIGHT of the base unit.

LEFT_EDGE Device must be positioned as LEFT termination device.

RIGHT_EDGE Device must be positioned as RIGHT termination device.

LEFT_RIGHT Device can be positioned LEFT or RIGHT of the base unit.

RIGHT_LEFT Device can be positioned LEFT or RIGHT of the base unit.

VIRTUAL Virtual device – is placed automatically to the right in the virtual device area.

String

necessary

G

producttype

Unit number of the KUNBUS product line

String

necessary

E

input / output / memory

Actual operating data (“attributes”) of the device that are modified during its operation; a data declaration consists of partial values described below (E.1 to E.x). Both input, output and memory array must be present in the file – but can be empty if necessary ([]).

Object array

necessary

E.1

name

Name of the value

IMPORTANT: if the name contains blanks, they are replaced by underscores when reading the file! Blanks should therefore be avoided 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 entry; depending on the type, plausibility checks or predefined dropdown lists are generated from this area. Each “range” entry consists of two sub-entries following this pattern:

„range“:{

“type”: „tooltip_loop“,

„values“: [0,1,1]

}

Available type/values combinations, see E.3.1 to E.3.3

Object

necessary

E.3.1

Range type 01:

loop

Creates a dropdown field from the loop values defined in the “values” array, e.g. “values”: [0,10,1.5].

Creates a dropdown field with values from 0 to 10 in increments of 1.5 (that is: 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

Creates a drop field from the value constants defined in the “values” array:

„values“: [

„M01|1“,

„M02|2“,

„M03|3“

]

The entries before the “|” symbol are displayed as readable text in the dropdown field, the entries after the “|” symbol are exported as the actual work value.

–

–

F

default

Default value of the attribute. Important: please make sure that it is within the value range defined at “range / values”! With range type “list’ the value must be entered BEHIND the “|” separator!

String

necessary

G

unit

Text string describing the unit of the attribute value; appears in the Unit” column of the edit table; if nothing is specified here, the data type is displayed as the 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 redundantly in the tags for easier and more performant processing of the RAP file. THEY MUST NOT BE IN CONTRADICTION TO THE TECHNICAL RANGE/TYPE SPECIFICATIONS!

String

necessary

I

edit

Edit mode of the attribute; determines the part which can be entered or changed by the user; the values 0-4 are valid here:

Neither name nor value of the attribute are editable.

Value of the attribute is editable.

Name of the attribute is editable.

Both name and value of the attribute are editable.

Value row is not displayed in the edit table (for constant, non-changeable values which 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 a correct sequential assignment of the offsets, please enter the corresponding offset distance to the next attribute depending on the value type (“type” entry, e.g. BYTE), example:

“name”: “Input01”,

“type”:“WORD“,

“offset”: 0,

:

“name“: “Input02”,

“type“:“BYTE“,

“offset“: 2

Input01 occupies the bytes 0 and 1 as a WORD value; the offset of Input02 therefore starts at 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”,

“multi”: 3

… generates attributes Input01_1 to Input01_3

IMPORTANT:

If no multi value is included, the value 1 is assumed as default.

If no multi value is defined for BOOL values, the multi value is automatically fixed to “8” internally when reading RAP files to set them to byte limits. A multi value in the file overwrites this automatism – here it is important to define only multiples of “8”!

No.

optional

M

active

true or false; defines whether an attribute value is considered at all or not when reading the RAP file. This allows attribute values to be completely deactivated for example for test purposes.

Bool

optional

N

export

true or false; determines whether the attribute value in the “Export” column of the edit table is marked for export by default or not.

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

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 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

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

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 BELOW an input / output entry:

“variants”: [

{

“id”: “Variant 001”,

“isDefault”: true,

„data“: [

:

:

The variant “id” will be displayed in future versions of PiCtory for variant selection. A descriptive text should be entered here, which must be UNIQUE.

“isDefault” indicates the default variant after reading the RAP file into PiCtory. Please pay attention to any defined “rules” and consider them when setting “isDefault”. PiCtory currently applies the “rules” only when the user changes the variant manually and cannot resolve contradictions in “isDefault” entries itself!

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:

work unit: „lang_input“:“8″

internationalisation area

„lang“:{

{

„de“: {

„input“: „Eingang“,

„output“: „Ausgang“

},

„en“: {

„input“: „Input“,

„output“: „Output“

}

}

}

Rendering in the value editor if German language is set:

Eingang: 8

Object

optional

rules

If the RAP file contains variants for both input and output entries, a logical link between input and output variants can be established by specifying “rules”. This causes PiCtory to automatically “synchronize” the linked variants as soon as a variant is selected. Example:

„rules“: {

„IO“: [

{

„sync“ : [0,0]

},

{

„sync“ : [1,1]

}

]

}

In this example, the 0th input and 0th output variants, and the 1st input and 1st output variants are linked. If the user changes the input to variant 1, PiCtory automatically changes the output to variant 1. If the output is then reset to 0, the input also 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“:

{

“include”:”[path to include file]”

}

Note the following points:

The path to the include file must be physically and permission-related defined in such a way that it can be reached by an Ajax call (user context of the web server).

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:

[

{

“name”: “RevPiLED”,

“type”: “BYTE”,

“offset”: 1,

:

:

In the case of a variant definition, it must look like this:

{

“variants”: [

{

“id”: “001”,

“isDefault”: true,

:

: