Archive for the ‘Information’ Category

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.

Conclusion

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_and_Out_of_Process_Code_EN

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:

Tabelle_S25

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.

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.

Security: Is the HTML Web Engine secure?

Wednesday, May 11th, 2016

Security has the highest priority

Measures such as encrypted communication based on security certificates or user authentication contribute to protecting the system.

User Authentication

Web_Desktop_Login

This is fully based on the zenon Runtime User Management (including Active Directory). You can set user levels in the zenon RT for example, to prevent somebody who is not authorized from getting into the HMI areas.

Please note

It is important to note that the Web Engine is not a secure solution per se. It is – for instance – not recommended to ever publish web content directly to the internet. Surrounding (standard IT) security concepts have to be considered.

HTTPS

The Web Engine recommends and sets the IIS to use HTTPS by default – in order to do this a self-signed certificate is created.

HTML5 visualization with the zenon Web Server – Licensing

Friday, April 22nd, 2016

Which license is required for the HTML Web Engine?

A Web Server Pro or Web Server is required for the HTML Web Engine.

Production Process Overview (HTML)

Production Process Overview (HTML Web Engine)

From zenon version 7.50 on, the zenon Web Server can provide visualization as an HTML5-compliant web page. HTML5-compatible web browsers are thereby always in a position to process and display visualization content; regardless of the type of device or operating system.

The HTML Web Engine, which is included in the zenon Editor checks the licensing of the zenon Web Server. The functionality of the HTML Web Engine is adapted based on the licensed Web Server versions as follows:

Web Server Version:

Only read access to the visualization. The HTML Web Client can be used as a viewer.

Web Server Pro Version:

Full access to the visualization, read and write.

NB: the number of simultaneous client connections given by the Microsoft IIS is limited. If there is no license, the HTML Web Engine is started in a time-limited demo mode. Once the demo period and the demo extension has expired, the HTML web engine can be started in demo mode again.

Does the HTML Web Engine run under “Web Server Pro Light”?

No, the HTML Web Engine doesn’t run unter Web Server Pro Light.