Running the Application

You can test the application in one of the following ways:

• Using Run> Test - Allows you to run the project in safe mode by activating the application with some protected features. Historical data, alarms, and events are written to temporary files so that they do not affect production logs, and communication modules cannot write data to IEDs.

• Using Run> Startup - Allows you to run the project in full operation, without the need to build the project.

You can run the project using both Test and StartUp at the same time.
For information on how to use the available diagnostic tools, see "Using Diagnostic Tools"

To test the application:

1. Follow one of the following options:

   • Go to Run> Test.

   • Go to Run> Startup.

2. Enter or select the information as needed.

• Click Run Test OR Run Startup to start running.

Tools for diagnosis

Once you have started running a project you can, using the Startup window, select some diagnostic tools, which show the windows:

• PropertyWatch (Watch)

• TraceWindow

• ModuleInformation (Info).

You can also start the diagnostic tools, as explained above, on the
Run-Test and Run-StartUp by pressing the left mouse button on the icons of the
diagnostic tools. If the menus are enabled for the Screens you can also access the Tools menu at run time.

Open

Info - Information from Modules

The Info - Module Information window contains information about the operation of the modules. For example, when choosing a Device module and a specific channel, you have a lot of information about how the communication channel works.
A very important point is the Read Information Groups because it provides information about the virtual read groups, the execution time of each item, the amount of reads and reads that failed, and also reports on the code and date/time of the last error.
For problem investigation, the following steps should typically be followed when using the Information Module:

1. Go to "Read Groups Information" to check the number of successes and failures in communication in order to quickly identify the communication blocks.

2. If you have a systematic error in all blocks, or status codes with negative values, this typically means that you cannot access the remote device. Make sure the node address is correct.

3. If you have either block with systematic error, check the tags and addresses related to the block. Use TraceWindow with Devices information to collect information about these communication errors.

4. For some protocols, such as OPC, dropped items will show wrong addresses in the configuration.

When running the application in test mode in The Enterprise Model, keep in mind that in this mode, only reads are performed from field devices, even if you have a setting to write to the field.
It is very useful to run the application with ONLINE CONFIGURATION enabled, so you don't have to stop/start the Device module when modifying the configuration. You can modify the PLC addresses in Points, AccessTypes, and most of the application and see in real time the results in execution. You can use Startup-Window or Propertywatch to start and stop only one module, such as Devices, instead of restarting the entire execution system.

Open

Watch - Tags, States and Properties

Property Watch is a diagnostic tool used for accessing real-time attributes and internal system tag properties for reading or writing. Simply type the name of the object property in the column and get its value in the Value column.

Open

Ex: Tag.Coils, Device.Channel.Modbus.Status. On the right side, we have properties of the selected object.
tag creation. These properties include value, timestamp, and quality.
The Action.NET uses for Quality coding the qualities defined by the OPC Data Specification.
See the main quality codes at "OPC DA Quality Codes"

Trace Window

The Trace window is the tool that reports system messages in a DataGrid (table) interface. When activating the module devices in the Settings button, we have information about the status of reads, writes, unsolicited, TX (send) and RX (received) frames.

Open

When you click the Settings in a configuration window appears where you can select which types of messages and modules, which will be shown in the datagrid of trace. This data that appears can also be saved to files for more thorough analysis. You can also set up an ObjectName tag by clicking the Add. Then a window appears with a menu to select objects to include in monitoring.

Open

Building and Packaging Projects

Open

The "build" function starts by pressing the Build in the desktop sub-menu panel Run, run, run. The desktop shown below appears for the function control. Build serves to recompile all project screens and scriptobjects for final verification of possible errors before project placement into production.
A thorough scan of the application logic is performed while preparing the files for the final production version. This operation is not required during project development, as all modifications are automatically and transparently compiled in the background while edits are made.
The workspace has two tabs with informational tables, not changeable. These are the build activity reports.
Messages - That shows the current status of each script and screen with information about potential errors or alerts about logic. If you do not perform a full Build, the BuildStatus column in this report shows any warnings or errors encountered during the background build process.
Double-click a line with a red X to go to the source code where is the line that generated this notice or error. The warnings are informative and do not serve for the script to run. Errors prevent the execution of the specified script, but do not affect the entire application. If a script or monitor has a notice, it will still run.

Open

History - Shows the list of BUILD runs made in this project, informing several details about each of these runs, such as date, error occurrence, product version, user who ran, and others.
References - It is a third tab that should be used for recording References to external or user code files used by the Scripts defined and used in the project.

Building projects

Periodically, you should run a full build ( Build):

• When you've made a lot of changes and you want a full validation and recompile of the entire project.

• When you want to assign a build number to a version.

• When you want to "package" the database. When the build is run, the system creates a backup of the current project file. If you want to save the project as it was before this build, rename the backup file.

• When you are preparing to make a publication, that is, create a read-only application for runtime, in a production environment.

To create the production application by Build:

1. Go to Run> Build> Messages.

2. If you want to "package" the database, select the "Pack database after build" option.

   • Packaging significantly reduces the size of the project file. The system creates a file with the backup extension, which is the database before packaging. Typically, you will want to package the database each time you run a build.

3. If you want to save all screens, select the option "Verify Symbols and Save all displays"

   • Be sure to use this option if you have made changes to the symbol library. This option applies to all modifications to the symbol library throughout the project.

   • The "include debug information" option should be selected if you want information to be debugged for scripts after Build.

4. Click the button Build.

References to external codes

In the tab References from the menu Build you can create references to external DLLs or check existing references.

Open

To create a reference to an external DLL:

1. Go to Run>Build>References.

2. Click the button Add DLL reference. The common MS-Windows window will be shown for selecting a file.

3. Navigate to where the DLL you want to reference is and click on it.

4. The Reference definition window shown below then appears. Enter or select the information as needed.

Open

To check existing references:

1. Go to Run>Build>References.

2. Click the button Verify References.

   • All external DLLs already referred to in existing scripts in the project will be shown in the DataGrid.

Project Version Control

This section presents the features in Action.NET for project versioning.

Control of configuration changes

The Action.NET implements several ways to help you keep track of project configuration changes:

• All configuration tables have for each record, the DateCreated, and the DateModified information.

• Or Run-Build-history logs and shows all build commands executed for the project. A project backup for each state can be available according to the user's settings.

• Or Info> Track> Tables shows all configuration tables, listing the number of rows each and whether they have changed since the last Build and the last Publish.

• Or Info> Track> Changes shows all project objects that have been modified. To enable or disable this functionality, you must be logged in as an application administrator. By default, object tracking is only activated after a Publish (publish) project, but you can activate at any time, regardless of whether or not you use the publish feature.

• In Info > Track > Releases - The list of all versions of publications made is displayed. The list shows the version, date of publication, the "build" number, and the user who performed the publication. Product, name, family, and other versions are also shown.

Publishing the Project

Publish (publish) the project creates a read-only version of the project, which can be placed in the final production environment without the risk of being changed.
IT IS NOT necessary to publish the project to install it in a final production environment. In scenarios where you still intend to have continuous changes to the project already in the field, it is simpler to place the main project file, TPROJ, directly on the production computer.
The benefits of publishing are that the system creates a compressed, read-only version of the project file. The created file has the same name as the project file, includes a published version number, and uses the TRUN extension.
Typical scenarios for command execution Publish are as follows:

• You want to deploy a read-only version of the project, for example, to comply with certified and regulated environments.

• You want to use the automatic version numbering system. The result of the publication is a TENG file. It also contains a version number, with a larger digit (1.0) and a smaller one (0.1) as part of the file name. In addition Info> Track helps manage published files, including the current Build number of the project.

• You want smaller project file size and faster loading of it at start-up, for example on machines, OEM and embedded systems. The TRUN file can be up to 5 to 10 times smaller than the TPROJ file.

• You want to protect the project from modifications.

To publish the project:

1. Go to Run> Build> Messages.

2. Select the desired build settings and click Build.

3. Go to Run> Publish.

   • The settings fields of the current project show the read-only status of the project.

4. Select the Publishing Settings you want.

5. Click Publish.

Runtime Information Objects

There are names of some runtime objects that provide information about project execution.
The namespace Info is the primary location for the runtime state. The main objects in the namespace that are:
Info.Project: Information about the project that is running
Info.License: license information
Info.Module: Information and start/stop command for modules
Info.Trace (): Displays a message in TraceWindow
Info.TestMode: Shows If The Project Is Running in Test Mode The Namespace Server has information about the server computer.
The namespace Client information about each client computer. running a graphical interface.
For the full programming reference on runtime objects, see http:// www.spinengenharia.com.br/help/an-2016/runtime/index.html.