Tell commands - D2000 Kom

• I/O tag with specified HOBJ,
• all I/O tags on the station with specified HOBJ,
• I/O tags with the name matching the given mask,
• all I/O tags on the stations with the names matching the given mask.

The command allows switching between the primary (OFF or PRIMARY) and backup (ON or BACKUP) devices for lines of categories "SerialOverUDP Device Redundant", "SerialOverUDP Line Redundant", and "SerialOverUDP System&Line Redundant", or discovering the active device (QUERY). The active device is used to write UDP packets and packets received from it are processed. Data received from the inactive device is ignored. Similar functionality is also supported for lines of the "TCP/IP-TCP System Redundant" category - the TCP connection is connected to a primary or backup device.

The third parameter (numbers 1-4) specifies the subline. For a line of the category "SerialOverUDP Device Redundant", it need not be specified or must be equal to 1. For a line of the category "SerialOverUDP Line Redundant", it can be equal to 1 (the device on the Primary line is set) or 2 (the device on the Secondary line is set). For a "SerialOverUDP System&Line Redundant" or  "TCP/IP-TCP System Redundant" category line, it can be equal to 1 - 4 (the device on the Primary/Secondary line of the system A/B is set). If an active device is detected (QUERY) and the third parameter is not entered, all active devices are listed (1, 2, or 4 depending on the line type).

The command is also applicable on the OPC UA Client line in the OPC Unified Architecture Data Access Client protocol for Client Type=Default. Using the command, it is possible to find out which of several specified hosts the D2000 KOM process is connected to (QUERY) or to force a connection to a specific one (ON, third parameter set to 1 .. N).

The command is also applicable on RFC2217 Client, TCP/IP-TCP, and TCP/IP-TCP Redundant lines. With the help of the command, it is possible to find out which of several specified hosts the D2000 KOM process is connected to (QUERY, or QUERY PRIMARY/BACKUP) or to force a connection to a specific one (PRIMARY/BACKUP, third parameter set to 1 .. N).

Examples of use:
LNALTERPATH L.MyLine ON 3
LNALTERPATH L.MyLine BACKUP 3
LNALTERPATH L.MyLine QUERY

Return codes:

• SUCCESS - transaction successful, data transfer to the system finished,
• IGNORED - the process D2000 KOM is not running in the mode of KOM Archiv,
• ERROR - invalid parameters (time format: dd-mm-yyyy hh:mi:ss), wrong sequence of entered times - BeginTime > EndTime.

The command de-configures the object (line or station) and its descendants (stations, I/O tags) and reloads them. The command can be used to apply configuration changes that would otherwise require restarting the KOM process. The command is currently implemented for protocols:

• IEC 60870-6 ICCP/TASE.2
• IEC 870-5-101 (client, server, balanced mode)
• IEC 870-5-104, IEC 870-5-104 Server
• Modbus Client, Modbus Server
• OPC UA Client

Return codes:

• SUCCESS - changed address (the value of the I/O tag is invalid until it is read from the new address).
• IGNORED - The D2000 KOM process does not support dynamic address change for the specified protocol.
• ERROR
  1. duplicate address
  2. point not found
  3. bad address format

Dynamic change of the I/O tag address is implemented only for a limited group of communication protocols:

• AMiT ATOUCH32 DB-Net
• BACnet
• General Electric SRTP protocol
• Honeywell C-Bus
• L&G TOCCATA
• L&G TOCCATA via UNIP2
• MODBUS Client
• OPC Data Access 2.05 & 3.0 Client
• Siemens SAPHIR
• SNMP

Return codes:

• SUCCESS - changed address,
• IGNORED - The D2000 KOM does not support a dynamic change of address for the specified protocol,
• ERROR
  1. object not found
  2. invalid number of parameters

Dynamic change of address is implemented only for a limited group of communication protocols:

• ALYA Lubrikacie
• MODBUS Client
• MODBUS Server
• MODBUS Telemecanique TSX
• MODBUS Valmet Damatic RTU
• MODBUS RTU Quad2000
• MODBUS SCT PPU

Example:
Data files, recorded by the TELL command:
START_RECORD DirName "01-12-2008 08:22:27" "01-12-2008 11:02:07"

These four data files (it relates to four hourly intervals) are the result of recording:
KOM-SELF_2008_12_01_08.dat < 01-12-2008 08:22:27 ; 01-12-2008 09:00:00 >
KOM-SELF_2008_12_01_09.dat < 01-12-2008 09:00:00 ; 01-12-2008 10:00:00 >
KOM-SELF_2008_12_01_10.dat < 01-12-2008 10:00:00 ; 01-12-2008 11:00:00 >
KOM-SELF_2008_12_01_11.dat < 01-12-2008 11:00:00 ; 01-12-2008 11:02:07 >

Note: The TELL command uses "dd-mm-rrrr hh:mm:ss" format for the parameters of DateTime type.
It is possible to initialize this TELL command from the D2000 Server, as well as directly from the clients (currently only from the D2000 KOM and Gateway Client processes).
Data are recorded into the specified subdirectory in the application directory, where a separate data file is created for every hourly time period.

Note: It is possible to start up this TELL command from the D2000 Server, as well as directly from the clients (currently only from the D2000 KOM and Gateway Client processes).

Example of data replaying:
Time Stamp (TS) - blue color, current time (CT) - red color

If /LOOP is used, data replaying will be again started automatically. It can be stopped by the STOP_REPLAY command.

Note: This TELL command uses the "dd-mm-rrrr hh:mm:ss" format for the parameters of DateTime type.
It is possible to start this TELL command from the D2000 Server, as well as directly from the clients (currently only from KOM client).
The  D2000 KOM process can be started up in replay mode only with the start parameter /Replay. It causes the process D2000KOM not to communicate with devices.

Note: There is possible to start up this TELL command from the D2000 Server, as well as directly from the clients (currently only from KOM client).

Example:
D2000 on OpenVMS platform: STDOUT "_TNA2:" (output is redirected to the terminal _TNA2:)
D2000 on Windows platform: STDOUT C:\output.txt (output is redirected to the file output.txt)
Note: See a note for STDOUT command for D2000 Archiv.

The first form of the command enables the communication (the parameter  START) or disables the communication (parameter STOP) with the StationName station. The station will get the StON (START) or StOFF (STOP) value.

The second form of the command sets the station's value to a communication error (StComErr or StHardErr). This form can be used for some communication protocols (e.g. KNX protocol, MQTT Client) if there is an external way to detect the outage (e.g. the value of I/O tag serving as a watchdog doesn't come in time).

For protocols based on periodic polling of I/O tags (request-response protocols): the command generates one or several requests for priority reading of all I/O tags on a specified station. The Number parameter defines the number of requests, possible value is within 1...5. If the parameter is not specified, a single request will be generated.

For protocols based on sending of changes (change-based protocols): the command generates one or several requests for the reading of all data. The command is implemented for a selected set of communication protocols:

• BACnet (sends ReadProperty, ReadPropertyMultiple, and Subscribe messages depending on the configuration of I/O tags)
• DNP3 (sends requests for reading of all configured Poll Classes specified in the configuration of station parameters and for reading of values of all objects with "Explicit read" enabled)
• IEC 60870-6 ICCP/TASE.2 (sends requests for reading values of all I/O tags)
• IEC 61850 (sends requests for reading values of all I/O tags)
• IEC 870-5-101 (sends Interrogation Command/Counter Interrogation Command depending on station protocol parameters)
• IEC 870-5-104 (sends Interrogation Command/Counter Interrogation Command depending on station protocol parameters)
• IEC 870-5-104 Server (sends Interrogation Command/Counter Interrogation Command depending on station protocol parameters)
• IEC 870-5-104 Sinaut (sends Interrogation Command/Counter Interrogation Command depending on station protocol parameters)
• OPC Data Access (sends requests for synchronous reading values of all I/O tags)
• OPC UA (sends requests for reading values of all I/O tags)

After receiving the command, the process writes, into its log file, information about:

ACCESS - text identifying the next information
ESL name - script identification¹
String - registered text string
time of GetAccess - time of string registration
bGlobal - flag defining the string to be global
userComment - comment
status - text "IN PROGRESS", if the global string has been registered, otherwise empty text ""

- list of all open XML documents (%XML_CreateDocument, %XML_OpenDocument)
Format: XML;ESL name;handle

XML - text identifying the next information
ESL name - script identification¹
handle - unique numerical identifier of XML document; it is identical to handle which is used by functions %XML_* 

- list of objects that have been opened by function %OpenRefToObject
Format: REFOBJ;Esl Name;Synchro;Obj HOBJ;Obj Name;Open In Progress

REFOBJ - text identifying the next information
ESL name - script identification¹
Synchro - value of parameter _bSynchro at calling of the function %OpenRefToObject
Obj HOBJ - unique identifier of opened object
Obj Name - unique name of opened object
Open In Progress - flag defining if the object is just being opened

- list of active database connections (by the DB_TRANS_OPEN, DB_CONNECT, PG_CONNECT, and SQL_CONNECT actions)
Format: DBCONNECT;ESL name;DB TRANS HANDLE;SUB CONNECT HANDLE;TYPE;OBJNAME;Prepared SQL Command;Last SQL Prepare; Comment

DBCONNECT - text identifying the next information
ESL name - script identification¹
DB TRANS HANDLE - identifier of transaction connections (it is created by calling the DB_TRANS_OPEN action), or 0, if the connection is not transactional
SUB CONNECT HANDLE - identifier of connection (it is created by calling the DB_CONNECT, PG_CONNECT, or SQL_CONNECT actions)
TYPE - type of connection (SUB CONNECT HANDLE)
OBJNAME - object name, on which the connection is joining
Prepared SQL Command - flag of the existence of prepared SQL command
Last SQL Prepare - format of the last SQL command which has been prepared by calling the SQL_PREPARE action
Comment - the position where the SQL_PREPARE action was called

- list of files which have been opened by functions %FIO_*
Format: FIO;ESL name;file name

FIO - text identifying the next information
ESL name - script identification¹
file name - filename

- list of created data containers (CNT_CREATE action)
Format: CNT;ESL name;handle;NR;valTyp;is array

CNT - text identifying the next information
ESL name - script identification¹
handle - unique numerical identifier of data container
NR - number of elements
valTyp - a type of key which identifies the items in the data container uniquely
is array - flag determining whether the action CNT_CNVTOARRAY is applied on the respective data container

¹ - script identification: text string uniquely identifying the running ESL scrip. It contains the object name (HOBJ)[instance number] unique numerical identifier.
Example: E.Script(728)[105]1872
(%GetSelfInstanceId, %GetSelfHBJ)

Example:
D2000 on OpenVMS platform: STDOUT "_TNA2:" (output is redirected to the terminal _TNA2:)
D2000 on Windows platform: STDOUT C:\output.txt (output is redirected to the file output.txt)
Note: See a note for STDOUT command for D2000 Archiv.

Example:
D2000 on OpenVMS platform: STDOUT "_TNA2:" (output is redirected to the terminal _TNA2:).
D2000 on Windows platform: STDOUT C:\output.txt (output is redirected to the file output.txt).
Note: See a note for STDOUT command for D2000 Archiv.

The log format is identical with the format [Calc], which is stated in the article Checking values of destination columns, Example 3.

Note: This command is mainly used for diagnostic purposes in D2000 systems.

MONITOR_TRANS SHOW {ALL/<id>} [<file_path>]

MONITOR_TRANS ON <history_depth_sec>

MONITOR_TRANS OFF

MONITOR_TRANS RESET

The mechanism for monitoring of the transactions.

ON - activates the monitoring. <history_depth_sec> means a time-depth history of closed transactions.
OFF - deactivates the monitoring
RESET - resets the list of transactions (including the opened ones)
SHOW - shows either the list of transactions including the history (ALL) or the particular transaction (<id>) to a console or file <file_path> in CSV format separated by ";"

Columns in the list:
- ID (transaction identifier)
- time, task, traceback (time the last operation within the group of identical ones, task, traceback in the internal code)
- comment, count (the last comment and the number of consecutive identical operations) (the identical operations has the same task and traceback)

Note: After starting DBManager, the monitoring is switched off.

MONITOR_CONNECTS SHOW {ALL/<id>} [<file_path>]

MONITOR_CONNECTS ON <history_depth_sec>

MONITOR_CONNECTS OFF

MONITOR_CONNECTS RESET

Monitoring the connections.

ON - activates the monitoring. <history_depth_sec> represents the time-depth history of closed connections.
OFF - deactivates the monitoring
RESET - resets the list of connections (including the opened ones)
SHOW - shows either the list of connections including the history (ALL), or the particular connection (<id>) to a console or file <file_path> in CSV format separated by ";"

Columns in the list:
- ID (auxiliary identifier of connection)
- logon_time, logon_task, logon_traceback (time of connection, task and traceback in internal code)
- logoff_time, logoff_task, logoff_traceback (time of disconnection, task, and traceback in internal code)
- comment (the last written comment for the given connection, e.g. traceback in ESL code)

Note: After starting DBManager, the monitoring is activated with the time-depth history of closed connections which is 3 hours (10 800 seconds).

The command allows you to close and reopen connections to the database that are not currently in use (there is no transaction in progress or a cursor in use).

Note: This command was implemented to work with temporary tables in PostgreSQL. These are only dropped when the database connection ends, and while they exist, the data in them is not visible outside the database connection that inserted them, so they cannot be accessed by vacuum, and therefore internal transaction IDs (XIDs) can be exhausted if a connection is open for a long time.

The command will cause the execution of the SQL statement DISCARD TEMPORARY in the PostgreSQL database with the specified name/ID on all connections, or on a specific one.

Note: This command was implemented to work with temporary tables in PostgreSQL. These are only dropped when the database connection ends, and while they exist, the data in them is not visible outside the database connection that inserted them, so they cannot be accessed by vacuum, and therefore internal transaction IDs (XIDs) can be exhausted if a connection is open for a long time.

The command may be used for example after a failure or stoppage of the application, which the D2000 GateWay Client process belongs to. It allows transferring the values from the archive of the remote application to the archive of the application. The only requirement of the value transfer is that the values of corresponding objects have been stored in the archive of the remote application.

The first form of the command reads all values transferred by specified remote tags (as well as structured objects).

The second form of the command reads all the values of several objects according to the mask.

The third form reads the values of a part of the structured object. The parameter item specifies a column of the destination structure (see the Destination structure parameter in the configuration of the remote tag) and it must be specified within quotes. When a single row (column) needs to be read, use the following:

• reading row 10 - GETOLDVAL "RemoteTagName[10]" …
• reading the column named Values - GETOLDVAL "RemoteTagName[0]^Values" …

The TELL command must always be executed in the transaction mode - the COMMAND action (within the D2000 System Console process, the command is automatically executed in the transaction mode). After the command is executed, the values that were transferred will be stored in the archive and the D2000 Archive automatically recalculates corresponding statistics.

The NORECALC parameter can be set at the end of the GETOLDVAL. In this case, the statistic calculations will not be executed by the D2000 Archiv process.

Debug Info for remote objects - enables/disables displaying the information about processing the values of objects with specified HOBJ or with the name matching the given mask.

Note: if the gateway client is run in a transparent gateway mode, use the TRGTW command to display debug information.

Starts recording of values read from the GateWay Server. For details see the command description for the D2000 KOM process.

Note: Replaying of recorded values by the D2000 KOM process is possible if the GateWay Client was running in a transparent gateway mode during the recording.

Instantly stops recording of values read from the GateWay Server. For details see the command description for the D2000 KOM process.