Posts Tagged ‘Programming’

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.

In or out? This is how you can find out whether your C# code would prefer to exist in its own application.

Wednesday, September 7th, 2016

It’s always the same question: VSTA, ActiveX, .NET control or perhaps an EXE after all? So, we’d like to give you some new food for thought and criteria for making the best decision.

First things first: whether program code is best executed within the main application or as its own process depends very much on the particular case in question. There is no single rule for this. This blog post shows the differences, as well as advantages and disadvantages of both variants.

In principle, we distinguish between two types of code during considerations: code that is executed within the same process and that which is executed in a separate process.

The first type includes VSTA, ActiveX, .NET controls and all other variants whereby your code is loaded into the main application as DLLs. In this case, the main application and your code share the same virtual address space and use the same main thread. Mutual calls between your code and the main application are normal assembler calls, without overhead, so to speak.

If your code runs in a separate process, it has its own virtual address space and its own main thread completely to itself. It thus runs at the same time and completely disconnected from the main application – generally even on a different processor core. Mutual calls between this code and the main application do, of course, entail much more work, because it concerns a communication between two processes, the so-called interprocess communication. This means that each call beyond the process limits takes a relatively large amount of time. COM is generally used as the interface on Windows operating systems. The interprocess communication with COM works internally by sending Windows messages to hidden windows of the other application. A call can therefore even take up to a millisecond and is very dependent on system load. In principle, this speed disadvantage also applies to any other interface suitable for interprocess communication and is even more pronounced in most of them (sockets or pipes for example). A major advantage for the developer is that COM works exactly the same, regardless of whether it is used on an intraprocess or interprocess basis.

The zenon API

In the case of zenon, the complete zenon API is implemented as a COM interface. It can also be identically addressed by the same C# code – regardless of whether this runs within or outside of zenon Runtime. As a result, it is also not a problem if you only decide on the other variant later on.


In addition to the issue of how it works in runtime, there are other areas where differences occur. The following table provides an overview to help you in the decision-making process:


Making a decision

If there is no knockout criterion in deciding for one or the other, we recommend comparing the number of mutual calls and the processing intensity of your code with one another. If many API calls and events are expected, internal code (such as VSTA) will be able to play on its performance strengths. If your code requires a lot of computing power, is memory-intensive and complex, but is rather loosely connected to the main application, then an external application has significant advantages when it comes to side effects, scalability and freedom of development. It is important in each new case that you ask yourself the question: in or out? Sometimes it can even make sense to execute a part of the code in zenon Runtime and another part as a separate process. There is no patented recipe for this, but zenon can competently support you with both variants.

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)

Create a zenon Project template in Visual Studio

Thursday, May 21st, 2015

In reference to IU-17,.Net Windows Form Controls in zenon, Page 26 for extending interface functionality of zenon, developers can develop controls by performing a special configuration in Visual Studio .Net.
To simplify the development of a control by Visual Studio .Net a zenon project template can be created which is reusable. Furthermore, a zenon control template can also be created in the same way if necessary.
An eligible zenon project contains a control and can be integrated in zenon but must include several prerequisite settings mentioned in IU-17,.Net Windows Form Controls in zenon, Page 26.

Create a project type: Windows Form Control Library

Register the control as a dual control through registering for COM interop.

Make the managed control visible for COM and set ClassInterface attributes.

Add necessary entries and ActiveX attributes in the code designer.

Take necessary steps to register control as an ActiveX in the Registry.

How to parametrize template

After configuring the project it must be customized with parameters for further use as a template. Each project must have a unique GUID for registering therefore this GUID must be generated automatically for each project creation. To implement this, the “$guid1$” parameter must be used instead of existing GUID in AssemblyInfo.cs file.


The second position which needs a unique GUID in the template is the class of control. It must be changed as follows and the GUID must be replaced with “$guid2$”.


How to create a template

After replacing the guids with parameters which are reserved template parameters, the template can be created.

  1. File menu > Export Template. The Export Template wizard opens.
  2. Project Template option must be selected.
  3. The current project must be selected in the list.
  4. Click Next.

Assign a name to the zenon project template.

  1. Assign a description.
  2. Assign an icon to the project template and all the assigned values will be shown in New Project dialog.
  3. Click Finish.
  4. The result of creating a template


For further information Microsoft’s reference links can be used.

Using a predefined project template lessens the probability of errors during development. Because for developing a control for zenon environment are some settings necessary which can be forgotten and with lack of them, control cannot be created how it’s expected.

To remove the template from Visual studio .Net

It’s enough to delete the zip files from the following folders:

  • My Documents\Visual Studio Version\Templates\ItemTemplates
  • My Documents\Visual Studio Version\Templates\ProjectTemplates



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

Avoiding possible problems caused by .NET controls exposed via ActiveX

Wednesday, August 14th, 2013

Microsoft .Net Logo (Source File, .jpg)zenon allows the use of ActiveX controls for extending the user interface. A series of Information Unlimited articles shows how such ActiveX controls can be created using a .NET Framework programming language. As the .NET Framework is managed code, the .NET ActiveX controls are  destroyed by a garbage collector at any time if the reference count reaches zero. Additionally, the garbage collector must recognize that the ActiveX control is not referenced by any other object in order to be able to destroy it. This managed way of destroying .NET ActiveX controls can lead to serious problems.

Problems that might occur with .NET ActiveX controls with a simple user interface

One problem that might occur is that there is no garbage collection between closing a screen in zenon Editor and closing zenon Editor itself. A .NET ActiveX control that hasn’t been destroyed when zenon Editor is closing causes the zenon Editor process to remain active after closing the zenon Editor window. Since there can only be one running zenon Editor instance on a computer, this leads to problems when zenon Editor is started again:

  • If it is started by a different user, the user trying to start zenon Editor will receive an error message that another user is currently using it although the other user has closed zenon Editor.
  • If it is started again by the same user, zenon Editor will show up immediately but without a workspace loaded. If the user then tries to load a workspace, zenon Editor crashes, because it is in the terminating state after hiding the main window and therefore no longer ready for user interactions.

In zenon Runtime this problem also might occur, but zenon Runtime terminates after running through its teardown routines without waiting for garbage collection of .NET ActiveX controls.
To fix this issue, garbage collection is triggered on closing screens in zenon 7.10 and higher.

Problems that do occur with .NET ActiveX controls with a complex user interface

But what happens if the garbage collector cannot recognize an object as deletable and when does this occur? If a .NET ActiveX control reaches a certain user interface complexity (child controls nested in other child controls, event handlers for those child controls and object members holding a reference to the control), the garbage collector cannot recognize the control object as deletable after the screen hosting it is closed. If that occurs, the problems described above will occur, in addition to leaking memory every time a screen with such a .NET ActiveX control is shown. As the mentioned fix only triggers garbage collection, it does not resolve problems caused by such .NET ActiveX controls.

So what can be done to resolve this problem (apart from not using .NET ActiveX controls)? First of all, it is recommended to avoid instance members holding a reference to the control wherever it is possible. If there is no way to avoid such members, they have to be cleared in the same method where the user interface is cleared (see below). As it is the complex user interface that prevents the garbage collector from destroying the object, the user interface objects must be cleared when the user interface is no longer needed. This can be done by implementing the .NET ActiveX control methods




and calling


in both those methods. The following code sample is given as an example:

public bool zenOnExit()
return true;
public bool zenOnExitEd()
return true;

With this knowledge it is easy to avoid the described problems by simply including the two zenon exit methods in every .NET ActiveX control that is used.

zenon 7.10 and Windows 8 Multi-Touch – Programming in VSTA – Part 2

Thursday, July 18th, 2013

WP_000608In our previous blog entry we talked about the possibilities of custom Multi-Touch programming in VSTA with the help of the zenon API. We focused on the raw WM_Pointer messages. This time we will have a look at gestures in VSTA.

Gestures in VSTA

There is the same pre-filtering concept for gesture events as for the raw touch events. At each dynamic zenon element (e.g. a button) and on each screen, you can select the gestures you are interested in (more specifically, you are configuring an Interaction Context, which processes the raw touch events in the background and searches the gestures you selected).

In VSTA you can react on these events by using

  • ElementGesture
  • PictureGesture
void DynPics_PictureGesture(zenOn.IDynPicture obDynPicture, object interactionContextOutput)
string CelString = string.Format(“VSTA: {0} on {1} “,
System.Reflection.MethodBase.GetCurrentMethod().Name, obDynPicture.Name);

More detailed information about the contents of the interactionContextOutput-object can be found in the MSDN documentation.

zenon 7.10 and Windows 8 Multi-Touch – Programming in VSTA – Part 1

Thursday, July 11th, 2013

In the previous blog entries regarding Multi-Touch we talked about the natively integrated features in zenon 7.10. However, the creativity of our customers has no limit and zenon, being an open system, supports the integration of custom solutions e.g. via VSTA.


The new features Windows 8 brings to Multi-Touch can be used directly via the zenon API (VSTA only, because of 64-bit). If you take a closer look at what’s happening in the background when moving your finger around the screen for example, you will find that a lot of single events are being generated. On the one hand this means that you get a lot of data you need to sort through by yourself and on the other hand a great deal of performance is wasted. When talking about Multi-Touch events we need to distinguish between two types:

  • Raw touch points (WM_POINTER messages)
  • Preprocessed, recognized gestures, e.g. a manipulation

Raw touch points in VSTA

This time we are focusing on the raw touch points: zenon 7.10 now allows you to pre-filter these messages at each screen, so if you are only interested in receiving PointerDown and PointerUp messages you don’t have to handle everything else and analyze thousands of events to find the right one. In VSTA you can react on events like

  • PointerActivate
  • PointerCaptureChanged
  • PointerDeviceChange
  • PointerDeviceInRange
  • PointerDeviceOutOfRange
  • PointerDown
  • PointerEnter
  • PointerHWheel
  • PointerLeave
  • PointerUp
  • PointerUpdate
  • PointerWheel

For example:

void DynPics_PointerDown(zenOn.IDynPicture obDynPicture, zenOn.IElement obElement, object vPointerId, bool bNew, bool bInRange, bool bInContact, bool bPrimary, bool bFirstButton, bool bSecondButton, bool bThirdButton, bool bFourthButton, bool bFifthButton, int lX, int lY)
string CelString = string.Format(“VSTA: {0} on {1} “,
System.Reflection.MethodBase.GetCurrentMethod().Name, obDynPicture.Name);
string ButtonMatrix = “”;
ButtonMatrix += (bFirstButton == true) ? “[1]” : “[x]”;
ButtonMatrix += (bSecondButton == true) ? “[2]” : “[x]”;
ButtonMatrix += (bThirdButton == true) ? “[3]” : “[x]”;
ButtonMatrix += (bFourthButton == true) ? “[4]” : “[x]”;
ButtonMatrix += (bFifthButton == true) ? “[5]” : “[x]”;
CelString += string.Format(“pointer-id: {0}, is-new: {1}, is-in-range: {2}, is-in-contact: {3}, is-primary: {4}, buttons: {5}, [X, Y]: {6},{7}”, Convert.ToString(vPointerId), bNew, bInRange, bInContact, bPrimary, ButtonMatrix, lX, lY);

For further information on this Pointer, please call up GetPointerInfo(VARIANT vPointerId) As VARIANT



Process dumps of 32-bit processes on 64-bit operating systems

Thursday, June 20th, 2013

64-bitSometimes it is necessary to snapshot the state of a process into a process dump file in order to analyze it in the debugger afterwards. Even if this is usually straight forward, creating process dumps of 32-bit processes on a 64-bit operation system could have some traps. Not paying attention to the architecture of a process could lead to unuseable dump files. This article tries to bring some light into this topic.


As with processes, there are 32-bit and 64-bit dump files. Now it’s the case that usually the process architecture of the process which intiates dump file creation determines if a 32-bit or a 64-bit dump is created independently from the process which is actually dumped. The reason why this could happen is, that on 64-bit operating systems 32-bit processes run in a type of 32-bit Windows emulation, called Windows-on-Windows64 (WOW64). So therefore also 32-bit processes have a small 64-bit part, making them seamlessly integrate into the totally 64-bit operating system. So if a 64-bit dump file from a 32-bit process is generated by mistake, it will contain some user mode-parts of this WOW64 emulation.

Rude awakening

What happens on opening a 64-bit process dump of a 32-bit process in Visual Studio at home depends slightly on the version of Visual Studio. Visual Studio 2012 tells you immediately: “Debugging a 64-bit dump of a 32-bit process is not supported, please collect a 32-bit dump of a 32-bit process.” With former versions of Visual Studio debugging can be started without any problem but in call stacks you will only see some lines containing “wow64cpu”. In this case you will notice that you have to delete your dumps and visit the site a second time to get new ones.

The simple solution

As mentioned already, the solution is rather easy. If you create your dumps with Task Manager, WinDbg or ADPlus, you only have to use the 32-bit version of these programs. You will find them in C:\Windows\SysWOW64 or C:\Program Files (x86)\… respectively. Please check in the Task Manager if the “*32” is added to the process name. So if you mind that the initiator process of dumping and the investigated process have the “*32” suffix, nothing should go wrong anymore. And the opposite way around, if your investigated process is a 64-bit process (no “*32” suffix in Task Manager), use a 64-bit dumping initiator.

Learn about zenon on