COPA-DATA Blog

zenon Analyzer not only offers manual report generation, it enables the creation of reports based on schedules and can generate them event-driven. The event-driven report generation is able to create reports based on external events, such as the end of a lot production. In this case, the zenon Runtime works hand-in-hand with the zenon Analyzer.

General description:

This functionality needs to be implemented in zenon using a VSTA macro. The triggering event starts this macro which sets the parameters like report template name, rendering format (e.g. pdf, jpg, html, …), time filters, event classes, … to the zenon Analyzer, using the Reporting Services Web service interface. The zenon Analyzer processes the report and returns the rendered report to the VSTA macro of the runtime for further processing. The VSTA macro can store the report in a file share or send it by message control as an email attachment.

Detailed description:

1. Information collection:

First the required parameters, which are needed to call up the VSTA macro, are determined. Two different

types of parameters exist. Those which are necessary for the report itself and those which give additional information and control the report generation.

Report parameter:
In order to be sure about the report parameters, we suggest to open the report in the Microsoft SQL Server Report Builder 3.0 and check them in the parameters section.

Other parameters;
Are rendering methods and project name.

2. VSTA programming:

Creating a Web service reference:
To create the required reference you can use the VSTA-Editor or the wsdl.exe (Web Services Description Language), provided by several Microsoft SDKs (.NET SDK, Windows SDK, Visual Studio, …)

C#-code:
It is important that the macro is running in its own thread, otherwise the runtime will be blocked and a deadlock is created!

In the C#-code the following parameters are passed to the zenon Analyzer:

• rendering method
• project
• report execution parameters (e.g. time filters, …)

Now the VSTA macro waits for the report to be processed from the zenon Analyzer and be returned to the runtime. The macro now can save the report under any name on the hard drive or send it as an email extension with message control.

3. Finally the C#-code needs to be saved as a ProjectAddin.

Possible usages:

• manual activation with a button in the runtime
• automatic activation for violated limits
• automatic activation using scheduler or Production & Facility Scheduler
• automatic activation using a time control function

Although the C#-code has a limited length, it would exceed the scope of this blog.
For implementation comprehensive documentation, including code samples, is available.

Introduction Although most .Net solution are developed using c#, in some cases porting existing old code (from vba) to VB.Net might be more efficient than starting from scratch in c#. This blog entry explains which methods and functions are to be implemented in order to have a VB.Net Wizard displayed in the zenon Wizard dialog which pops up when creating a new project. Similar, yet different in small details

compared to the c# scenario. Integrating VSTA-Code into the wizard dialog In order for VSTA-C ode to be available in the wizard dialog the automation code needs to be contained (implemented) into a Windows-Form. Additionally the Form-Class needs to

implement the following set of static functions (all without parameters): Public Shared Function GetWizardName() As String Return the name of the wizard, displayed as “Name of the wizard” in the wizard dialog. Public Shared Function GetWizardInfo()

As String Return a description of the wizard, shown as “A more detailed description of the wizard.” in the wizard dialog. Public Shared Function GetWizardCategory() As String Returns the category of the wizard and is displayed as “Wizard category” in the wizard dialog. Note: An existing category can be used here. And a VSTA and a VBA wizard can reside in the same category. Public Shared Function IsZenOnWizard() As Boolean This function determines whether the wizard should appear in the dialog. It offers the possibility to stop a wizard from appearing without having to delete all functions or removing it from the Addin. Public Shared Function GetWizardVersion() As Integer This function returns the version number of the wizard, indicated next to the wizard information. Public Sub StartWizard() This method is called when the wizard has been selected in the wizard dialog and confirmed with “OK”. NOTE: It’s not allowed to have any functions with the same name inside of the wizard class, not even if their return type of parameter count is different from the “Wizard-Functions”.

Introduction

In average day working with the zenon Editor quite a few actions are required for each project. Actions like creating a default set of users, common drivers, default templates, etc. can be time consuming. Obviously these actions can be replaced and automated by use of VSTA-code in

the editor. But if

these actions are to be performed for each new project, it would be more efficient if the actions could be triggered in a more comfortable way: By use of the integrated Wizard dialog which pops up when creating a new project in zenon.

Integrating VSTA-Code into the wizard dialog

In order for VSTA-Code to be available in the wizard dialog the automation code

needs to be contained (implemented) into a Windows-Form. Additionally the Form needs to implement the following set of static functions (all without parameters):

static public string GetWizardName ()
Return the name of the wizard, displayed as “Name of the wizard” in the wizard dialog.

static public string GetWizardInfo ()
Return a description of the wizard, shown as “A more detailed description of the wizard.” in the wizard dialog.

static public string GetWizardCategory ()
Returns the category of the wizard, shown as “Wizard category” in the wizard dialog.
Note: An existing category can be used here. And a VSTA and a VBA wizard can reside in the same category.

static public bool IsZenOnWizard ()
This function determines whether the wizard should appear in the dialog. It offers the possibility to stop a wizard from appearing without having to delete all functions or removing it from the Addin.

static public int GetWizardVersion ()
This function returns the version number of the wizard, indicated next to the wizard information.

NOTE: It’s not allowed to have any functions with the same name inside of the wizard class, not even if their return type of parameter count is different from the “Wizard-Functions”. If all functions are correctly implemented and the Addin has been successfully compiled, the Form will appear in the wizard dialog.

Problem:
When a Macro with a zenon Object zenOn.IRecipes is set to null execute thrice the zenon RT can be crash.
Usually zenon Interface Objects (e.g. IVariables, IAlarms …) returns a pointer of the zenon-COM-Object but in the case of the IRecipes the zenon Interface returns a copy of the Object. If you set any zenon Interface Objects = null the pointer will released. In the case of the copy, the copy will exist until the Garbage Collector has time to release the Object. This depends on the CPU-Capacity and other .NET internal things. If the Macro is called again and the Garbage Collector doesn’t have the time to release the object, the Object will have a not valid condition and zenon RT will crash.

Example:

public void MacrocoloreSuVariabile()

{

zenOn.IRecipes projectRecipes;

zenOn.IRecipe ricetta;

zenOn.IRecipeValue item;

try

{

projectRecipes = this.Recipes();

if (projectRecipes != null)

{

ricetta = projectRecipes.Item("RICETTA_UNIFILARE");

if (ricetta != null)

{

for (int r = 0; r < ricetta.Count; r++)

{

item = ricetta.Item(r);

if (item != null)

{

item.Value = Convert.ToDouble(r);

item = null;

}

}

ricetta.ExecuteValues();

ricetta = null;

}

//This will cause the crash
projectRecipes = null;

}

}

catch (Exception ex)

{

Debug.Print("ERROR : " + ex.Message.ToString() + " " + ex.Source.ToString());

}

}