Code: |
AS + 810 |
Symbolic: |
bccLadMonStart |
This command will create and start a special monitor for a specific ladder process. Request parameters are the following:
Offset |
Type |
Label |
Description |
|---|---|---|---|
0 |
U32 |
OWNER |
Owner ID |
4 |
U16 |
PID |
Process ID |
6 |
U32 |
RUNGID |
First rung ID |
10 |
U16 |
COUNT |
No. of consecutive rungs |
12 |
U32 |
TIMEWD |
Initial watchdog time [ms] |
On success, a bccAck is received with the following data:
Offset |
Type |
Label |
Description |
|---|---|---|---|
0 |
U32 |
MONID |
Monitor ID |
On failure, a bccNack is received. Specific errors:
NACK code |
Description |
Extra data |
|---|---|---|
nackIllegalArgs |
Illegal arguments |
U16 What illegal 1=Process ID 2=No. of rungs 3=Watchdog time 4=Owner ID 5=First rung ID |
nackNotFound |
Process not found |
|
nackOutOfResource |
No more resource to create and start a new ladder monitor |
|
Once started, the monitor will continue to send bccData messages, containing data for each of requested rungs (or a single bccNoData if no rungs or data to send): transmission frequency is decided by the device.
Each bccData message has have a progressive PID, starting from 0 at first data message and has the following structure (overall cannot exceed 255 bytes total):
Offset |
Type |
Label |
Description |
|---|---|---|---|
0 |
... |
RUNG0 |
Data for rung 0 |
... |
... |
RUNG1 |
Data for rung 1 |
... |
... |
... |
... |
Each RUNGx field is structured as:
Offset |
Type |
Label |
Description |
|---|---|---|---|
+0 |
U8 |
SIZE |
Rung data size (SIZE included) |
+1 |
U32 |
ID |
Rung ID |
+2 |
U8 |
RTF |
Runtime Flags 0x01 Rung not executed 0x02 Rung with error(s) |
+3 |
U8 |
NBF |
No. of BITS fields (min 1) |
+6 |
U8 |
BITS0 |
Boolean data 0 bit0 = rung general state |
+7 |
U8 |
BITS1 |
Boolean data 1 (optional) |
... |
... |
... |
... |
... |
... |
VAL0 |
Value data 0 (optional) |
... |
... |
VAL1 |
Value data 1 (optional) |
... |
... |
... |
... |
Items inside a rung have a natural order: monitor value for these items follow the same order, split betwen boolean values (represented with consecutive bit in BITSx fields) and numeric values (represented with consecutive VALx fields).
Bit no. 0 of BITS0 is used to represent the general boolean state of the rung itself; starting from bit no. 1 there are the user boolean values.
Each VALx field is structured as:
Offset |
Type |
Label |
Description |
|---|---|---|---|
+0 |
U8 |
FLAGS |
bit0-bit3 = Data type (TYPE) bit4-bit7 = Reserved |
+1 |
... |
DATA |
Raw data |
while the DATA field is structured as (depending on data type value):
Type |
Offset |
Type |
Description |
|---|---|---|---|
0x0 |
|
- |
(reserved) |
0x1 |
+1 |
I8 |
Signed integer 8bit |
0x2 |
+1 |
U8 |
Unsigned integer 8bit |
0x3 |
+1 |
I16 |
Signed integer 16bit |
0x4 |
+1 |
U16 |
Unsigned integer 16bit |
0x5 |
+1 |
I32 |
Signed integer 32bit |
0x6 |
+1 |
U32 |
Unsigned integer 32bit |
0x7 |
+1 |
I64 |
Signed integer 64bit |
0x8 |
+1 |
U64 |
Unsigned integer 64bit |
0x9 |
+1 |
DBL |
Floating point 64bit |
0xA |
+1 |
FLT |
Floating point 32bit |
0xB |
+1 |
- |
Boolean (TRUE): has no raw data. |
0xC |
+1 |
- |
Boolean (FALSE): has no raw data. |
0xD |
|
- |
(reserved) |
0xE |
|
- |
(reserved) |
0xF |
|
- |
(reserved) |
NOTE: to have more informations about the composition (and the order) of data sets, see Ladder Monitor Data Types in the ladder diagram documentation.
