Damocles network communication protocols
The units from Damocles family control the binary
inputs and outputs over the network, eventually measure the value
of temperature sensor. The immediate values are available over the
network communication protocols here mentioned.
measured data from Damocles are available by different ways corresponding
to various applications. Modbus/TCP is intended for industry
and the visualization used in the industry, SNMP is intended
for telecommunications and remote management. It´s possible use XML
for simpler applications control using scripts on the server side.
- Question/Answer type of communication
- Event notification type of communication
>> Damocles model
XXXX - models overview
Question/Answer type of communication
The Question/Answer protocols are intended for periodic reading
of all sensors values. Damocles is in the TCP Server mode, waits for
request from supervising application.
WEB - HTML (WWW page)
of binary inputs and outputs are displayed on a simple WWW page which
is first loaded when accessing Damocles using web browser. The page
is reloaded every 5 to 30 seconds (see the Damocles models manual).
If some variable reaches the value that is set as ALARM value, this
binary input or a sensor is colored red.
Access to this WWW page is not restricted by password, it only writes
values and there is also nothing to modify. The access can be restricted
by IP address filtering.
Note: On the other hand for access to the Flash Setup user
name and password can be demanded. You can find this option in "General
Setup" bookmark in FLASH Setup. In case you forget your password
new configuration of the device to "Set to Default" over
RS-232 Setup is necessary.
HTTP - XML tags
current monitored values are displayed in the defined .XML page (for
example values.xml - see the model documentation) and they
can be read easily from XML tags by any application. It represents
the most efficient way of retrieving data for Machine-to-Machine TCP/IP
communication, because values from all sensors are stored in one file.
XML entry is comprehensible for a man as well, process independent
on SW platform and information can be retrieved even without a special
Note: We recommend using XML as the input interface for
your SW applications...
Example of XML record for a binary input:
|<Name>Input 1 </Name>
||- input name
||- input state
Note: Majority of the Damocles models contains two XML files
which differ in range of commands. The smaller file (typically values.xml)
is used for print-out of connected sensors state. The second file
(typically setup.xml) contains full device configuration data and
you can dump sensor values, names of sensors, their alarm state configuration
and others using your SW application. If the setting of Damocles allows
it, you can change some parameters over this file.
Modbus over TCP
Modbus is a communication protocol developed for measuring devices
communicating over RS-485 or RS-232. The Modbus protocol allows sharing
the variables' memory area over one of the physical interface, from
measuring values for instance. Modbus/TCP represents the extension
of this protocol for Ethernet communication.
Easy implementation into visualization systems for industrial professions
Mapping the variables of the Modbus/TCP protocol for Damocles
||Number of sensors
||Temperature 1 - current value
||Number of counters
||Input xx counter - adress 201(H) - 202(L)
||Setting input xx counter - adress 201(H) - 202(L)
||0 - open, 1 - close
||Input current value, where xx is index of output
||0 - open, 1 - close
||Output current value, where x is index of output
||0 - open, 1 - close
||Output set value, where x is index of output
Damocles Damocles operates as a TCP Server on port 502 (Modbus standard).
Communications run on the addresses defined by the Modbus/TCP protocol.
For more information, see http://www.modbus.org.
Schedule of individual parameters mapping can be found in the Damocles
>> AN28: Damocles family & Modbus/TCP
SNMP - question / answer
(Simple Network Management Protocol) is suitable for primary system
information exchange using short packets.
Individual variables are organized and described in so-called MIB
(Management Information Base) table, which can be used for any device.
The MIB table is distributed as a separate .mib file that can
be downloaded to Damocles from our main web pages or found on the
supplied CD which is part of start set.
SNMP is an asynchronous protocol based on the client/server model (here
SNMP Client/SNMP Agent). This means that the supervisor (SNMP Client)
queries for the state of the individual values and SNMP Agent, implemented
in the device, responds.
SNMP protocol support is provided in many languages intended for creating
dynamic WWW pages (e.g. PHP, ASP, Java, Perl, Python and others).
Thanks to existing modules it is possible to allow access to reading
or writing the data, provided by peripheral device to the system (e.g.
a Poseidon), over the SNMP protocol quite quickly.
In classic communication mode, the communication proceeds in terms
of questions and answers. The variables are defined by a numeric string
that is described in the MIB table that also defines the meanings
of the individual variables, format and names. If you know the hierarchy
(numeric string – e. g. „.18.104.22.168.4.1.21722.214.171.124.1.2.3“ – state of
binary input 3) for a specific value, you don’t need the MIB table.
- MIB table (Management Information Base) – .mib file is
a text-based file, describing individual variables supported by
the device. It contains variables' addresses, their name, description
and numeric format.
- OID (Object Identificator) is an identifier of the variable
in the variables’ chart. It is represented by a long number, defining
the variable’s position within the variable tree structure.
Some programs do not support MIB files for working with SNMP. With
these programs, you must enter the OID strings manually. The strings
can be found in the MIB table, but to save you looking there, we provide
a summary of several variables, their OID in Damocles models manual.
If sending of an Email is allowed as a reaction to Alarm, Damocles
sends email directly or via supervising program. It is standard email,
where recipient, subject and some parts of the message can be set.
Methods of sending the email
- Email is sent via external program
On a local server, the program runs and via SNMP supervises the
state of one or more Damocles units. In case of Alarm status, the
program sends notice via email.
- (+) If you have more Damocles units, the central point is
advantgeous for the administrator, he can set all supervising
parameters in this point and hasn´t to set them in each unit.
- (+) Email is always logged by an independent authority
- (+) Email format is programmable
- (-) It is necessary to guarantee a running application where
to send SNMP Traps from Damocles units and transmit emails.
This means to rely on:
- function of the local server and its program
- functionality of the connection server - Damocles unit
- functionality of the connection server - SMTP server
- E-mail sent via external SMTP server
Damocles connects directly to set SMTP server and transmits email
- (-) External SMTP server necessary
- (+) SMTP server logs sent emails
- Damocles supports user name and password authorization
- E-mail sent via Damocles directly to recipient's server - SMTP
server isn´t used
This method is advantageous if the SMTP server for sending emails
from the Damocles unit is not always accessible. The Damocles unit
sends email directly to recipient's SMTP server. It means that Damocles
unit is SMTP server for itmself.
- (+) You do not need SMTP server
- (-) Email can be deleted by the server, according to missing
reverse MX record which can recipient verify. Necessary to test
- Email is never logged
- Damocles needs to set the DNS server
the reaction of Alarm state by sending SNMP trap is allowed, Damocles
sends SNMP Trap to the specified IP address in the moments when the
Alarm state is beginning and when the Alarm state is finishing .
The trap consists of two SNMP traps for increasing of security and
compatibility with other systems.
The format of the packet is described in MIB table, the first packet
contains information about Alarm beginning and the second packet contains
information about sensor in alarm status.
The alarm is state value so that after alarm termination (for example
temperature goes back to the defined range) another two SNMP Traps
The trap system was developed to speed up delivery of information
about changes of state because in the classic SNMP mode - question/answer,
the period between each query can last from miliseconds up to several
hours. For input contacts it is possible to define sending Alarm at
Opening /Closing or the alarm can be disabled completely.
Detailed description and a summary of SNMP Traps can be found in
the MIB table. The Damocles model manual contains enhanced description.
SMS (over supplied software)
alarm status notification can be realized with redirecting the Email
to SMS. The redirecting is executed by supplied software which runs
as the service in the background of your system.
Methods of SMS sending
- SMS sent via GSM modem from server
On a local server, a program runs and via SNMP supervises the state
of one or more Damocles units. In Alarm status it sends notice via
SMS using GSM modem which is connected directly to the server....
- (+) For more Damocles units central point is advantageous
for setting all parameters in one step.
- (+) Alarm is always logged by an independent authority, it
can be sent to Email as well
- (+) SMS format is programmable
- (+) Via SMS request from your phone, you can verify the state
of several connected Damocles units
- (-) It is necessary to guarantee running application where
to send SNMP Traps from Damocles units and transmits SMS. This
means to rely on:
- function of the local server and its program
- functionality of the connection of server - Damocles unit
- functionality of the connected GSM modem
to the Damocles's detailed description
Similar and related products