Posts Tagged ‘Drivers & PLC communication’

Alarm Management Challenge 2: Managing a Diverse Infrastructure

Friday, August 21st, 2015

Only in very few cases, are plants and facilities built from the ground up with a single turnkey solution that provides both the controls as well as HMI/SCADA. In well-developed markets, many manufacturers have a diverse infrastructure of different PLCs, HMIs, and a general mixture of new and old technology. Each PLC program or HMI system follows its own unique conventions which only adds to the problem.

A good alarm management system must be based on a solid, efficient, and a reliable communication foundation to bring these components together. In a production facility where alarms are provided to operators who must make critical decisions with serious operational or safety implications, the quality of data must be called into question. The fact is that many existing HMI/SCADA systems still rely on additional software components (e.g. a middleware OPC Server) or PLC head stations which adds additional complexity and extra components which may fail.

zenon’s alarm management solution: A software solution for any hardware

With more than 300 native drivers and communication protocols – actively developed and maintained by COPA-DATA – zenon has the unequaled ability to be installed in a production facility that has a mixture of old PLCs, new PLCs, proprietary PLCs, and PLCs supporting standardized communication protocols (Modbus, BACnet, OPC UA, etc.).

Since zenon uses its direct communication drivers, the alarms are always derived from a variable that is being mapped to the logic controller. The zenon variable list provides an overview of all variables at all times, and in Runtime there are 64 dedicated status bits to ensure the communication status and the quality of data.

The functionalities of the core zenon alarming system require no extra configuration, settings, databases, or a dedicated server. When a new zenon project is created, alarming is activated by default, and all the engineer needs to do is define the alarm states and implement the alarm screens.

Alarm Management: Alarm visualization steps in zenon

Alarm Management: Alarm visualization steps in zenon


See “Alarm Management Challenge 1: Too many alarms” here.

Interfacing with SQL Servers with zenon – zenon SQL Driver

Thursday, August 28th, 2014

SQL DriverThe zenon SQL driver can interact with a SQL database via ODBC, as if the SQL database were a PLC itself. This driver requires the tables to be created and formatted in a specific way, but if properly configured will allow zenon to read and write to tags defined in the SQL database.

Use Case

zenon is able to read data from the pre-defined table, placed there e.g. by third party applications, and assign this data to PLC variables. Effectively reading data from a table in a database of a SQL server and writing that data to PLC variables using any of the many direct PLC drivers that come with zenon.

How it Works

The zenon SQL driver (sqldrv.exe) is a polling-based driver that can communicate with specially defined send and receive tables in an SQL database. COPA-DATA also offers SQL queries to create the needed tables, columns, and assign the appropriate data types for them.

The designed use-case for this driver needs a separate table for sending and receiving values. If these values need to be used in different applications or in different tables, a periodically executed stored procedure has to be created to transform the data into different formats and/or to transfer them into different tables.


This module must be licensed in the zenon Editor as well as the zenon Runtime. If this is a network project, it is only required to license this driver on the runtime server(s) which will actually communicate with the SQL database.

DNP3_NG – Part 2

Thursday, October 24th, 2013

DNP3_NGIn the previous blog entry, we looked at what is the DNP3_NG driver. Now let us take a closer look at what is new.

With the DNP3_NG driver, it is now possible to automatically create variables in the zenon Editor. One option is to import the XML Device profile that specifies the capabilities of the outstation. The driver allows you to create variables for the items specified in the points list of the device profile. Alternatively, you can carry out an online browse of the outstation. In this case, the driver in the editor will connect to the outstation, perform an integrity poll, and enable you to select which points returned in the integrity poll should be created as variables.

Where the DNP332 driver only supported configuration of a polling interval for the integrity poll and all three event classes together, the DNP3_NG driver allows you to specify both an interval for common event class polls as well as polling intervals for each individual event class.

The DNP3_NG driver now also provides configuration options for unsolicited responses for each event class. When unsolicited responses are supported, you could turn off cyclic polling for event classes and e.g. only perform event polls on demand, triggered from the runtime.

Using the driver object “class scan” you can explicitly trigger an integrity poll or an event poll for the event class specified. Also, you can trigger a read for points that are not included in the integrity poll or any event class. Such a read is also executed after each integrity poll. Device Attributes, for example, are not included in an integrity poll and need to be read explicitly. Using a variable from the type “class scan” it is also possible to trigger a “cold restart” of the outstation.

Variables now also allow individual configuration of the variation. When the Outstation does not return the DNP object in an event class poll in the desired variation, e.g. the object contains no timestamp, you can change the variation at the variable, and set the option “permanently read variable”. After every integrity poll, or after an explicit trigger, the driver will request the DNP objects in the specific variation.

While it was necessary for the DNP332 driver to select the “SBO” flag at the variable, to specify that a Select Before Operate should be executed via Command Input instead of a Direct Operate, with the DNP3_NG driver, this flag needs to stay disabled. Instead, at every variable of the type Binary Output and each Analog Output, a property “Command Mode” defines if a Direct Operate or a Select Before Operate (Automatic SBO) is executed.

When using Command Input it is now also possible to use a Boolean variable instead of an unsigned short integer, and use the Qualifier Of Command to specify whether a Latch On / Off, Pulse On / Off or a Trip / Close will be used.
The DNP3_NG driver also supports Secure Authentication. Currently, Secure Authentication v2 is supported using pre-shared keys.

To get a detailed overview of which functionality is supported by the DNP3_NG driver, the DNP3 XML device profile is installed with an installation of the zenon Editor in the directory: “%CD_PROGRAMDATA7100%communicationprofiles\Dnp3\Driver”. The driver manual (login required) also provides a source for further detailed information.

DNP3_NG – Part 1

Thursday, October 17th, 2013

DNP3_NG“NG” is a common abbreviation for “No Good”. You may therefore find it uncomforting, that especially for newly introduced drivers, the driver name ends with “NG”. There is no need to worry though. Actually quite the opposite of “No Good” is the case here. “NG” as we use it, stands for “Next Generation”. Basically, as demands for support of additional features for a PLC driver grow, there is a turning point where it makes more sense to develop a completely new driver than to continue adding functionality to an existing driver. The new driver will become the “Next Generation” driver for the specific protocol or PLC.

What is the DNP3_NG driver?

The DNP3_NG driver is a new zenon driver for the DNP3 resp. IEEE 1815 protocol. Like the DNP332 driver it allows communication to DNP3 Outstations, sometimes also called DNP3 slaves. The DNP3_NG driver is the successor to the zenon DNP332 driver.

Where do I get the DNP3_NG driver?

The DNP3_NG driver is officially available with zenon 7.10. In fact, when you add a new DNP3 driver to your project in zenon 7.10, only the DNP3_NG driver is available in the list.

Can I still use the old DNP332 driver in zenon 7.10?

Yes, the DNP332 driver is still installed with zenon 7.10 and will continue to be available in future versions. Existing projects with the DNP332 driver that are converted to zenon version 7.10, will still contain and use the DNP332 driver. You will be able to open the driver configuration in the editor and the DNP332 driver will still be used in the runtime. If you want to create the legacy DNP332 driver for an existing or new project in zenon version 7.10, this is also still possible. The procedure how to add the legacy DNP332 driver to the driver selection list is described in the version 7.10 DNP332 driver documentation.

Can I switch from the DNP332 driver to the DNP3_NG driver in zenon 7.10?

Yes, you can make the switch from the DNP332 driver to the DNP3_NG driver for existing projects. Although everything should go smoothly, it makes sense to start off by making a project backup. You will need to make note of the communication parameters in the DNP332 driver configuration. Then in the context menu of the DNP332 driver you can call up the option to exchange the driver to the new DNP3_NG driver. After this process is complete, you will need to reopen the driver configuration of the DNP3_NG driver and input the correct communication parameters which you previously made note of. The output window of the zenon editor will inform you of any possible errors that may occur during the exchange process. For example, with the old DNP332 driver it was possible to select data types for certain driver object types that were not compliant with the DNP3 protocol standard. If such data types are used in the DNP332 driver, a warning message will appear, and the driver exchange is cancelled. To continue, the data type for these variables needs to be changed prior to exchanging the driver again. The manual for the DNP3_NG driver contains further information on how to switch the DNP332 driver to the DNP3_NG driver.

Next time we will look at some of the new features of the DNP3_NG driver and draw up a more detailed comparison between the legacy DNP332 driver and the new DNP3_NG driver.

Status update MELSECA driver

Monday, September 5th, 2011


Mitsubishi Melsec A-Q protocol and hardware exist in several evolution steps, and are not fully compatible:

  • The first Mitsubishi PLC’s used A series CPU’s, later extended to series like AnA or AnU, with a larger protocol field for device numbers. The current CPU’s are from series Q/QnA, not fully backward compatible with A CPU variants.
  • Communication options are designated C for serial (COM) port or E for ethernet (TCP) protocol. Within the Melsec A-Q protocol, several frame types are defined, frame 1 is used by A CPU’s, including variants for short and long device numbers, other frames (2..4) are compatible with Q CPU’s, most common is type 3.
  • Frame 1 can also be used to communicate with Q/QnA CPU’s, but is restricted to devices found with the same names in An, AnN, AnA and AnU CPU’s, with step relay and latch relay mapped to the internal relay, while file registers are not available. Those Q CPU’s with built in ethernet port are not compatible with frame type 1, and could not be used with the earlier zenon driver.
  • Melsec A-Q protocol can use ethernet in ASCII or binary mode, serial communication standard is ASCII, binary is only an option format with frame type 4.
  • Mitsubishi adds compatibility information and the communication mode to the frame number, giving, for example, A compatible 1C frame or QnA compatible 3E frame, binary mode.

zenon Status:

The zenon driver for Melsec A-Q started with serial communication for A and AnA CPU’s, that is frame 1C with short and long device numbers. Next came TCP, using frame 1E also in ASCII mode. Now we have added frame type 3E in binary mode, giving full access to the latest features for all types of Q CPU’s. Not yet covered are the ASCII modes for frame type 3E and 3C, and any kind of binary mode for serial communication.


No demand for updates to frame 1 is expected, and serial binary mode looks equally rare. But since frame type 3 is needed for full use of Q CPU’s, ASCII mode for 3C or 3E may become necessary: Serial installations have no other option, and ethernet users could find their own reasons not to switch to binary. Either more options have to be integrated into the current driver, or a split in two versions, like A/frame1 and Q/frame3, could be the better option.