Posts Tagged ‘Ergonomics’

Ergonomics of Sustainability, Innovation & Continuous Integration (Part 3)

Wednesday, July 13th, 2016

In the previous blog articles we looked at the information that is essential to understand before initiating any upgrade sequence with zenon. In this article, we will look more closely at the specifics of updating a standalone system.

As a reminder, these are the possible zenon network types:

  • Standalone (single PC, no zenon network active)
  • Client – Server (single server)
  • Client – Server (redundant server)
  • Client – Server (circular-redundant server)

In our first example, we are going to upgrade a standalone system with one zenon project running from a zenon 7.20 system to zenon 7.50.

Step 1: Read back or import the Runtime project files in the Editor project in the old 7.20 version. Make sure that in the Editor for the current version of the project the settings for “RT changeable data” concerning de-compilation settings are set correctly.

Step 2: Create a Project or Workspace backup in the current 7.20 version.

Step 3: Install the zenon Editor of the new 7.50 version on the Engineering PC. Now both zenon Editor versions, 7.20 and 7.50, are installed and can be used (by starting them through the zenon Startup Tool).

Step 4: Upgrade the standalone Runtime.

Stop the Runtime and install the new version of the Runtime. Hint: Installation without demo projects is advisable.
Now both zenon Runtime versions – 7.20 and 7.50 – are installed on the PC. In the worst case scenario, you can always go back to using the 7.20 Runtime.
Following successful installation of the new Runtime, start it.

Hint: The installation changes the paths for the Runtime start. StartupTool: Enter the path to your project in the StartUpTool for the new 7.50 entry.
zenon Remote Transport: Retransmit the project and reset the start project on each client PC before restarting.
Now the Runtime of version 7.50 is executing the zenon project from version 7.20.

zenon_product_version_connectivity_-10You can now choose to follow steps 5a or 5b.

Step 5a: On the engineering PC, start the new version of the Editor. Compile the Runtime project files for the new version. Remote Transport the Runtime project files for the new version to the Runtime PC and reload the project.

Step 5b: You achieve the same result if you transfer the new Runtime project files to the Runtime PC before starting the Runtime of the new version. In this example, I would rate this as the preferable sequence.

It is up to you what sequence to use, I am simply outlining the possibilities here. This gives you the flexibility to plan your upgrade process according to your own needs.

Downtime lasts, in this example, for the duration of the installation of the new zenon Runtime and its subsequent start.

Upgrade Engineering PC only:

Perhaps you don’t want to upgrade the Runtime; you would prefer to continue to run it in version 7.20? No problem! You can do this by updating only the Engineering PC.

In the process described above, leave out Step 4 and do not install the Runtime of the new version.

Instead, on the engineering PC, start the new version of the Editor, compile the Runtime project files for zenon 7.20 and use it for the Runtime running in version 7.20.


  1. You can still serve older Runtimes with Runtime project files of its version where there is no need to use zenon’s latest features.
  2. At the same time, with the same Editor, you can create new projects using the new version and benefit from zenon’s latest developments and features.

zenon is flexible: it is up to you what sequence you use. Do it your way.

In the next blog post, we will have a look at a client-server system and how the upgrade proces s works there.

Ergonomics of Sustainability, Innovation and Continuous Integration (part 2)

Thursday, June 30th, 2016

The first blog post of this series gave some background information about compatibility of diverse zenon versions.

When we talk about a zenon version we need to be precise and need to name exactly what we mean by it. This graphic outlines the different components involved and their respective version.

  • zenon Editor
  • zenon Runtime
  • zenon project runtime files
  • zenon Runtime data (version independent)

Runtime data is all the data created by the zenon runtime, like *.aml, *.cel, *.arx, *.bin and so on.

zenon_product_version_connectivity_-09 zenon_product_version_connectivity_-11

The versions of the zenon Editor and the zenon Runtime are usually known by system integrators and end customers. What is less well-known, because it is hardly visible from the outside, is that compiled Runtime project files also carry a dedicated version for which they are compiled. Runtime data is basically version independent.


A zenon project, no matter what version it was created with, can always be converted to the very latest zenon version. This effectively makes zenon a safe haven for your investment into a project.

In order to improve your zenon project with the latest features you must convert it to the new zenon version. Ideally, upgrade to the most recently released zenon version in order to benefit from the very latest developments and new features.

How to convert even very old zenon projects, to the very current zenon version is explained in detail in the Online Help, see “Manual -> Project Conversion”.

The current zenon version offers a direct restore for zenon projects of versions 5.50 SP7 and newer.

HINT: Mind that for an optimum conversion from 5.xx projects, the 32 bit version of the editor should be used.

ATTENTION: Always check what differences between versions are important to consider for your project before executing a conversion.

Always check the following sources:

  • Release notes of your new version
  • Documentation & Online Help ( F1) -> Manual -> “Project Conversion”
  • Knowledge Base on Service Site for known Issues tagged with “Compatibility” or “Conversion”

Before a project can be changed in a zenon Editor it must always be converted to the exact version of the zenon Editor. This is done automatically on loading it for the first time into the zenon Editor. Please bear this in mind when restoring a backup of an older zenon version in the Editor of a newer zenon version. The project can also be loaded from the existing projects in the database, and this also follows the same sequence. Conversion takes place on a project basis which means that, when restoring a workspace backup containing multiple zenon projects, it should be done project by project.


The project from a newer zenon version cannot get loaded to an Editor of an older zenon version, neither through a backup nor through opening an existing project! If you attempt to do this, a message box appears. This shouldn’t ever be a problem, since zenon project files can be compiled for older zenon Runtime versions (thanks to zenon’s Editor compatibility).


As mentioned before, conversion takes place at the point a zenon project using a former version is opened in the zenon Editor of a newer version. During this process, for safety reasons, a backup of the former version remains stored in the zenon backup folder, so the original project can always be used if required.
Everything you create remains available to you.

The Runtime project files can get compiled (F7) anytime from the zenon Editor project files.

Before we start, I would like to underline two important points to consider:

  1. Always make sure you have the updated license details for the new zenon version available.
  2. Test first – always carry out a first test with your project, during the upgrade planning phase, on a test environment rather than on the live system.

In the next blog article, I am going to focus on the first upgrade sequence option.

Ergonomics of Sustainability, Innovation and Continuous Integration (Part 1)

Friday, June 17th, 2016


zenon_product_version_connectivityThe goal of zenon is to give you the best tool, a tool on the latest technical level, for you to be able to get a head start in offering exciting automation solutions to your customers. Speed, flexibility, motivation and sustainability matter.

At COPA-DATA we talk about the ergonomics of sustainability, innovation and continuous integration:

  1. To secure your investments done so far in a project
  2. To let you and your customers benefit from new product features and improvements at an early stage
  3. To allow an easy update process of your zenon system with lowest downtime for step 2 to be possible quickly, even in existing and running systems.

With zenon this is an easy process where you only have to focus on your core competence and the project and not so much on the application you created it with.

To excite your customers is the highest goal to reach and can be the crucial advantage to your competitors. For you to be able to excite your customer with new features and offer this even for systems already running the above-mentioned points are compulsory and are areas which zenon can offer solutions for.

In terms of our product zenon we talk about:

  1. Conversion
  2. Improvement with newly developed features
  3. Easy upgrade process for a continuous integration

With zenon your investments are safe and no matter what version of the product you started with first, you are anytime able to convert it to the very latest zenon version. This is an important point in order for you to be able to improve your existing projects with the newest developments and features currently available on the market, without the need to recreate anything again.

Point 1 and 2 is presumably well known to you, Point 3 is probably not so common. This is why we are going to focus in a series of blog articles to address it in order to bring the possibilities to your attention.

System changes during the lifecycle of the production equipment are very unpopular, upgrades are often delayed as much as possible, mostly till they are unavoidable. But this hinders you also from improving the whole system by letting it benefit from recent developments and new features.

One reason is often that this creates a long or undefinable downtime of the production. We at COPA-DATA believe that an upgrade can be done quickly, reliably and safely. This blog series will outline how this can be accomplished on a zenon system with the shortest downtime.

The key word is Compatibility.

COPA-DATA has invested significantly in features and functionality built into zenon, to provide engineers and end users with the highest amount of true compatibility options.

You can find the most important functionalities described in the Online help:

  • Editor Compatibility:
    F1 -> Manual -> Editor -> Compatibility
  • Runtime Compatibility:
    F1 -> Manual -> Runtime -> Runtime files -> Compatibility Runtime files
  • Runtime files:
    F1 -> Manual -> Runtime -> runtime files

These already published blog articles also address the compatibility features:

In this series of blog articles I would like to outline this procedure in more detail and explain the technical background.

In the next blog post I am going to deal with the conversion process.

Multi-Touch features in zenon 7.20

Friday, June 26th, 2015

The way we interact with computers has changed in recent years and since then most people are used to directly manipulating interfaces by using gestures. Also with zenon Multi-Touch features the user literally stays in touch with what is going on in the work process. In zenon 7.20 we equipped the operator with new Multi-Touch features, which can easily be adapted.


In zenon 7.20 you can use freely definable frame shapes for movable screens, as the Demo login screen shows.


Frames can be moved without having a title, a system menu or a min/max button. Also freely definable frame shapes can be used for native interaction. To illustrate how to create such frames, let’s have a look at the login screen of the zenon Supervisor demo project as an example:

Create a new frame with a freely definable frame shape and give it any shape you like. In the demo, a rectangle and a polygon with rounded corners was used. After creating a freely definable shape, position the frame where you initially want to have it in the RT.


In the frame’s property settings you can individually define position settings and movability.

Now, to make the login frame movable, go to the frame’s property settings, activate “always in the foreground” and set the following positioning settings: Opening size as “frame size”, no limitation minimum and restrict the movability to display borders. The property “minimum frame margin” defines, how many pixels of a frame have to remain on the RT monitor and cannot be pushed outside the screen (however, in the case of free shapes only the bounding rectangle is considered). In the demo project, 70 px were defined as margin.

Afterwards, create a screen with this frame. Now comes the “creative” part: Fill the screen with elements (rectangle, templates, adapted tem¬plates, symbols…), align them and link functions and variables as usual, until you have your desired screen result.


When creating a faceplate screen with different screen containers such as an Alarm Message List, a Chronological Event List or trend elements, you now can use it as worldview as well. For instance, this feature could become interesting if you want to have an overview of a whole site containing several alarm or trend screen containers within one (touch) screen. The other way round, you can also use the screen container for displaying a worldview, e.g. when you want to display a touchable menu slider.


The configuration of worldviews can also be used for faceplates and screen containers.


Video: Paper on Glass and Electronic Batch Reports

Wednesday, June 10th, 2015

Paper on Glass’ is a very simple concept, with one main aim – to replace paper batch records with a mobile device. Pharma production is getting more and more complex. Watch this video to see how mobile devices powered with zenon reduce post batch analysis time and increase Right First Time (RFT).

The problem with paper

Paper is used a lot in pharmaceutical production environments; it drives the operator through the production sequence and records critical processes. It forms the base to prove each batch is of high quality and compliant to the regulations. But today’s Pharma production is becoming more and more complex, and in parallel the international regulations are increasing their demands.  Paper also needs to be printed and stored in secure environments for long periods of time. Using paper to drive production in Pharma, is like standing outside in a storm ripping up $100 bills:

  • Paper is manually intensive and RFT is less than 50% when using paper to drive production.
  • ⅔ of rejects are down to simple human failings: Missing entries and incorrect entries.
  • Collation of production data and analysis takes 15 to 40 days post batch

Paper on Glass: Putting automation in the hands of the operator

Using a batch engine gives you a consistent sequence in production, with clear instructions and safety information. Information is recorded from the operator directly into the historian. Missing entries are eliminated, and incorrect entries are also eliminated as far as possible. The collation of data is automatic and complete, batch recording and analysis documentation is instantly available.

Validation efficiency

No change to equipment or processes is needed. Production is being produced on exactly the same equipment, using the same workflow, with the same documentation.

Video: Paper on Glass and Electronic Batch Reports with zenon

Take a look at this Video to increase RFT, quality, and production efficiency with ‘Paper on Glass’.

In this video, you will see:

  • How to change your workflow without changing equipment or processes
  • Example applications in zenon
  • Batch Reporting possibilities

Substitution with Index Parameter

Friday, April 24th, 2015

Things can quickly become complex when it comes to creating a project. In order to keep the overview in your work process, ease of use is an important topic. That is why zenon supports the user with an object-oriented and central workflow concept.

You might already know substitution features like linking rules, index variables or manual index editing. By applying them, screens as well as functions can be created once and reused for different content. This will not only save you time but will also help you to keep your project sleek and clearly structured.

Nevertheless, there are situations where using such functionalities can slow down your workflow. Taking index variables as an example, you not only create the variable but also need “write set value” functions and scripts in order to make it work. The effort is not always worth the benefit. To bypass such a scenario, zenon now offers an additional possibility to substitute screens and functions: “Replace indices” with parameter.

Substitution dialog of a function

Substitution dialog of a function

Let’s say you have three tanks and need to have a detailed screen of every single tank with all its variables. You have already created a “screen switch” function and a detailed screen for the first tank.  In the substitution dialog of the function you can create an indexing rule by entering a source variable, e.g. “Tank1”, and add a target, instead of using an index variable, type {PARAM} at the position. From now on, you can also apply this edited function for the other two tank buttons.
As a last step, set the parameter for substitution directly at the element properties of the button. This new feature not only works with a button but with a combined element and Combo-/Listbox too.

Element properties (of a button) – Variable/function

Element properties (of a button) – Variable/function

Graphics Technology Update in zenon

Friday, April 17th, 2015

zenon WorldviewErgonomics in HMI applications depends to a considerable extent on the capability of the runtime system to conduct graphical operations in a high-performance manner. The evolution of Multi-touch functionality and the contribution of natural user interactions particularly require a certain level of graphics performance in order to achieve a smooth and appealing behavior. One key parameter here is how fast the system can react to user interaction and, in turn, deliver the necessary responses on the graphical level. A screen refresh rate of around 25-30 frames per second is generally said to be sufficient to let a dynamic display feature appear “fluent”. This will – amongst other parameters – decide upon the level of user experience you´re about to reach in your application.

The use of native means of graphics processing prepares the foundation to handle high-performance HMI requirements with a respective level of responsiveness. The term “native” in that context relates to techniques which are designed for a close interaction with the operating system and which are optimized for use on a respective hardware platform.

Since version 7.00 zenon provides graphics rendering modes based on DirectX 11 for Windows server- and PC operating systems. Besides the option to operate the graphics processing on the CPU core(s) of the local system – which is available for any setup – the graphics processing can be supported by a dedicated DirectX graphics card. In this way, the system profits from an optimized computation of graphics-related operations and the freeing up of local computing resources.

The current zenon version comes with an upgraded version support for DirectX 11.1. What appears to be a minor step in the graphics engine’s version, offers considerable performance advantages due to optimized utilization possibilities in zenon. Specific interaction features, such as movable or resizeable frames or more complex worldview display constellations potentially benefit from this technological update. Hence, with the background of rapidly evolving HMI demands, another step is made to keep things running smoothly.

Improved handling of scripts in zenon 7.20

Thursday, April 2nd, 2015

With the current zenon version, we continued to make working with scripts easier and more efficient. The first change you might notice regards the script-functions “Script: execute” and “Script: select online”. The previous dialog was replaced by a new selection dialog – which should be more familiar to you as it is used commonly throughout zenon. It offers you all the functionalities to search for a script, see what is inside the script, modify the script and even create a new script on the fly. This already saves a lot of time during engineering but as you know, there is always one more thing …

The new script selection dialog

Up until zenon 7.11 working with scripts was done the long way around: You had to go to the Scripts-node of the project, create a new script and configure it, switch to the Functions-node, create a “Script: Execute”-function; find your script again, etc. Then finally link the new function to e.g. a button to actually use it in the Runtime.
7.20 makes your life a lot easier now: On all places in zenon, where you can link a function (except at a script of course), you now have the possibility to directly select a script instead of searching the “Script: execute” function. The enhanced function selection dialog offers you the additional editing possibilities of our new script selection dialog. But it gets even better: instead of having to do the legwork and searching a matching “Script: execute” function (or create a new one) this is automatically done for you in the background.
Linking multiple functions at e.g. a button just got way easier.

The enhanced function selection dialog

The enhanced function selection dialog

Get the most out of the zenon redundancy

Thursday, March 12th, 2015

RedundancyWith zenon version 3.51, released in 1996 COPA-DATA introduced the first version of the highly sophisticated seamless zenon redundancy. This feature is implicitly available with each zenon installation and does not require any additional licensing. For almost 20 years the zenon redundancy has been configurable via an ergonomic one-click configuration and is used in thousands of applications. With zenon version 7.11 COPA-DATA enhanced the zenon network with two additional redundancy concepts to provide more flexibility in designing the zenon network.

Redundancy mode DOMINANT

If DOMINANT mode is selected, the well-known network behavior is in operation. This means, a dedicated PC is defined for the role of server and standby. As long as the server PC is available, this PC will be in the server role. If the server PC fails, the PC defined as standby will jump into the server role. The second PC will go into standby again if the PC defined as server is back on duty.

Redundancy mode NON DOMINANT

In NON DOMINANT mode PC1 and PC2 are equal in terms of the server role. In this network constellation it doesn’t matter which PC is currently in the server or standby role. The PC which was started first will run in the server role, the second PC as standby. If the server PC fails, the standby PC will take over the server role. This PC will also continue as server even if the former server becomes active again. The reestablished PC will jump into the standby role. Due to this behavior there is no need to do a redundancy switch after a reconnection of the standby PC. If there is no dedicated requirement for a DOMINANT or RATED network environment, COPA-DATA suggest using the NON DOMINANT mode for your projects.

Redundancy mode RATED

On top of the above described network modes there is the redundancy mode RATED. In this mode an evaluation based on process variables will decide, which PC should be the active or standby server. In the editor a rating-matrix can be defined; this matrix is used to evaluate the best suitable network constellation during runtime. For example, if the primary server loses a connection to a PLC due to a network failure but the current standby is able to communicate to this PLC, a redundancy switch will be performed in order to keep as many datapoints connected to the field as possible.

With the enhancement of the redundancy functionality zenon provides most flexibility in designing the network topology according to specific requirements of each single project.