Posts Tagged ‘Efficient Engineering’

Automated Engineering with zenon. part 3: automating with XML and ideas for practical use

Tuesday, October 18th, 2016

Automate with XML

There are now four possibilities for editing variables in the zenon Editor:

  • Import via a driver:
    For example, Siemens S7 TIA portal, Allen-Bradley ControlLogix, OPC UA and many more.
  • Export/import in dBase format:
    An old format that can still be used by Excel and Access.
  • Export/import in CSV (comma-separated text file):
    This file format is particularly suitable for semi-automated engineering in Excel, where mass processing is often easier to handle than in zenon, for example when modifying addresses.
  • Export/import with XML
    The following particularly speak in favor of this supreme method:

    • XML export/import is available for virtually all zenon modules.
    • All data is exported (e.g. dBase and CSV only support four limit values).
    • All files can be easily used with modern programming methods such as LINQ to XML.
    • Very good performance.
Import of variables from Siemens S7 TIA Portal.

Import of variables from Siemens S7 TIA Portal.

Methods 2 to 4 are particularly well-suited to automation purposes, because they can be used to create, modify and delete variables (and also other objects with XML).

Export/import in dBase format, as CSV or as XML.

Export/import in dBase format, as CSV or as XML.

In addition to manual XML export/import, there is the particularly useful method of automating this process using the API. We even expressly advise doing this, because this way objects can be created or modified using the API directly. And with XML export/import, this usually works much more quickly because each object does not need to be handled individually.

We recommend the following procedure: export all existing objects by means of XML. Then carry out the necessary changes in the automation tool (for example, by LINQ to XML) and import the file again. A freely-available example in which the XML import is shown is the project wizard.

Another benefit of the XML method is that you can easily create and save templates with it. Two methods are available:

  1. Create the corresponding objects (variables, screens, functions, scripts, recipes, users, etc.) once manually in the zenon Editor and then export these by means of XML into a template folder. This can also be automated if required. What is important for this is a uniform naming convention, for example when all templates start with the “tpl_” prefix. This way, an automation tool can identify all templates and process them automatically.
  2. With the screens, it is also possible to create templates using the screen template mechanism. The advantage in doing this is that the name, description, screen size and preview screen are included in the zip file.

Ideas for practical use

The most frequent application for automated engineering is surely use in conjunction with variables. Be it just transferring variables from other tools or issuing Modbus addresses, correcting driver configuration information or converting a driver to a different one, including manipulating address information. The large amount of data and the error rate of manual entries speak in favor of automation here.

A very exciting possibility is offered in conjunction with zenon Logic, our integrated PLC system. The user positions graphic objects in a screen, in the form of symbols. In the background, the variables and detailed screens (faceplates) are then created by a wizard and even the PLC code is created.

A further example in conjunction with zenon Logic is the metering point administration: when a metering point is created, the code to calculate the relative values is also created in zenon Logic.

Many machine manufacturers use automation to individualize their projects. Instead of offering all options in a large project where options that are not required are deactivated for each individual machine, the machine project is tailor-made from a modular system with a wizard. The individual configurations are then stored as templates in XML format and are compiled as required. This configuration can also be carried out in part with external tools.

Examples of automated engineering in zenon

The zenon Excel macro

The zenon Excel macro was developed by COPA-DATA consultants and shows how easy it is to create drivers and variables in zenon from Excel. The example consists of an Excel table with its own macros and four buttons: the connection to zenon Editor is established with the first button; the second button provides all available projects; the drivers defined in the Excel table are created with the third button and the predefined variables are created in zenon with the fourth button. You can request this Excel file from COPA-DATA anytime.

Abb4a-Excel Beispiel Oberfläche-Verbindung zum zenon Editor

zenon Excel macro – example: connection to the zenon Editor from Microsoft Excel …

Abb4b-Excel Besipiel Code zum auslesen der Projekte aus dem zenon Editor

… and the code used to read the projects.

The zenon Automotive Generator (zag)

“zag” is a very efficient example of automated engineering. You can find details about it on our web site.

The project wizard

The project wizard is supplied with zenon and is automatically opened with each new project. It is programmed in C# and covers the issues described very well with:

  • Direct modifications using zenon API:
    creating a driver for example.
  • Import of existing XML files from stored templates:
    importing a demo project.
  • Handling of screen templates:
    zenon standard and user-defined screen template selection and import.
The screen selection for screen types in the zenon project wizard.

The screen selection for screen types in the zenon project wizard.

The wizard also shows how multithreading can be implemented. For example, this is how the zenon screen templates are read in their own thread. The wizard is VSTA-based and is available as source code.


With automated engineering in zenon, you have a powerful tool at hand; compared to manual engineering you can save a great deal of time in project configuration and provide a significant increase in accuracy and reproducible results. zenon does indeed offer many possibilities out of the box for efficient project creation. However, with automated engineering, these can be multiplied and efficiency can be increased accordingly.

We wish you much success with your automation projects!

Automated Engineering with zenon. part 2: When do you use automated engineering?

Wednesday, September 28th, 2016

Creating a program for automated engineering yourself is time consuming and requires specialist knowledge. You should thus first always ask yourself the question: manual or automated?

Reasons for choosing automation are as follows:

  • Repeated tasks:
    For example, creating the same users, variables, functions etc. for each new machine
  • Information is already available in digital form:
    For example, variables in external data sources or screen information that can be derived from the PLC program
  • Results should be reproducible:
    For example, critical elements that should always be the same
  • The task is so comprehensive that automation is beneficial:
    For example, creating 500 screens or processing 10,000 variables

Automation is worthwhile particularly when there are large amounts of data, the tasks are repetitive or certain data is already available electronically in databases or other systems.

This series of blog posts does not provide instructions on how to implement customized automated engineering. However, we have suggestions and ideas for you, for how you can enter into the world of automated project creation, most of all for:

  • Programming in VBA
  • Programming in VSTA (C# or VB.NET)
  • Programming in external software, such as Excel
  • XML export/import
Abb1a-zenon API in zenonVBA

The zenon API in zenon VBA

Abb1b-zenon API in zenonVSTA

The zenon API in zenon VSTA

Abb1c-zenon API in Microsoft Excel

The zenon API in Microsoft Excel

Yes, that’s right: you can also easily program zenon from Excel – using Excel VBA. You thus have exactly the same possibilities as in zenon directly. It’s very simple if, for example, you have variables in Excel and want to create these in zenon: you open the Excel table from zenon VBA or VSTA and read off the values. This is how the zenon Automotive Generator (zag) works, for example. On the other hand, you can also access the zenon Editor from Excel directly and create, modify or also delete zenon objects.

You have a range of entry points available to start your automation solution in zenon:

  • Wizard
  • Macro that is started from the macro toolbar
  • Macro that is triggered by an Editor event. A very good possibility for starting actions fully automated. E.g. relevant events are triggered when loading a project or when a backup is created. However, it is also possible, when editing a screen for instance, to evaluate a double click on a screen element
  • External program that is incorporated in the zenon main menu

In the next blog post, you will find out more about automating with XML and practical examples.

Automated Engineering with zenon. part 1: introduction

Wednesday, September 14th, 2016

automated_engineering_video_Scene_05-800x800Automated engineering allows projects to be created partly or fully automatically. Depending on the application, this can happen by means of setting parameters in already existing wizards and tools, such as for the import/export possibilities of zenon Editor. Alternatively, however, zenon is controlled using scripts and macros or an external program, for which programming knowledge is required.

A long tradition of automated engineering in zenon

Back in 1999, with the release of zenon 5, Visual Basic for Applications (VBA) was introduced in our software. Initially only for Runtime, in order to allow individual customer solutions for our standard product. Our CEO, Thomas Punzenberger, selected VBA because this programming environment, based on Visual Basic (VB) 5, was already sufficiently known from the Microsoft Office packages. The implementation was so successful that Thomas Punzenberger was even invited by Microsoft to Redmond to present the solution.

The integration of VBA was also a complete success for our customers and the wish for VBA in the Editor quickly followed. Two fundamental functions for automated engineering were ultimately integrated into zenon 6:

  • VBA for the Editor
  • XML export/import

The highlights of zenon 6 correspondingly included “automatic engineering” and “efficient reuse”. And this applies now more than ever. Intensive work has been dedicated to these issues in recent years. When VBA was no longer developed and .NET prevailed, we implemented Visual Studio for Applications (VSTA) in zenon – with the possibility to choose development in VB.NET or C#. In addition, we allowed XML export/import for virtually all zenon modules.

A tip at this point: the interface for VBA and VSTA is the same. With a few exceptions in the Multi-Touch environment, the same functionalities are available in VBA as in VSTA. There are, however, more possibilities outside the zenon interface in VSTA. First, a very large integrated scope of functions is available with the.NET framework 3.5 and second, VSTA supports multithreading.

In addition to VBA and VSTA, there is a third significant possibility for automation: an external program. In an external program, the zenon API is also available in full and can be used accordingly. The advantage of this option is primarily the free choice of the programming language. You can, for example, also use Java or other programming languages for your application.

In part 2 of this series you will find out more about when to use automated engineering.

Disk Space Handling in zenon – FAQs Part 3

Wednesday, November 11th, 2015

How can zenon proactively notify users when resources become too low?

Part 3 Hard Disk HandlingDue to the fact that Free disk space – database (%) is essentially just another zenon variable, you can easily add a Limit or Reaction Matrix which is capable of color changes, visibility, flashing, etc. when a certain condition is met.

For example, a limit could be created on the Free disk space – database (%) variable which returns true when the free disk space goes below 15%. When this occurs you can generate an Alarm and/or an Event. Furthermore, you can require that this specific Low Disk Space alarm is in a special class, and requires acknowledgement from a system administrator.

To go another step further, you can add an additional limit on the Free disk space – database (%) variable which returns true when, for example, free disk space drops below 10%. On this limit you might add a zenon Function type “Send a Message” which sends an SMS or Email notification to a specific user or group of users about this event.

How can zenon manage the disk space and remove old data?

The zenon Historian module offers built-in mechanisms which grant the capability to either delete old archive data, or evacuate/move archive data to another location after a specific time period has lapsed. If configured properly, zenon is even capable of re-reading this data back into Trends, Reports, etc., although it may no longer physically reside in the same directory or PC anymore.
Although the sophistication of the zenon Historian enables it to manage archived data, zenon will continue to accumulate Alarms and Events from the time the project is first started. To manage the historical Alarms & Events, zenon offers a ready-to-use function called File Operations in the Function Group -> Windows.

The File Operations function can be used to move or delete files either on a time schedule (zenon Time Control Module) or when a limit is breached (Limit Function or Reaction Matrix Triggered). The function must, of course, first be parameterized with the operation (Copy, Move, or Delete) and the source and target directories defined. The File Operations function also allows wildcards and time filters to be used, for example: all files in the format *.XML – that are older than 180 days – should be moved to a network file server at \\MyNAS.corporate.lan\zenonData\old_alarms.


Industrial operating conditions will fluctuate to a certain degree. Exact estimates of how frequently value changes will be received by the HMI/SCADA system next month or how many alarms will be generated next week are often difficult to make. This is further amplified when unsolicited communications are used and data is being generated based upon these unforeseeable value changes (e.g. alarms, events, etc.).

The tools we’ve discussed here help to give zenon users an insight of zenon disk space use and flexibility in handling it. In this way, zenon ensures that your HMI or SCADA application can continue to run in industrial environments with minimum IT monitoring and involvement.

Disk Space Handling in zenon – FAQs Part 2

Wednesday, November 4th, 2015

Can zenon monitor the hard disk space?

There are a few methodologies that can be used with zenon to monitor the hard disk utilization. One method would include configuring the Windows OS SNMP Agent and using the zenon SNMP driver to read hard disk data in the form of process variables. Another alternative would be to use the zenon Programming Interfaces and the Microsoft .NET Framework to obtain management information via WMI.

However, the most straightforward method is to use the zenon System Driver Variables. Every zenon project has an internal driver available called the System Driver. The system driver has a wide collection of predefined variables that easily allow system-related information to be accessed by zenon Runtime and the HMI/SCADA system. Particularly of interest are the following System Driver Variables, available in the system driver variable topic -> Hardware resources (click table to enlarge):

Disc Space Handling System Driver Variables
In addition to these system variables the system driver offers other variables that may be useful in your project such as: CPU Usage %, Hostname, Servername, Total Alarm Count, Unack Alarm Count, Network Timeout, Total Received Packets, Total Sent Packets, etc. The system driver variables do not count towards your licensed zenon variables.

How can I see the free disk space in zenon Runtime?

After the system driver variable for Free disk space – database (%) is added to the project, the variable is free to use throughout the system.

It is good practice in a zenon project to create a “system information” screen to provide users with system-specific information on a dedicated screen. It would, of course, be wise to also display the system variable Free disk space – database (%) within this screen in the usual numerical value screen element, along with a text description. Then users can open this screen at any time and have a look at the real-time percentage of free disk space on the partition in which the zenon Runtime Folder is located.

Note: The “system information” screen is especially useful on systems where the user is locked out from the Operating System, the Runtime starts in full screen mode, or systems using the zenon Keyblock tool.

Disk Space Handling in zenon – FAQs Part 1

Wednesday, October 28th, 2015

Part 1 Disk Space Handlingzenon Runtime, by default, stores process data on the hard disk. This is true for a standalone zenon project, as well as zenon Runtime server(s) in a zenon network. This data consists of alarms, events, Historian, reports, exports, etc. Although zenon uses highly efficient native file formats by default, the amount of data recorded and accumulated by zenon Runtime can vary greatly depending on the project’s configuration.

The purpose of this series of blog posts is to provide an overview of zenon Runtime data storage and how it can be effectively managed to ensure optimal disk space utilization and performance over a typical HMI/SCADA lifecycle of more than 10 years.

Why does zenon Runtime save data?

A zenon HMI/SCADA system not only handles real-time current values coming from the PLCs, IEDs, etc., but is capable of maintaining records for historical reporting, analysis and compliance. zenon Runtime offers ready-to-use modules which are capable of reading from these historical files and presenting the data in a variety of forms. For example, one such module is Extended Trend. The zenon Historian can be configured to record measurement values for the last three months. These are saved onto the hard disk by zenon, and the Extended Trend module knows exactly how to read these files to present the user with a trend diagram in the Runtime.

Where does zenon Runtime save data, and what data is saved?

Runtime Folder: The zenon Runtime Folder contains both the compiled zenon Runtime Files and the zenon Runtime Data. The Runtime folder is commonly named with the zenon project name.

Runtime Files: are the compiled project files created by the zenon Editor. The zenon Editor’s Output Window will provide details about the compilation of the zenon project, but it is not necessary for you to become familiar with the different types of Runtime files and what they mean. The important thing to know is that your entire zenon project is compiled by the zenon Editor into a set of Runtime Files which the zenon Runtime can interpret.

The compiled zenon Runtime Files are usually quite moderate in size and are generally not a concern in terms of hard disk usage. Once a zenon project is live, the Runtime Files do not grow or expand, unless the zenon system is expanded intentionally by an engineer. The path where the Runtime files exist on the target system is user-definable. However, the Runtime files are consistently in a folder called RT, for example: C:\zenonRT\Project_SAS_1023\RT.

Runtime Data: is the data that is created and managed by zenon Runtime. The Alarm Message List, Chronological Event List, and Historian are some of the modules that actually store Runtime Data on the hard disk. Depending on the zenon project configuration, the Runtime Data can increase and use more disk space over the months and years of live zenon operation. The path where the Runtime data exists on the target system is user-configurable, but usually relative to the RT folder, in its own directory with the hostname of the PC e.g. C:\zenonRT\Project_SAS_1023\ServerA.

The following are some of the most common file types that zenon Runtime uses

.AML – The format written for a historical alarm file. To maintain historical alarm records, by default zenon will automatically create one alarm file per day. The naming format for these files is the letter “A”, followed by YYMMDD, for example: A151109.AML. The size of the alarm files depends directly on how many alarms are configured within the zenon project, and the alarm occurrence frequency.

.CEL – The format written for a historical event file. To maintain a historical record of chronological events, by default zenon will automatically create one event file per day. The naming format for these files is the letter “C”, followed by YYMMDD, for example: C150309.CEL. The size of the event files depends directly on how many events are configured within the zenon project, and the event occurrence frequency.

.ARX – The default and native format written for an archive file saved by the historian module. The size of these files is dependent on multiple factors such as the historian recording type (cyclic, on change, event triggered), the amount of variables recorded, and how often there are changes. The naming format for these files is the short name of the archive, followed by a timestamp of when the archive file was closed, in the format YYMMTThhmmss.

Alarm management challenge 5: Keeping an overview and finding specific alarms

Thursday, September 17th, 2015

This challenge is very much interconnected with the challenge of how to cope with too many alarms presented earlier in this article. If the amount of information presented by your alarm management seems already overwhelming, you will be surprised how lost you would feel in an alarm flood without proper filtering mechanisms. For a truly effective and manageable alarm system, finding and displaying the most critical alarms is a key success factor.

zenon’s Alarm Management Solution 5: Advanced Filtering Mechanisms

zenon offers flexible and user-definable solutions to enhance operations such as alarm classes and alarm groups for the purpose of classification and prioritization. Alarm groups and classes in zenon are also defined globally and set independently of the variable limits or Reaction Matrix states. Therefore, it is possible to have a pressure transmitter with a High Alarm with a class of Warning and the same pressure transmitter with a High-High Alarm with a class of Critical.

In Runtime mode, individual colors of the alarms can be defined within the alarm groups or classes to give operators a clear indication from the Alarm Message List about the most important alarms to handle. Of course, filtering in the groups and classes is an integrated part of the zenon filtering concept.

When alarm classes are used in combination with zenon alarm areas, then the ultimate statistics and overview are provided to the operator. Alarm areas are abstracted so they can be used for a variety of purposes, but they provide detailed information about active, unacknowledged, and acknowledged alarms within a logic area. The figure below shows a simple example how alarm groups, classes, and areas can be used together to provide a complete overview of the alarm status of an entire production facility.

Alarm groups, classes and areas examples.

Alarm groups, classes and areas examples.

There is one additional attribute to the unique alarm concept in zenon, and this is the Equipment Model. The Equipment Model in zenon represents an ISA 88 and 95 model that allows for the linking of objects to a physical piece of equipment. In general, it is a structured, hierarchical tree view of equipment within a plant or facility.

Equipment model example in zenon.

Equipment model example in zenon.

The zenon variable which generated an alarm can be linked to one or multiple equipment groups. When this is utilized, it provides not only a connection of a variable to a piece of equipment for the operator, but will also provide a hierarchical alarm filtering mode. If we look at an example from a beverage bottling facility, the equipment model may be structured as follows:

In Runtime, if the operator filters on Line 3, all alarms that occur from any piece of equipment within Line 3 will be returned. If the operator filters alarms in the Runtime for just Line 3 filler, only the alarms generated from the Line 3 filler will be returned. As a result, the operator who is looking to troubleshoot or diagnose a problem can quickly and effectively narrow the results of hundreds of alarms to just the alarms relevant for their investigation.


Alarm management standards such as ISA 18.2-2009 and IEC 62682 are practical guidelines developed by industry professionals to implement and maintain an effective alarm management system. These standards are, however, just one piece of a larger equation.

Contact us to learn how zenon HMI/SCADA can help you convert these standards into reliable, dynamic, and effective alarm management solutions.

See “Alarm Management Challenge 4: Quality of Values and String Processing” here.

Alarm Management Challenge 4: Quality of Values and String Processing

Thursday, September 3rd, 2015

Energy_AMLIt’s a matter of fact that the communication quality to the PLC very much influences the alarm generation in the SCADA system. If the communication is bad, interrupted, or even lost, the system generates a flood of alarms which might lead to false conclusions. Therefore, the quality of values is essential. Another common challenge is the monitoring of string values via alarming features.

zenon’s Alarm Management Solution 4: Reaction Matrix

The most powerful tool for a global alarm definition, status supervision and string monitoring in zenon is the Reaction Matrix, known by zenon users by its abbreviated name ReMa. The Reaction Matrix differs from variable and datatype limits in a few ways, but most notably in its linking. Where limits are defined directly on the variable or datatype, the Reaction Matrix makes it possible to define a global alarm condition and reuse it for multiple variables. For example, in an automation system using zenon, there could be 300 valves and all valve statuses are read in as an integer for the defined states. Since all valves have a common value reading for their states, the Reaction Matrix is perfectly suited. The engineer must create only one reaction matrix with this configuration and it is then simply linked to all instances of the valve.

In addition to the global aspect of the Reaction Matrix, zenon also offers the ability to use a Numerical Reaction Matrix, a Binary Reaction Matrix, or a String Reaction Matrix. The Numeric Reaction Matrix gives the user the option to define the alarm set points in terms of less than, greater than, or equal to a specific numeric value. It also has a unique feature to “treat any value change as a limit violation”. The Binary Reaction Matrix gives the engineer the ability to define alarm conditions based on the state of individual bits of a word. The String Reaction Matrix can be linked with any string variables being read from the PLC to generate an alarm. Value monitoring can be achieved with static values or even with wildcards.

State-based alarming:

In zenon Runtime a variable always consists of the following three things: (1) the variable value, (2) the variable timestamp, and (3) the variable status. The variable status is maintained for every zenon variable and is composed of 64 individual status bits to always give a clear indication of the real-time or recorded variable status, whether it was a good status, communication fault status, alarm suppressed status, etc.

The main benefit of the Reaction Matrix is that not only can it analyze the value of a variable, it can also generate alarms or event conditions based upon a specific status bit. Or sometimes even more important: it can suppress alarms if the status information does not fit. For example, if there is a communication problem no alarm will be triggered. This makes it quite easy to avoid thousands of alarms during a communication problem with the PLC.

See “Alarm Management Challenge 3: Multiple Points of Configuration” here.

Alarm Management Challenge 3: Multiple Points of Configuration

Thursday, August 27th, 2015

Many alarm systems in use today require an additional alarm server or require tags to be configured multiple times, adding to inefficiencies in engineering and hindering the process of creating a proper alarm management system.

zenon’s alarm management solution 3: tags defined one time, object-oriented engineering

With zenon, variables are only defined once. For example, if a pressure transmitter is being read from an Allen Bradley ControlLogix PLC, this is just one variable in zenon. This one pressure transmitter variable can be displayed on HMI screens, recorded in the Historian, plotted in the Extended Trend diagram, or used to generate an alarm. Therefore, if the alarm condition must be modified for the pressure transmitter it must only be done once, in a single location.

To take object-oriented engineering a step further, zenon supports the creation of custom and structured datatypes. All zenon variables are based upon a driver (e.g. Siemens S7), a driver object type (e.g. Ext. Datablock), and a datatype (e.g. Real). There are multiple benefits in creating and using custom datatypes in zenon. For example, it is possible to create a custom datatype for the pressure transmitter. This can be set as a Real datatype and will inherit the properties of the default Real type in zenon. The new pressure transmitter can then be customized even further by adding the measuring units of psi, showing three decimal places, and defining a series of four limits on the datatype.

Custom datatype example in zenon

Custom datatype example in zenon

As you can see in the figure above, the creation of this custom datatype for the pressure transmitter will take an engineer approximately five minutes to configure and check. The savings and benefits come in at the next step, since the engineer must display 150 pressure transmitters in the SCADA system, each with the above configuration and limits configured. This process in zenon will only take the engineer one minute since he is able to create an array of 150 elements for the pressure transmitters which will automatically inherit the properties set on the pressure transmitter datatype set in the figure. Of course, individual instances can still be customized and “unlinked” with the datatype.

Not only is this a huge time saver, it also guarantees that every individual pressure transmitter is configured accurately. If, after two weeks of operation, the operations manager wants the Low-Low limit for the pressure transmitter changed to only alarm at < 56 psi, the engineer only needs to make this change at the pressure transmitter datatype, and all 150 pressure transmitters will be updated automatically with the new Low-Low limit of < 56 psi. After the configuration is changed, the zenon Editor downloads the updated files to the Runtime server via zenon Remote Transport over the network, then the engineer remotely reloads the project with a mouse click. The changes are live and deployed throughout the zenon network to all connected servers, clients, and web clients in just a few moments, all happening without any downtime, operational inconvenience, or concern.

See “Alarm Management Challenge 2: Managing a Diverse Infrastructure” here.

Debugging zenon Control during Runtime

Thursday, May 28th, 2015

To extend interface functionality of zenon for special projects it is necessary to develop modules or dll files which can take on special computation or visualize different interface controls.

Two different methods exist for testing or debugging the dll that has been developed: either by attaching to the process or by starting the zenon Runtime as an external program. Developers can attach Visual Studio to the zenon Runtime process through:

Debug menu > Attach to Process… and the Attach to Process dialog opens




The following steps are needed for debugging a dll:

  1. Develop a dll
  2. Embed dll in zenon editor
  3. Set a breakpoint in code design (F9)
  4. Run zenon
  5. Attach Visual studio to the zenon Runtime process

After that, if the end user uses the control, the breakpoint will be activated if the breakpoint is placed inside the invoked code.




In another method of testing and debugging of the control without attaching to the zenon Runtime process, the Project properties must be set.

Project properties > Debug Part > Set Start external program by using the browse button




The following steps are needed for debugging a dll:

  1. Develop a dll
  2. Embed dll in zenon editor and make a runtime file
  3. Set breakpoint in Code design
  4. Set Start external program option in Project properties to the path of zenon runtime program
  5. Run the control via Visual Studio (F5)

Visual Studio builds the dll first and then runs the zenon Runtime program, because a zenon project which contains the dll control has been created before, therefore any update in dll is applied to control in Runtime without opening the zenon Editor.

(The COPA-DATA Blog Team would like to thank Parisa Moosavi from EDAG Production Solution for her zenon insights)