Posts Tagged ‘Compatibility’

Ergonomics of Sustainability, Innovation & Continuous Integration (part 4)

Monday, August 8th, 2016

In the previous blog post we explained how to upgrade a zenon standalone system. This time we are going to focus on a zenon Network server-client system.

On a zenon Network server-client System we have to bear in mind that more than one operator works with the system. This makes the upgrade sequence a bit more challenging as the uptime of the whole system becomes more important.

The good news is that the whole zenon system can get upgraded step by step. There is NO need to shutdown the whole system for an extensive upgrade period. This is a crucial advantage when it comes to the step-by-step planning of an upgrade sequence.

“Client only” PCs in a zenon network can always be upgraded prior the upgrade of the Server PCs. This way, only the PC being upgraded is temporarily unavailable while the rest of the zenon network runs uninterrupted.

zenon has worked this way since zenon 7.00, based mainly on zenon’s Runtime Compatibility function. For more about Runtime Compatibility check out the zenon online help (F1) -> Manual -> Runtime -> Runtime Compatibility.

Upgrade Scenario:

In our second example, we are going to upgrade a zenon network client server system with one zenon project running, from a zenon 7.20 system to zenon 7.50.zenon_product_version_connectivity_-12 Step 1: Read back and import the Runtime files into the Editor project in the old version 7.20. Make sure that, in the Editor for the current version of the project, the settings for “RT changeable data” concerning decompilation settings are set correctly.

Step 2: Create a workspace backup in the current version 7.20.

Step 3: Install the zenon Editor of the new version 7.50 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.zenon_product_version_connectivity_-08zenon_product_version_connectivity_-11 Step 4: Upgrade client Runtimes (all except Server 1 of the project).

Stop the Runtime and install the new version of the Runtime.

Hint: Installation without demo projects is advisable.

After successful installation, enter the path to your project for the new 7.50 entry in the Startup Tool.

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.

Step 5: Start the new 7.50 Runtime. The same unchanged zenon project files of 7.20 will be synchronized from the process-leading server 1. Now, the Runtime version 7.50 on the clients is executing the zenon project of version 7.20.

zenon_product_version_connectivity_-13Step 6: Upgrade Server 1 just like you upgraded the clients in the previous step.

Warning: this will result in some downtime.

Stop the Runtime and install the new version of the Runtime.

Hint: Installation without demo projects is advisable.

After successful installation, enter the path to your project for the new 7.50 entry in the Startup Tool.

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.

zenon_product_version_connectivity_-14Step 7: On the Engineering PC load the project -> this will be converted to zenon 7.50. Compile the project for zenon 7.50.

Step 8: Transfer the zenon project files of version 7.50 to Server 1 using Remote Transport.

Step 9: Start the new 7.50 Runtime on Server 1 with the Startup Tool.

Step 10: The zenon project files will be synchronized to all clients automatically.

Hint: On very large zenon network installations, the network bandwidth can be a crucial factor to keep an eye on. This should be considered during the planning phase.

Depending on what you prefer to work with – the Startup Tool, the Remote Transport or the Network Topology – Steps 7 through 9 can vary a bit.

zenon is flexible and offers a tool for all your needs: do it your way!

Now your whole zenon system runs entirely on zenon 7.50 and you can benefit from all the new features available.

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.

Advantage:

  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.

Conversion:

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.

zenon_product_version_connectivity_-08

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).

Backup:

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

Introduction

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.

Compatibility in zenon – exploit potential, carry out updates easily and efficiently (part 2): an example

Thursday, May 8th, 2014

The compatibility mechanisms in zenon make it possible to use different versions of the software in a network structure. This way the overall system is available at all times when a version is changed – even if individual computers are switched off during the software administration.

An example involving a conveyor system

Automotive_BodyshopThe system consists of three individual projects: feed-in, storage and feed-out, which are connected via an integration project. The individual projects each have a redundant server pair and a total of 15 connected clients. The additional zenon Web Server provides the project with five web clients on the intranet. The proven zenon version 6.xx is used.

Without the compatibility in zenon, an update would be as follows: the user would have to convert all data into the desired version with the zenon Editor. At a defined point in time, they would shut down the whole system in order to install the new version – at the same time as far as possible. Then they would transfer the converted data and the whole system can be started again. Now the new version is tested: if any noticeable problem arises, the whole system must be searched to identify the cause. In the worst case, the whole system must be moved back to the original version in order to restart production.

Runtime compatibility

Thanks to the compatibility mechanisms in zenon, a zenon update is much more relaxed and can even be carried out during operation: zenon Runtime can operate with the project data from older versions without conversion with no problems at all. A connection to a server running or communicating with older versions is also possible. In practice, this means that each computer can be updated without changing the project. In doing so, the individual stations are only offline for the duration of the installation. The whole system remains available during the updates and the stations continue to be operable. Another advantage is that the alarms and archive logging are also retained and are safeguarded, because the server is also completely available thanks to redundancy.

Forward compatibility

If the current version of zenon is installed on all computers, the project conversion can be started. It is sufficient to open the projects with the zenon Editor: when reading back project backups from older versions, the project data is automatically converted upwards after you are requested to confirm you want to do this. Now the user only needs to import the settings configured in Runtime, such as user passwords or recipes, and then create the Runtime files for all projects. If these are transferred to the respective server by the zenon Editor, they can be updated without interruption using the “Hot Reload” function: this function integrated into zenon automatically distributes the updated project data from the servers to the connected clients. An identical project status is therefore available on all networked zenon stations. With the method described, all Runtime computers are updated to the current version in the first stage and then the Runtime files are converted to the desired version with the zenon Editor in the second stage.

Backward compatibility

In addition to the above-mentioned compatibility mechanisms, zenon also offers backward compatibility: if companies use a current zenon Editor, they can also read in project backups from older versions. The Editor files are automatically converted to the respective version in the process. It is therefore possible to work with the most recent zenon development tool, to benefit from the latest functions and to also create Runtime files for older Runtime versions with the current development tool. To do this, it is only necessary to set the target version in a selection box in “Project properties”. The Runtime files created this way can then be transferred to the older systems and used there.

The compatibility that zenon offers provides companies with the freedom to plan migration strategies on a long term basis and to quickly react to market trends. The administration and maintenance of existing systems is thus very easy and also very safe.

Compatibility in zenon – exploit potential, carry out updates easily and efficiently (part 1)

Friday, May 2nd, 2014

The highest degree of equipment availability, uninterrupted production processes and maximum productivity are the complex objectives of automotive concerns. Software updates for production equipment are often seen as a possible risk factor that can impair these objectives. However, you are on the safe side with zenon.

Never touch a running system – hardly any rule is quoted in the IT field as frequently as this one. If a system is able to work and run, you should change as little as possible in order to avoid interruption to production, breakdowns or faults.

Risk factor update

Automotive manufacturers are also skeptical of system changes during the lifecycle of their equipment. Our many years of practical experience and many conversations with users have taught us that many companies delay updates as much as possible – often until it is unavoidable. They usually only make exceptions if there are new manufacturing requirements – for example, a product change – or when major updates to the operating system or security updates are necessary.

Unexploited potential for modernization

The withdrawal of support for Windows XP means that a number of automotive manufacturers are facing the challenge of switching their system. This is perceived as a challenge because version changes and updates can hide risks and may cause, for example, equipment failure or interruptions to production. At COPA-DATA we believe an update should be capable of being implemented quickly, reliably and safely. zenon makes this possible. At the same time, companies also have the potential to benefit from the new features and innovations of the HMI/SCADA solution to the full extent

Compatibility in zenon: well thought out, simple, safe

Thanks to the compatibility mechanisms in zenon – which have been a component for many versions – companies can significantly reduce the work involved and the attendant tests and checks. Forward compatibility, backward compatibility and Runtime compatibility take the load off the user considerably. zenon makes it possible to separate the individual steps for updates and also allows the checking of individual steps in ongoing production. The overall system is constantly available thanks to the redundancy in zenon.

In my next entry you can read about a practical example, involving a conveyor system that benefits from zenon’s compatibility.

Is it possible to have more than one zenon version on my engineering station?

Thursday, November 14th, 2013

Many COPA-DATA Partners & System Integrators are facing the same challenge. They have to support the projects of various end customers. Most of the time these projects are maintained in different zenon versions.

For the engineering interface – the zenon Editor – that’s not a challenge because it is able to load any older project backup downwards to zenon Version 5.50 (Already mentioned in my Blog entry from the 31/10/2013).

What happens in detail when a zenon project in the Editor is upgraded to a new Editor version?

The process always follows the same steps, independent of the zenon versions. Option A: A project backup from previous versions is restored into a new zenon version.

  • The Editor recognizes a zenon project backup from previous versions; this information is stored in the project.ini file of each project.
  • The user is asked to adjust the project version to the new Editor. This is necessary because there might be changes in the database backbone of the Editor, like a new version of the MS SQL Server.
  • Afterwards the user is prompted to enter a target folder for the restored project. It is recommended to use a new folder rather than the project folder of the original project. The default folder for zenon projects is always C:\Users\Public\Documents\zenon_Projects.
  • Afterwards the project conversion is complete. The original backup file remains unchanged so it is always possible to go back to the previous zenon editor version.

Option B: Via the Option “Insert existing project …” a project of an older version is inserted into a workspace.

  • Again the Editor recognizes the previous project version and asks the user for confirmation of the conversion.
  • The only difference to option A lies in the fact that the zenon Editor automatically generates a backup of the project in the previous version before the conversion takes place. This backups are easily recognized, there naming uses the following Syntax: “before converted to …”

This backup can be found in the project tree under “Backups”. So there is always an easy way back into an older version.zenon Compatibility

How to convert a project from version 5.50 into zenon 7?

In principle, the same steps are necessary. Only that for projects of Version 5.50 a two-step conversion is necessary. First from zenon 5.50 into any zenon 6.xx version and then into any zenon version of generation 7.

But how can I handle the Runtime systems and how can I test my project locally on one and the same physical environment?

In principle the answer is easy. The various zenon versions can be installed in parallel on the same system. The zenon setup sees that every version gets its separate folder / registry keys etc. For the operator, we deliver the zenon Startup tool in which all the zenon versions are automatically included. Just select the appropriate version, start the registration process and run the corresponding Editor or Runtime.
The Editor offers a setting for the compiler through which the engineer can choose for which Runtime version the zenon project should be compiled. The compiler then automatically creates the Runtime files in the correct version.

zenon Compatibility

Can I also only convert parts of my project into a new Editor version / a new zenon project?

The best way to only convert parts of an existing project into another is to use the XML export / import interface of the zenon Editor.

  • This XML interface is kept compatible with the various zenon versions. This means one can export his tag list or screens out of an older version like generation 6. Afterwards, simply import the XML file into an Editor of generation 7. zenon sees that everything is converted correctly.
  • The XML files can be used as a kind of external database / library which is version independent.
  • The zenon import / export interface is designed in a way that with a new version there are only new objects or attributes added to the XML format. The old items are kept and always readable for a newer generation of the Editor.
  • The same strategy is followed for example with the zenon API (the programming interface) -> it is always kept compatible.

 

32- / 64-bit systems – are they compatible, or do I need to use the same technology for all components?

Friday, November 8th, 2013

Since zenon Version 7.10, our product has been available in a 32-bit & 64-bit edition. Some might be confused where the difference is or how this effects an application. This blog entry is designed to solve some of these mysteries.

32-64-BitThe setup provides both editions automatically. So there is no add-on or separate edition to purchase or install. The setup automatically recognizes if the computer is a native 32- or 64-bit system and installs either one or both editions of zenon. Or, in other words, on a 64-bit machine the user is free to choose which edition he wants to run. Simply choose the corresponding button in the zenon Startup Tool.

On a 64-bit machine you will now find two installation folders; one for 32-bit components and one for 64-bit components:

  • C:\Program Files (x86)\COPA-DATA\zenon 7.10 SP0
  • C:\Program Files\COPA-DATA\zenon 7.10 SP0

The version independent files are compatible with both versions and can still be found within:

  • C:\ProgramData\COPA-DATA\zenon710

The following components in zenon are available in a 64-bit version. The rest, for example the drivers, remain as a 32-bit component, but they are automatically loaded into the 64-bit environment:

  • Editor
  • Runtime
  • Process Gateway
  • Webserver
  • zenon Services

As the two versions are kept completely compatible by COPA-DATA there is not much more a user needs to take care of.

  • It makes no difference if a zenon project is designed in a 32-bit Editor and later opened in the 64-bit Editor (or the other way around).
  • Choose freely between Editor and Runtime. Use your maintenance Laptop based on a 32-bit technology, use the Remote Transport to copy and run the project on a 64-bit based server machine.
  • Also, it is not a problem to have a mixture of both editions in the Runtime. Run the server projects on a 64-bit technology while the still use a 32-bit environment.

So keep it simple, choose the technology that fits your environment best and enjoy zenon!

Is `compatibility´ a feature I have to switch on in my project?

Thursday, October 31st, 2013

Sometimes I have been asked the question if zenon compatibility is something like a dedicated feature that I have to kind of “switch on” or consider in the design of my projects?
The straightforward answer is “No”. Compatibility is something deeply integrated into the zenon Product Family. Any zenon user automatically profits from it.
There is only one possible project property a use can choose: “Create RT Files for”.

Compatibility_1_1

Per default the zenon Runtime Compiler is set to the actual Editor version. But any user of a zenon Editor can choose to compile the loaded project for a specific, older, zenon Runtime version. The Compiler then automatically compiles zenon Runtime files which can be loaded by older runtime systems. The advantage for the engineer is obvious. He gains the possibility to always use the latest Editor version with latest engineering features and there is no need to install / maintain different versions of the engineering tool. Use of the Compiler guarantees that even features that are not available in an older Runtime version are not causing any problems in the old Runtime. The worst thing that could happen is that a screen element, for example, is not visible in the old version. Other than that the engineer has nothing else to consider when designing his HMI / SCADA applications. The rest is done automatically by zenon and works backwards to zenon version 6.20 SP4.

COPA-DATA also offers a concept for the Runtime compatibility. This is also a built-in feature and nothing the user has to configure. The zenon Runtime system in a client server structure can use different runtime versions. For example, the Server and Client Runtime versions can be different. A zenon Server can be updated to the latest zenon Version 7.10, while the Clients remains on the “old” zenon 6.51. The user obtains full flexibility to choose which technology is installed in his facility. A mixture of versions on different clients is also possible – the zenon Runtime Servers will talk to all of them. Again, the zenon Runtime automatically regulates that only items / data are communicated that is fitting to the client version. This is nothing that needs to be considered while engineering the HMI / SCADA application. The only recommendation COPA-DATA gives is that both Servers (Main & Standby Server) run the same zenon versions to ensure the data integrity.

Compatibility_1_2In terms of Network Compatibility there is one restriction to consider. Since version 7, zenon is one of the few systems that is already supporting and addressing IPV6 based IT networks. It is possible to activate an IPV6 based communication for all the zenon Servers and Clients in the zenon startup tool.

The restriction to consider is: A mixture of IPV4 and IPV6 based Clients or Servers within one zenon network architecture is not possible. That means that all the communication within one zenon network must follow one technology. Either IPV4 or IPV6. Also important to know: up until now there are no PLC’s that support IPV6 that we are aware of, so PLC communication is still based on IPV4.

Why zenon is world champion in compatibility

Thursday, August 22nd, 2013

We at COPA-DATA put great emphasis on the issue of compatibility. For us, compatibility is a key characteristic of an ergonomic software solution. That’s why we are on the way to becoming world champion in compatibility.

Compatibility is a great topic, in any sense – that’s why we think ten pillars are necessary to support the concept:

  1. Editor Compatibility:
    Imagine, your projects are already 10 years old and want to convert them to current versions. With zenon – no problem at all! You can convert your projects directly without intermediate steps.
  2. Backward Compatibility:
    Keep your old Runtime systems and profit from the latest engineering technology. With zenon you can always use the latest version of the Editor for efficient engineering and just compile the Runtime data for the older Runtime system.
  3. Runtime Compatibility:
    You can use cutting edge technology for your visualization network, independent of the variety of versions you use. Just update your servers to the latest version and keep your Clients untouched. zenon ensures that everything runs smoothly.
    Furthermore, with zenon you don’t have to worry about losing data from older versions – because zenon’s data compatibility allows data from older versions to be displayed.
  4. Import/Export Compatibility:
    Data files can be generated in an older version older versions but used in a new version.
  5. Product and Engineering Compatibility:
    When using an ergonomic software like zenon, ergonomic engineering is also a major topic. Screens and data can be generated with one tool for all devices. Regardless of whether you want to see the screen on Windows Client, CE Terminal or Web Client.
  6. Operating System Compatibility:
    You can rely on trouble-free operation with any Windows operating system. There is no need for you to spend time on it in the engineering phase.
  7. Technology Compatibility:
    You can use your PC resources without changing the applications – no matter if 32-bit or 64-bit architecture.
  8. Hardware Compatibility:
    It’s your free choice, which devices you use – whether you need to use zenon on Panel, PC, PLC or Tablet – we have the right solution. Also, screen solution is not a problem at all. Adjustments can be made easily.
  9. Network Compatibility:
    You can plan IPV6 network structures in order to be prepared for future requirements.
  10. API Compatibility:
    Individual adaptations, ActiveX Controls, wpf controls, .Net controls can be created once and reused in newer versions.

Further benefits:

In addition to all the benefits previously mentioned for project engineering, the high level of compatibility has three further advantages. Firstly, it means high level of security on investment. Secondly, engineering costs can be kept low. And thirdly, the maintenance efforts are reduced by comprehensive connectivity.