7.10.4.2 Device Message Commands

Within the terminal session it is possible to read and write every parameter of all devices. A typical use case is to mock parameters of equipment which is currently not connected.

get msg-id

The get command returns all parameters starting with the string in msg-id. If you specify a name which does not exist it returns an empty line. If msg-id matches more than one parameter multiple lines will be return. This allows for example to get all parameter from one device with get BUC-1 or a subset of parameters like get BUC-1.faults.

Normally 2 lines return per parameters:

• the parameter itself with the current value
• the range setting of this parameter (marked with [msg-id].R ) which describes the type range and range.
• Disabled parameters (marked with DIS) or parameters which where never initialized will only result in one line with the range message.

Example: Parameter BUC-1.tx.on which is a CHOICE parameter with possible values ON and OFF, currently set to ON

---> get BUC-1.tx.on
BUC-1.tx.on.R EnumRange (ON|OFF)
BUC-1.tx.on OFF

The get command recognizes a parameter -r which causes the command to suppress all range messages which otherwise would be included in the list.

---> get -r BUC-1.tx.on
BUC-1.tx.on OFF

The range message belonging to this paramter is not shown.

set msg-id value

The 'set' command does not produce any output (except logParameterChanges is enabled for the device). It performs also no range checking and setting values of an unknown messageId will be silently ignored.

In case of a communication fault, the driver will stop after the first INPUT statement which does not get answered by the equipment and starts from the beginning. Therefore you will not see any outgoing (PUT) commands even if you set a parameter with set until you stop the driver cycle aka polling (see below).

Example: switch BUC transmit to ON

---> set BUC-1.tx.on OFF
000000 2021-07-30 16:07:50 2021-07-30 16:07:50   I BUC-1 tx.on changed to 'OFF' by debug window

loop msg-id value

A loop commands simulates that the device receives a message from equipment. So it looks like, that the equipment response to polling. With this command you can mock e.g. read-only values to display something useful even if you have no equipment connected.

But remember, values set with the loop command will be overwritten by next successful polling result (if there is communication to the equipment)

Example: set the output power of an BUC to 162 (Watt). On first get BUC-1.meas.fwdPwr is not initialized, but after looping 162 to the device it show this new value on the next get

---> get BUC-1.meas.fwdPwr
BUC-1.meas.fwdPwr.R IntegerRange R/O (0 .. 0)

---> loop BUC-1.meas.fwdPwr 162

---> get BUC-1.meas.fwdPwr
BUC-1.meas.fwdPwr 162
BUC-1.meas.fwdPwr.R IntegerRange R/O (0 .. 0)

verbose mode

Enable verbose mode for a device to follow all communication between MNC server and equipment Verbose mode could be enabled in the device setup page of each device or in the terminal session with set [DEVICENAME].verbose true.

Example: Beacon Receiver with HTTP protocol. Parameter BCRX.threshold is read from the device with the command /rmt?thrh=?

 ---> set BCRX.verbose true
 tx(BCRX): /rmt?thrh=?
 rx(BCRX): thrh=-90.00
   BCRX.threshold=-90.00

In addition you can enable dump mode for a device to print full communication between MNC's server and equipment even if it does not match with the required protocol structure with set [DEVICENAME].dump true.

Attention : Enabling this output creates huge amount of date which on the disk so do not forget to disable after testing.

stop polling cycle

You can stop the driver cycle with the following command in the terminal session: set [DEVICENAME].cycle true. Re-enable polling with set [DEVICENAME].cycle false or a restart of the MNC server.

Example: disable polling and set a value on a not connected device. After disabling polling the device tries one more time to communicate (tx(BUC-1): GET ...) but does not expect a response anymore. Device state switches to Communication OK.

---> set BUC-1.cycle false
tx(BUC-1): GET 1.3.6.1.4.1.2566.127.1.5.10.1.1.14.1.2.0 (FAILED)
000000 2021-07-30 15:52:20 2021-07-30 15:52:20   I BUC-1 past 0m17s Communication OK.
000000 2021-07-30 15:52:20 2021-07-30 15:52:20   I BUC-1 OK.

Now you can issue a set command (or send commands via Client UI) and the corresponding PUT procedures will be executed. Of course you will still not get any response from the equipment, so the Communication Fault will be issued.

---> set BUC-1.tx.on OFF
000000 2021-07-30 15:57:46 2021-07-30 15:57:46   I BUC-1 tx.on changed to 'OFF' by debug window
tx(BUC-1): SET 1.3.6.1.4.1.2566.127.1.5.10.1.2.1.3.1.0 I 1 (FAILED)
000000 2021-07-30 15:57:55 2021-07-30 15:57:55   I BUC-1 past 2m57s Communication OK.
000000 2021-07-30 15:57:55 2021-07-30 15:57:55   I BUC-1 OK.