ACE3600 STS Advanced Features

(1)

0

Advanced Features

ACE3600 System Tools

Suite (STS)

Version 15.50

6802979C15-J

AB

MOTOROLA, MOTO, MOTOROLA SOLUTIONS and the Stylized

M Logo are trademarks or registered trademarks of Motorola Trademark Holdings, LLC and are used under license. All other product or service names are the property of their respective owners.

(2)

COMPUTER SOFTWARE COPYRIGHTS

The Motorola products described in this instruction manual may include copyrighted Motorola computer programs stored in semiconductor memories or other media. Laws in the United States and other countries preserve for Motorola certain exclusive rights for copyrighted computer programs including the exclusive right to copy or reproduce in any form the copyrighted computer program. Accordingly, any copyrighted Motorola computer programs contained in the Motorola products described in this manual may not be copied or reproduced in any manner without the express written permission of Motorola. Furthermore, the purchase of Motorola products shall not be deemed to grant either directly or by implication, estoppel, or otherwise, any license under the copyrights, patents or patent applications of Motorola, except for the normal non-exclusive, royalty free license to use that arises by operation of law in the sale of a product.

This media, or Motorola Product, may include Motorola Software, Commercial Third Party Software, and Publicly Available Software.

The Motorola Software that may be included on this media, or included in the Motorola Product, is Copyright © by Motorola Solutions, Inc., and its use is subject to the licenses, terms and conditions of the agreement in force between the purchaser of the Motorola Product and Motorola Solutions, Inc.

The Commercial Third Party Software that may be included on this media, or included in the Motorola Product, is subject to the licenses, terms and conditions of the agreement in force between the purchaser of the Motorola Product and Motorola Solutions, Inc., unless a separate Commercial Third Party Software License is included, in which case, your use of the Commercial Third Party Software will then be governed by the separate Commercial Third Party License.

The Publicly Available Software that may be included on this media, or in the Motorola Product, is listed below. The use of the listed Publicly Available Software is subject to the licenses, terms and conditions of the agreement in force between the purchaser of the Motorola Product and Motorola Solutions, Inc., as well as the terms and conditions of the license of each Publicly Available Software package. Copies of the licenses for the listed Publicly Available Software, as well as all attributions, acknowledgements, and software information details, are included below. Motorola is required to reproduce the software licenses, acknowledgments and copyright notices as provided by the Authors and Owners, thus, all such

information is provided in its native language form, without modification or translation.

The Publicly Available Software in the list below is limited to the Publicly Available Software included by Motorola. The Publicly Available Software included by Commercial Third Party Software or Products, that is used in the Motorola Product, are disclosed in the Commercial Third Party Licenses, or via the respective Commercial Third Party Publicly Available Software Legal Notices.

For instructions on how to obtain a copy of any source code being made publicly available by Motorola related to software used in this Motorola Product you may send your request in writing to:

Motorola Solutions, Inc. Open Source Software Management 1301 E. Algonquin Road

Schaumburg, IL 60196 USA.

In your request, please include the Motorola Product Name and Version, along with the Publicly Available Software specifics, such as the Publicly Available Software Name and Version.

Note, the source code for the Publicly Available Software may be resident on the Motorola Product Installation Media, or on supplemental Motorola Product Media. Please reference and review the entire Motorola Publicly Available Software Legal Notices and End User License Agreement for the details on location and methods of obtaining the source code.

Note, dependent on the license terms of the Publicly Available Software, source code may not be provided. Please reference and review the entire Motorola Publicly Available Software Legal Notices and End User License Agreement for identifying which Publicly Available Software Packages will have source code provided.

To view additional information regarding licenses, acknowledgments and required copyright notices for Publicly Available Software used in this Motorola Product, please select “Legal Notices” display from the GUI (if applicable), or review the Legal Notices and End User License Agreement File/README, on the Motorola Install Media, or resident in the Motorola Product. MOTOROLA, MOTO, MOTOROLA SOLUTIONS and the Stylized M logo are trademarks or registered trademarks of Motorola Trademark Holdings, LLC and are used under license. All other trademarks, logos, and service marks ("Marks") are the property of the respective third party owners. You are not permitted to use the Marks without the prior written consent of Motorola or such third party which may own the Marks.

(3)

PUBLICLY AVAILABLE SOFTWARE LIST Name: Info-ZIP

Version: 2005-Feb-10 (2.32, 2.52) Description: General compression library Software Site: http://www.info-zip.org/

Source Code: The Source Packages for this software are available from the original Software Site, or may be acquired from Motorola. To obtain the Software from Motorola, please contact Motorola using the methods described in the preamble of this Legal Notices and End User License Agreement Document. License: This is version 2005-Feb-10 of the Info-ZIP copyright and license. The definitive version of this

For the purposes of this copyright and license, "Info-ZIP" is defined as the following set of individuals:

Mark Adler, John Bush, Karl Davis, Harald Denker, Jean-Michel Dubois, Jean-loup Gailly, Hunter Goatley, Ed Gordon, Ian Gorman, Chris Herborth, Dirk Haase, Greg Hartwig, Robert Heath, Jonathan Hudson, Paul Kienitz, David Kirschbaum, Johnny Lee, Onno van der Linden, Igor Mandrichenko, Steve P. Miller, Sergio Monesi, Keith Owens, George Petrov, Greg Roelofs, Kai Uwe Rommel, Steve Salisbury, Dave Smith, Steven M. Schweda, Christian Spieler, Cosmin Truta, Antoine Verheijen, Paul von Behren, Rich Wales, Mike White

This software is provided "as is," without warranty of any kind, express or implied. In no event shall Info-ZIP or its contributors be held liable for any direct, indirect, incidental, special or consequential damages arising out of the use of or inability to use this software.

Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions:

1. Redistributions of source code must retain the above copyright notice, definition, disclaimer, and this list of conditions. 2. Redistributions in binary form (compiled executables) must reproduce the above copyright notice, definition, disclaimer, and this list of conditions in documentation and/or other materials provided with the distribution. The sole exception to this condition is redistribution of a standard UnZipSFX binary (including SFXWiz) as part of a self-extracting archive; that is permitted without inclusion of this license, as long as the normal SFX banner has not been removed from the binary or disabled.

3. Altered versions--including, but not limited to, ports to new operating systems, existing ports with new graphical interfaces, and dynamic, shared, or static library versions--must be plainly marked as such and must not be misrepresented as being the original source. Such altered versions also must not be misrepresented as being Info-ZIP releases--including, but not limited to, labeling of the altered versions with the names "Info-ZIP" (or any variation thereof, including, but not limited to, different capitalizations), "Pocket UnZip," "WiZ" or "MacZip" without the explicit permission of Info-ZIP. Such altered versions are further prohibited from misrepresentative use of the Zip-Bugs or Info-ZIP e-mail addresses or of the Info-ZIP URL(s). 4. Info-ZIP retains the right to use the names "Info-ZIP," "Zip," "UnZip," "UnZipSFX," "WiZ," "Pocket UnZip," "Pocket Zip," and "MacZip" for its own source and binary releases.

Credits: N/A

Motorola Solutions, Inc. 1301 E. Algonquin Road, Schaumburg, IL 60196 U.S.A.

(4)

Connection to a Computer or Terminal... A-1 Connection to a Modem... A-2 Connection to GPS Receiver... A-3 Connecting a User Port to a Printer ... A-3 Connecting a User Port to an External Unit ... A-4 Connection to a Radio ... A-4 RTU-to-RTU Connection Using MDLC Protocol through RS232 ... A- RTU-to-RTU Synchronous Communication Using Plug-in Port... A- ACE3600 RTU-to-ACE3600 RTU Connection Using MDLC Protocol through RS485 ... A- ACE3600 RTU-to-MOSCAD RTU Connection Using MDLC Protocol through RS485... A- ACE3600 RTU-to-PC Ethernet Port Direct Connection without Hub ... A- ACE3600 RTU Main CPU to Expansion Module Direct Connection ... A- ACE3600 RTU Main CPU to Expansion Module Connection via LAN Switch... A-8

APPENDIXB:REMOTE STSMODEM SETUP... B-1 Hayes ACCURA 144 + FAX 144, V2.20E ... B-1 Hayes ACCURA 144 + FAX 144, V4.1 ... B-4 Motorola OnlineSURFR 28.8 ... B-5 Motorola OnlineSURFR 33.6 ... B-8 Motorola OnlineSURFR 56K... B-9 UDS V.3225 ... B-10 UDS V.3400 ... B-12 USRobotics Sportster 14400 Fax... B-14 USRobotics Sportster 28800 Fax... B-17 USRobotics Sportster 56K Fax ... B-20 Intel SatisFAXtion Modem/400e ... B-21 Multitech Leased Line Modem... B-24

APPENDIX C:PCCOMMUNICATION OVER MOTOTRBO... C-1

Installing the USB Driver (Windows XP) for the radio:... C-1 Programming the Radio ... C-2 Communicating over the Air via MotoTrbo Radio: ... C-2

(7)

Scope

This reference manual provides useful background information on ACE3600 advanced system features, communication features, and specialized utilities and features.

The system features include:  I/Os

 Automatic I/O Recognition  Power Management  Safe Firmware Download  Flash File System

 Accessing Database Variables via Coordinates  Event Driven Software

 Fast Events

 RTU and Power Supply Redundancy The communication features include:  Network Configuration

 MDLC over IP Communications (Static LAN, Dynamic – DHCP Client, or PPP)  Firewall

 Clock Functions and Synchronization  ACE IP Gateway

The utilities include:  Core Dump Logger  MDLC Encryption  Protocol Analyzer  PID Loop

 Enhanced PID  Irrigation

(8)

ACE3600 I/Os

I/O Configuration

The basic ACE3600 RTU can include up to eight I/O modules in any combination, arranged in a single frame and numbered 1-8. Optionally, I/O expansion frames can be added to the ACE3600 RTU, increasing the number of I/O modules controlled by the CPU module on the main frame. I/O expansion is based an expansion LAN switch installed on the main frame, and an expansion module plus a power supply installed on the I/O expansion frame. Up to 110 I/Os can be connected to the ACE3600, by using two expansion LAN switches on the main frame and thirteen I/O expansion frames. For details on setting up a system with I/O expansion, see the ACE3600 RTU Owner’s Manual.

The RTU’s I/O modules are configured in the ACE3600 STS I/O tab during site configuration (see figure below.) The module types are selected from a drop-down list and include an FLN number which is also printed on a label on the left side of the physical module. Two different DI/DO FET modules (FLN3553, FLN3554) are available, with up to 16/32 user connections which can be configured as either DI or DO, in groups of eight. For a list of the available I/O modules, see the ACE3600 STS User Guide or the ACE3600 RTU Owner’s manual.

The I/O tab includes a field, ‘Enable auto I/O modules recognition at startup,’ which instructs the unit to automatically recognize I/O modules when it is started up. This saves the user time when configuring the site in the STS. If automatic recognition is enabled, no I/O modules can be defined for the site and the I/O configuration must be uploaded from a unit. For more information, see Automatic I/O Recognition below.

Settings for I/O modules and individual I/Os can be set using the Advanced Configuration of the specific I/O module. This includes defining values such as DO power source, AI/DI filters, and AI differential. For details, see the Customizing the Configuration of a Site section of the ACE3600 STS User Guide.

(9)

ACE3600 I/Os

I/Os and the Application

The I/Os controlled by the RTU are represented by variables in the application database tables and manipulated by the application process rungs. The process of linking the database

variables to the physical I/Os of the site is performed before compiling the application in the Application Programmer. For more information, see Linking I/Os to the Database in the ACE3600 STS User Guide.

If a ladder application is downloaded to the RTU and the I/O configuration associated with the application does not match the I/O configuration in the unit, the application will not execute and an error will be sent.

If a site configuration is downloaded to the unit with a working application, the unit will restart and check the match between the I/O configuration associated with the application and the I/O configuration in the unit. If the two do not match, the application will not execute and an error will be sent.

If the system includes more than one site with the exact same I/O configuration, assigned to the same application, the I/O Link information can be distributed from one site to the other sites. During I/O link, the user can define input/output mask values to be used by the application if the I/O module loses communication with the CPU.

I/Os Hot Swap

The ACE3600 RTU has a hot swap capability, which means that an I/O module can be

removed from its slots and reinserted (or replaced by another module of the same type) without powering down the unit. The only exception to this rule is the main power supply module, which cannot be removed during normal operation.

If an I/O module is replaced by another module of a different type, the I/O link association will remain for any I/Os which are the same (e.g. DI in Frame 0 Module 1 linked to IN_1). For those I/O whose types have changed, a popup will be displayed explaining that those links will be erased (e.g. DI in Frame 0 Module 4 is now a DO).

I/O Module States

An I/O module can be in one of three states in the unit:

 Running: The I/O module in the slot matches the one in unit’s site configuration. (In this case the application can run.)

 Failed: The I/O module is missing or the module in the slot does not match the one in unit’s site configuration. (In this case the application cannot run.)

(10)

ACE3600 I/Os

Sleep Mode

Each I/O module can be switched by the user application program to Sleep Mode. In Sleep Mode, the module does not function and the power consumption is minimized. During Sleep mode, the user application program will get the predefined values (PDV) or keep the last value (KLV) for each I/O. The PDV/KLV values are set in the I/O link table of the application program. For more information, see the Application Programmer chapter of the ACE3600 STS User Guide.

Hardware Tests

The RTU’s I/O modules can be tested using the STS Hardware Test utility. I/O module parameters can be retrieved, the state of the I/Os can be scanned, and the application started and stopped. The I/O module LEDs can be turned on and off. Information on the I/O module power supply (DI/AI modules only) can also be retrieved. Individual I/Os can be tested. During hardware tests, various values and settings can be changed by the user. These changes will revert to their previous values/settings (saved by the system) under the following

circumstances:

 when the Hardware Test utility is closed,  after ten minutes have elapsed,

 when the stopped application is run or the frozen module is unfrozen. For more information, see the ACE3600 STS User Guide.

Freeze Mode

The STS Hardware Test utility enables the user to test inputs and outputs while the user program is running. The I/O module can be set to Freeze mode. No actual values will be read/written to the application until the module is unfrozen. The application will continue to run; all unfrozen I/O modules will continue to interact normally with the application while the frozen module will not be impacted by the application at all.

The user program will get the predefined value (PDV) or keep the last value (KLV) of each input in the module instead of the actual inputs value. The DO values will keep the last value they had at the time the module was frozen.

If the hardware test involves reading inputs only, the I/O module generally need not be frozen. When testing outputs, the I/O module should be frozen to ensure proper execution of the application.

If the user does not unfreeze the module, the STS will prompt to unfreeze it when closing the Hardware Test utility or after ten minutes have elapsed.

For more information, see the Performing Hardware Tests section of the ACE3600 STS User Guide.

(11)

ACE3600 I/Os

Select Before Operate DOs

As of firmware v14.00, the ACE3600 RTU supports Select Before Operate digital output (DO) relays for safe output activation in secure operations. The SBO feature is used to ensure that the correct output has been selected before actually activating the relay. The table below compares the activation of SBO relays to that of standard DO relays.

DO Relay Steps SBO DO Relay Steps

Selected relay is activated. (Scan out DO.)

Relay is selected.

Back indication (BI) is checked. (Scan in BIs of the module.)

Select back indication (SBI) is checked. (Scan in SBIs of the module.)

Relay is activated (either for a specific duration or forever)

Back indication (BI) is checked. (Scan in BIs of the module.)

Reset SBO.

The SBO feature can be implemented in the user ‘C’ or ladder application. The application can perform each SBO operation separately (select, check, operate) or have the system perform the select, check and operate automatically. The user specifies the duration of the relay operation (or forever) as a parameter.

IMPORTANT: Unlike standard DOs (where several DOs can be activated at once), only one SBO DO per RTU can be activated at a time. However, a single Scan In of the ‘Select’ Back Indication and ‘Activate’ Back Indication can be done at once for all DOs in a specified module.

Site Configuration for SBO Relays

The following I/O parameter is configured for the RTU in the Advanced tab of the STS site configuration.

SBO relay check hardware timeout <0-65535> msec [50]:

Time to wait for the hardware Check. After this timeout, a hardware failure message is sent. (Internal use only).

SBO relay select timeout [5000]:

This parameter determines how much time may elapse between the Select and the Operate. After this timeout, the SBO DO will be reset (the Select is aborted.) This parameter is only relevant when the user calls Select, Check, and Operate separately. When the system performs the SBO automatically, this parameter is not checked.

(12)

ACE3600 I/Os

SBO DOs in User Ladder Applications

The SBO functionality can be programmed in a user ladder application. The following four functions can be called using the CAL operator. (The function name is the first parameter of the CAL operation.)

Function Name Description

SBO Performs Select, Check and Operate on the specified SBO automatically. SBO_select Performs Select of the specified SBO. After calling this function, the

user program should check the SBI back indication.

SBO_operate Performs Operate of the specified SBO. This function is called after the check indicates that the desired SBO DO relay was selected. The duration of the operation is determined in the SBOduration Reserved Value.

SBO_reset Resets the current operation and selection. All SBO DOs are unselected.

The specified SBO is a discrete output (d-o) type which is I/O linked to SBO_1 – SBO_X in a specific module. To link the output:

1. In the ladder database, generate a (d-o) column in a single or multi column table. 2. Link the specified I/O (rack and module) to SBO_X using the drop-down list. 3. Pass the linked cell to the CAL operator as the second parameter. (You can use a dynamic index.)

In order to check the select back indication(s) SBI after selecting a DO, you must do as follows:

1. In the ladder database, generate a (d-i) column in a single or multi column table. 2. Link the I/Os (rack and module) to SBI_1 – SBI_X using the drop-down list. 3. Scan in the column.

In order to check the back indication(s) BI after operating a DO, you must do as follows: 1. In the ladder database, generate a (d-i) column in a single or multi column table.

2. Link the I/Os (rack and module) to BI_1 – BI_X using the drop-down list. 3. Scan in the column.

For details on the CAL operator, see Appendix B: Ladder Diagram Language of the ACE3600 STS User Guide. For details on programming ladder applications, see the Application

Programmer section of the ACE3600 STS User Guide.

SBO Reserved Values

Three indicators in the Reserved values system table can be used by the ladder application to check the SBO status and associated errors. These are as follows:

SBOduration - This value can be used to set the operation duration (in units of 1 msec).

(13)

ACE3600 I/Os

SBOstatus - This value indicates the status of the SBO process (i.e. if the SBO was selected or

operated already). In this way, the application can know whether to check back indications or whether another SBO operation can be generated.

SBOerror - This value is indicates the type of error from the last SBO step.

For details on these three values, see Appendix C: Database Tables and Data Types of the ACE3600 STS User Guide.

SBO DOs in User ‘C’ Applications

The SBO process can be programmed in a user ‘C’ application using the following functions: MOSCAD_SBO (rack_module, SBO, duration)

- Performs Select, Check, and Operate on the specified SBO DO in the specified I/O module for the specified duration.

MOSCAD_SBO_select (rack_module, SBO)

- Performs Select of the specified SBO DO in the specified I/O module. MOSCAD_rm_SBO_check (rack_module, p_check_bits)

- Performs Check of the specified I/O module and returns the check bits status for the module. MOSCAD_SBO_operate (rack_module, SBO, duration)

- Performs Operate on the specified SBO DO in the specified I/O module for the specified duration.

MOSCAD_SBO_reset();

- Resets the current SBO operation and selection. All SBO DOs are unselected. MOSCAD_rm_get_num_sbo_bits (rack_module)

- Returns the number of SBO DOs in the specified I/O module. MOSCAD_rm_get_num_sbo_bytes (rack_module);

- Returns the number of bytes to allocate for the specified module (one byte for eight SBO DOs.)

For more information on SBO routines, see the ACE3600 RTU ‘C’ Toolkit User Guide. For more information on using SBO DOs in the user application, see the ACE3600 RTU ‘C’ Toolkit User Guide and Appendix B: Ladder Diagram Language in the ACE3600 STS User Guide. For details on the SBO DO module, see the ACE3600 RTU Owner’s Manual.

I/O Expansion

Before reading this section and implementing the I/O expansion feature, please consult the detailed description in the ACE3600 RTU Owner’s Manual.

(14)

ACE3600 I/Os

I/O expansion is not available for ACE IP Gateway units or IRRInet-ACE RTUs. I/O expansion is available for ACE3600 RTUs from firmware version 13.00.

I/O Expansion Frames in the ACE3600 Database

The ACE3600 application database includes information on the RTU components, including expansion frames (up to 13.) Some information appears per RTU (for example the error logger has an indication for all expansion frames) and some information appears per frame.

Two new dedicated system tables, the Expansions Reserved Flags and Expansions Reserved Values, monitor and control important system flags and values of a single expansion frame. Likewise, two columns of the Main Power Supply<n> system tables display values of a single expansion frame. Before using any columns in the Expansions Reserved Flags or Expansions Reserved Values system tables, or the expansion related columns in the Main Power

Supply<n> tables (whether to scan in or scan out), the user application must first call the GtExDt ladder call or the MOSCAD_GetExpData ‘C’ Toolkit function to set the desired expansion frame to be the current frame. After that call, the relevant flags/values will be displayed in the database.

For further details on the database tables, see Appendix C: Database Tables and Data Types of the ACE3600 STS User Guide. For further details on the MOSCAD_GetExpData ‘C’ Toolkit function, see the ‘C’ Toolkit for MOSCAD Family RTUs manual.

I/O Expansion Configuration

A number of I/O expansion parameters and advanced parameters can be configured. A

predefined port configuration ‘I/O Expansion Comm.’ is provided for Ethernet communication over LAN using a predefined static IP address. Other parameters define the timeouts and IP addresses required for proper communication between the main frame and the expansion frame(s.)

For details, see Appendix A: Site Configuration Parameters in the ACE3600 STS User Guide. Note: In an I/O expansion system with an activated firewall, the IP address range of all

expansion frames configured in the system must be listed in the firewall approved list, as well as the IP address of the main CPU expansion port. For details, see the Firewall parameter in Appendix A: Site Configuration Parameters in the ACE3600 STS User Guide.

These IP addresses are comprised of:

1. the number set in the I/O expansion module’s rotary frame number selector switch (1-13)

plus either

2. the ‘Expansion module first frame IP address’ advanced parameter (if it is not 0.0.0.0) or

the Self IP address from the 'ETH1->I/O Expansion Comm. port configuration (if the advanced parameter is 0.0.0.0).

(15)

ACE3600 I/Os

For example, in a system with thirteen frames, the IP address range might be 10.100.100.100 (main CPU) to 10.100.100.113, or 0.0.0.0 to 0.0.0.13.

Time & Sequencing Synchronization of I/O Expansion

In a system with I/O expansion, the expansion modules automatically update the time from the main CPU. This date and time information is used for event timestamps, etc. Each expansion module is synchronized to the main CPU’s time while taking into consideration the different time drifts which are typical of the main CPU and of each individual expansion module. Any change in main CPU’s date and time is immediately transferred to the expansion modules. In addition, the Time & Sequencing mechanization ensures that the event timestamps are sequenced in chronological order.

When the main CPU synchronizes the expansion module, an extended time synchronization frame is created in the main CPU (master) to be dispatched to the (slave) expansion modules in the system.

The sequencing mechanism ensures that time tags and timer events are sequenced properly in chronological order.

An advanced parameter ‘Main to expansion frame TX delay Time’ determines the number of microseconds that represent the time synchronization packet delay on its transit from the main CPU to the expansion frames.

Please note that the time synchronization packet delay is also affected by the number of Ethernet switches on the route between the main CPU and the expansion frame. The synchronization mechanism described above is the default and the recommended one. Alternatively, the expansion module can use the main CPU as an NTP server for time synchronization. To do so, the following parameter must be set:

 The ‘Expansion module sets main frame CPU as NTP server’ parameter (Advanced ->

I/O Expansion Manager) should be set to Enable.

If the user uses the main CPU as an NTP server for time synchronization, the sequencing mechanism is still performed by the main CPU and the time is synchronized via NTP.

(16)

Automatic I/O Recognition

The site configuration of an ACE3600 RTU includes the definition of all I/O modules in the unit. In legacy MOSCAD systems, the user manually defined each module in each RTU using the Site Configuration tool and then linked the physical I/Os to the definitions in the single- and multiple-column tables using the Application Programmer tool.

With the Automatic Recognition feature, the ACE3600 RTU identifies the actual hardware (I/O modules only) components in the unit when starting up and builds the initial site configuration accordingly. This site configuration is based on the default site settings and the unique module type ID number associated with each I/O module.

The Automatic Recognition feature saves time for the system definer who merely sets the ‘Enable auto I/O modules recognition at startup’ field (disabled by default) in the STS and powers on the RTU. Once the initial I/O module configuration is determined, the site configuration is uploaded using the Upload New Site command from the System menu. For more information, see the Uploading a New Site to the STS section of the ACE3600 STS User Guide. Further site configuration or advanced I/O configuration may be required. For more information, see the Customizing the Configuration of a Site section of the ACE3600 STS User Guide. Once all changes are made, the new site configuration can be downloaded to the unit. For more information, see the Downloading to a Site section of the ACE3600 STS User Guide. Note: In an RTU to which no site configuration has been downloaded, a default configuration exists, with Automatic Recognition enabled. When uploading from an RTU to which no site configuration has been downloaded, the Site Upload Form will list Default Site Configuration instead of Site Configuration. The configuration of the inserted I/O modules and plug-in ports PI1 and PI2 will be retrieved.

The RTU also identifies the module type automatically when an I/O module is inserted into a slot (hot-swap) in a powered-up RTU which is configured for Automatic Recognition. If an application is running, the application will ignore the newly inserted I/O module. When the RTU is restarted, the application will relate to all I/O modules. After restart, the site’s I/O configuration will also reflect the change in the I/O modules.

If a conflict arises between the I/O module configuration of an RTU associated with the application and the actual I/O module configuration (as recognized by the Automatic Recognition feature), an error will be sent to notify the user of incompatible definitions, and the application will relate only to those modules which have no conflict.

When Automatic Recognition is set in the site configuration, the user cannot define I/O modules. If the site configuration includes at least one I/O module, the user cannot enable Automatic Recognition. In each case, the STS prompts the user to choose one option or the other.

In systems with I/O expansion, Automatic Recognition can detect I/O modules in the main frame and in expansion frames. If the ETH1 port to which the expansion frames are connected is configured as “Not Used”, only I/O modules in the main frame will be detected. If the ETH1 port to which the expansion frames are connected is configured as Static LAN or I/O

Expansion Comm., I/O modules attached to the main frame and expansion frames will be detected. Expansion frames with no I/O modules can also be detected.

(17)

(18)

Power Management

The ACE Power Management feature enables ACE3600 RTUs which run on batteries to reduce the power consumption, and thus reduce the frequency of the RTU’s battery

maintenance. Power management is especially important for RTUs located in the field with limited access, or RTUs integrated in systems with low levels of activities (i.e. RTUs are frequently idle.)

Power management for an RTU is defined and implemented by the user using a ladder/‘C’ application program to control the power supplies in the system.

I/O modules and their power supplies are defined as new element types in the user tables. The current state of the I/O module or power supply can be retrieved using a Scan(). A power consuming element can be turned on/off as a result of an explicit user control.

IMPORTANT: It is the responsibility of the user when defining the application to operate the RTU in accordance with its power management requirements. For example, if the user tries to transmit data over a communication interface which has been powered off, the transmit will fail (as it would in the case of a disconnected cable.)

The following RTU components can be controlled using power management:

 I/O modules - Put an I/O module to sleep or wake up an I/O module according to the user application request; retrieve an I/O module’s sleep mode.

 Power Supplies on the main power supply module, on the I/O modules, and on the CPU board (i.e. belonging to the plug-in ports) - Turn power supplies on/off according to the user application request; retrieve power supplies’ current state.

 LEDs – Disable LEDs after a pre-defined timeout.

The following system database tables control the power management: CPU Power Supply [id:233], Main Power Supply 1 [id:234] and Main Power Supply 2 [id:235]. Also, DI and DO tables can control the power management of DIs and DOs, respectively.

For details on ‘C’ functions used in power management, see the ACE3600 “C” Toolkit manual.

Configuration

A number of power management: configuration parameters are defined in the STS site

configuration, including LEDs operating mode, timeout for switching the LEDs off, and size of the power manager’s message queue. For details, see Appendix A: Site Configuration

(19)

Power Management

Constraints

Activities on the power supplies have latency (either because they are done through SPI communication, or because it takes time for the power supplies’ hardware to stabilize.)

Therefore, a request to manipulate such a power supply is not immediately served. On the other hand, we don’t want the process to wait for a response to the user’s request. Therefore, such a request returns immediately and the user must check the hardware indications, (i.e. Get() the hardware’s actual state) and act accordingly.

User requests are mutually exclusive. While the power manager processes a user request, it disables rescheduling, preventing other requests from being simultaneously served.

(20)

Safe Firmware Download

A primary feature of the ACE3600 is the Safe Firmware Download. This feature ensures that remote download of firmware to an RTU will not cause the RTU to become unreachable. This feature is based on the concept that after new firmware is downloaded to an RTU and it is restarted, the RTU should be able to communicate with the PC host which downloaded the firmware. If it will not be able to communicate with the remote PC host, then RTU will roll back to its previous firmware. This protects the RTU from a situation where a flawed firmware image is downloaded and it becomes impossible to communicate with it remotely.

When an ACE3600 RTU is delivered from the factory, it contains the current firmware version (primary image) in the Flash memory. It also contains a minimal bootstrap image in the Flash memory, including the VxWorks operating system and a basic ACE application. The bootstrap image enables you to start up the unit and download new firmware (in the unlikely event that the unit cannot start up correctly with current loaded firmware, application and files.)

When the ACE3600 RTU is running, a new firmware version can be downloaded using the ACE3600 STS Download feature from a remote/local host over the MDLC or IP network. In the Download window, in the System File Settings, the ‘Evaluate request’ parameter (by default enabled) instructs the unit to evaluate the newly downloaded image before making it the primary image. Evaluation means the unit has received an evaluate request and then sends an echo to the host STS within a period of five minutes after the new firmware download. (The unit is rebooted 30 seconds after the end of the firmware download. The Evaluate request is transmitted from the STS to the unit approximately every 30 seconds up to the five minute limit).

If the downloaded firmware is evaluated and found to be problematic, the RTU will restart and roll back to the earlier, robust, burned image, and a message will be displayed on the

Downloader screen. If the downloaded firmware is found to be sound, it will be burned to the Flash memory and become the primary image.

It is recommended to always use the Safe Firmware Download.

A similar check exists for site configuration files, where the system checks every new site configuration that is downloaded. If there is a discrepancy between the I/O site configuration in the ladder application and in the RTU, an error will be logged and the system will revert to the previous configuration. See the Downloading to a Site section of the Operation chapter of the ACE3600 STS User Guide.

Note that firmware files are large and may take a long time to download at low communication speeds.

(21)

Flash File System

General

Information in the ACE300 RTU flash memory is organized and maintained as files in a flash file system (Motorola Flash File System-MFFS, which is a layer about Intel® FDI.) User flash files are created when the user configures/administers the ACE3600 RTU using one of the STS utilities. In general, the user will interact with these files via the STS GUI and the specific utility (e.g. Network Manager, Phonebook, etc.) For those user files in flash which require handling outside the STS, high-level file operations have been provided in the ACE3600 RTU ‘C’ Toolkit. These file operations handle file pointers and low-level read/write operations and were designed to save the user time and effort. For more information, see the ACE3600 RTU ‘C’ Toolkit User Guide.

Note: System flash files cannot be accessed by the ‘C’ application. Burned system software stored as a consecutive block instead of a flash file.

Associated with each user flash file type is a File ID, as shown in the table below.

File ID Description File ID Description

0 Ladder Application 33 X25 Address Table

1 Network Configuration 34 'C' Application Parameters without reset

2 PLC 1 35 Compressed Files

3 PLC 2 36 RDLAP Modem IDs Table

4 PLC 3 37 MAP27 Address Conversion Table

5 PLC To Master 1 38 NTP Configuration

6 PLC To Master 2 41 Feature File

7 PLC To Master 3 42 Modem Configuration PI1

8 Phone Book 43 Modem Configuration SI1

9 Sites Table 44 Modem Configuration SI2

10 'C' Application 45 Encryption File

11 Application Source 49 Modem Configuration PI2 13 TCP/IP Configuration 50 FPGA file for IO module 26 MOSCAD ACA Code 51 Predefined IO module values 27 MOSCAD ACA Data 53 Temporary Configuration File 29 'C' Application Parameters 56 Network Source File

30 Site Configuration 98 ACE Default Configuration 31 NetMon 'C' Application Parameters 100 Remote System File

(22)

Flash File System

File ID Description File ID Description

32 IP Conversion Table

In addition to user flash files, the user application can create log flash files (File ID #55) during runtime.

User Generated Flash Files

Most of the files created and used by the STS are stored in the flash memory in a format which is meaningful to the utility, and not to the user. The two files that are meaningful to the user and should be accessible to the user application are the ‘C’ Application Parameters with Reset files (File ID #29) and the ‘C’ Application Parameters without Reset files (File ID #34). These files are created by the user offline (not during runtime) and are the responsibility of the user. The File ID associated with ‘C’ application parameter files is determined by the choice of file type in the STS Add-Ons Manager, as shown in the figure below. The file name extension or suffix (e.g. .dat, .txt, etc.) is determined by the user. Most file types can have one instance in the flash at any one time. ‘C’ Application Parameters files (with and without reset) can have more than one instance (e.g. MyCfile.dat and MyCfile.txt).

Accessing Flash Files

The ACE3600 RTU ‘C’ Toolkit services enable the user application to access flash files by either file ID (e.g. 29) or by filename (e.g. MyCfile.29). Where one instance of a file exists, it can be accessed by file ID. Where more than one instance exists (e.g. MyCfile.dat and MyCfile.txt) it should be accessed by filename. The ‘C’ application can also retrieve the size of the flash file by filename.

(23)

Writing Flash Files

When the user downloads a file to the flash, all new data is saved as a temporary file (fileID.tmp). The new file is validated by the system to ensure data integrity. If validation succeeds, the temporary file is renamed (e.g. Myfile.<fileID>). If a file of that name already exists in the flash memory, it will be erased and replaced with the new file.

Therefore, files of a file type which can have multiple instances in the flash (i.e. ‘C’ data parameters) with different file name extensions (e.g. .dat, .txt, etc.) that are downloaded using the *.* extension, should be given different filenames; otherwise the second instance of the file will override the first instance which was just downloaded previously.

Note: There is no backup of old file versions.

In the event that a file download fails, the temporary file may remain in the flash memory, to be overwritten the next time a file of that type is downloaded.

To clean up extraneous files from the flash, use one of the Erase Flash options in the ACE3600 STS Downloader utility.

Note: It is not recommended to create very large user files (greater than 1MB). Instead use several smaller files.

Logging Flash Files

User logging flash files (e.g. database history files) are created and maintained by the user application. The file ID of user logging flash files is 55. The format of the files is determined by the user.

An advanced parameter which can be set in the STS site configuration determines the

Maximum size of Flash memory for user logging and the percentage of the flash to be used for logging flash files.

The ACE3600 RTU ‘C’ Toolkit provides a number of specialized functions for performing operations on user logging flash files, such as reading, writing, appending and removing logging flash files. Information such as whether the logging flash file exists, the status of the logging flash, the amount of free/used logging flash. For more information, see the ACE3600 RTU ‘C’ Toolkit User Guide.

Flash File Headers

All files in the flash memory include a 64 byte file header added automatically by the system while the file is burned to the flash. The header includes information such as CRC, file name, and the date and time the file was downloaded. When a flash file is read, the size of the file which is returned includes the size of the header. To calculate the size of the actual contents of a flash file (e.g. to copy the file contents to a buffer), you must subtract the size of the header. Logging flash file headers are added automatically by the system. The logging flash services provided by the ‘C’ Toolkit return the size of the file as well as the size of the file header.

(24)

Flash Files Diagnostics

Software diagnostics on the flash file system can be retrieved using the STS SW Diagnostics and Loggers, Device MFFS. Level 0 provides information on the actual files in the flash file system, and Level 3 provides information on the space available and in use in the flash file system.

If after downloading a ladder application to the RTU, the site configuration information stored in the RTU flash conflicts with that defined in the ladder application, the MFFS diagnostic will list both files (although the ladder database and rungs will not be used.)

Under certain circumstances files are listed in the MFFS diagnostics but not used during runtime due to integrity failures. For example: If the ladder was downloaded with the ‘Load Only’ ladder application setting and the number of differentiators used in the rungs is different than in the previously used ladder, then the new burned ladder will not be used.

Software diagnostics on the logging flash files can be retrieved using the SW Diagnostics, Device LOGFLAS. Level 0 provides information about the logging flash status (current and previous file and operations). Levels 1 and 2 provide information on the logging flash queue, and Level 3 provides information on the buffers in use.

The list of application files in use that were loaded from Flash memory to RAM memory can be retrieved using SW Diagnostics, Device FFILES Level 0.

(25)

Accessing Database Variables via

Coordinates

One of the most important features of the RTU is its database structure and concept (refer to Appendix C: Database Tables and Types in the ACE3600 STS User Guide.) The RTU database is divided into reserved and user-defined variables/constants, arranged according to various data types (such as discrete inputs/outputs, value inputs/outputs, timers, parameters, etc.) The application database is built as a set of tables, where each table defines a group of devices, each row defines a separate device and each column contains a specific device data. The table entries are assigned user-significant names, such as PUMP1.

Since database variables are assigned meaningful logical names, it is very easy to build, understand and modify the database.

Two functions, FETCH and STORE, are available for accessing database variables also via coordinates. Every database variable can be accessed by the following three coordinates:  Z coordinate (Z=0,1,...,126) is the user table number in the RTU database

 Y coordinate (Y=0,1,...,249) is the row number in the user table that appears under the index (Ind) column

 X coordinate (X=0,1,....,7) is the column number in the user table.

This way of accessing database variables may be useful for mapping the database of one RTU into another RTU using user protocols (which use coordinates to access database variables rather than logical names).

(26)

Accessing Database Variables via Coordinates

Definitions

Using the FETCH and STORE functions requires the definition of a single-column user table of integer value type, with the following variables.

Note that the order of the variables in the table is mandatory. The variable names shown in the table are recommended.

The first three values (Table#, Row# and Column#) represent the coordinates of the required variable in the database. They must be set by the user before calling the FETCH or STORE functions.

The FETCH/STORE call return code will be returned in the RetCod variable, as follows: 0 – OK

1 – spare

2 – invalid Z coordinate 3 – invalid Y coordinate 4 – invalid X coordinate

When calling the FETCH function, the required data will be put in Data0/ Data1 variables according to the data type (specified by the ColTyp variable), as follows:

 If the data is of Bit type (ColTyp=1), the data will be put in Data0 variable according to the following:

– If the data is 0, then Data0=0x0 – If the data is 1, then Data0=0xFFFF

 If the data is of Value type (ColTyp=2), the data will be put in Data0 variable.

 If the data is of Floating Point type (ColTyp=4), the data will be put in Data0 and Data1 variables.

(27)

Table#

 If the data is of Bit type (ColTyp=1), the data must be put in Data0 variable according to the following:

– If the data is 0, then Data0=0x0 – If the data is 1, then Data0=0xFFFF

 If the data is of Value type (ColTyp=2), the data must be put in Data0 variable.

 If the data is of Floating Point type (ColTyp=4), the data must be put in Data0 and Data1 variables.

For example, to store the value of fl1 (floating point variable) in the Z0,Y0,X0 coordinates, the following rungs should be used:

( MOVE ) Z0 Row# ( MOVE ) Y0 Colmn# ( MOVE ) X0 C P Y Data0 fl1 #4 Store ( CALL ) Table #

#4 is a constant defined in a Constants table. Its value is 4 (4 bytes*8=32 bits). Note: The FETCH and STORE functions are not supported for byte and long types.

(28)

Event Driven Software

Some applications, especially electrical ones and process control, have to deal with fast

changes caused by various events or follow these events with precise delay. The RTU provides you with the necessary database types and special functions in order to deal with such events. These functions allow you to get information on the change that has occurred (database coordinates, data, and time stamp) and activate a specific process accordingly, rather than polling the database. It also allows you to activate "fast" timers (shorter than Scan time) upon events.

This chapter describes the event-driven Change-Of-State (COS).

The time stamp can also be retrieved without waiting for an event to take place and stored in the Ladder Database.

Definitions

Data Type

The Event Driven concept is applicable only for Discrete Inputs of Time-Tagged DI (TgDI) data type.

This data type is similar to the DI data type (see Appendix C: Database Tables and Data Types in the ACE3600 STS User Guide.) Note that only the important inputs should be defined as Time-Tagged DI, since this feature is CPU-time and space consuming. By calling the Time function, a time stamp can also be retrieved and appended to an analog input called via the SCAN function from the Ladder. This need not be related to a specific event.

I/O Link

The specification of a Time-Tagged DI as Event-Driven is done during I/O Link (accessed from the Application Programmer). For details, refer to Application Programmer chapter of the ACE3600 STS User Guide.

During I/O linking, each Time-Tagged DI may be defined in the Event Type column as one of the following types:

(29)

 TIMETAG – for time-tagged COS. Changes are stored in a time tag logger with the time of occurrence in 1 msec resolution. For further details, refer to the ACE3600 STS User Guide.  EVENT – for event-driven COS, described in this chapter.

 TAG+EVENT – for time-tagged and event-driven COS. A combination of the above two types.

Event Driven Mechanism

When a COS occurs in one of the digital inputs defined as TgDI, the change is recorded in an event queue, including the rack (frame) number, module number, and input number.

When calling the GtEvnt function, the event is transferred to the Event-Driven database table (PRMEVENT table), while the rack (frame), module, and input numbers are translated into X,Y and Z coordinates, (where: X=column no., Y=row no., Z=table no.). Simultaneously, the corresponding table in the database is updated according to the change that has occurred. The event's time (date and time) is written to the TmMost and TmLeas columns in the PRMEVENT Table). These are two real type parameters, that represent the event's time as follows:

TmMost TmLeas

Day Month Year Hour Minute Second mili-seco

1 byte 1 byte 1 byte byte 1 byte 1 byte 2 bytes

1-31 1-12 0-99 0-23 0-59 0-59 0-999

Since the tables can hold up to eight columns, all the time's parameters (day, hour etc.) are arranged in two real type variables. In order to read specific information (e.g.: seconds), the user should perform LSL (Logic Shift Left) or LSR (Logic Shift Right) for the relevant variable, TmMost or TmLeas.

The number 0 in the YEAR byte (part of the TmMost) represents the year 1980, the number 1 represents the year 1981 etc. until the number 99 which represents the year 2079. (e.g.: 15 represents the year 1995).

(30)

The system can simultaneously handle up to 150 events and timers. If there are more than 150 events/timers, the EvOvfl flag of the Reserved Flags table (one of the System Tables), will be set to 1. In this case, it is recommended to clear the events queue (by calling the StEvnt function), and performing ordinary scan.

The system can set timers for up to 10 seconds. If no event is read during this period of time, the timer will be turned off, and the EvOvfl flag will be set to 1. It is the user's responsibility to reset this flag to 0.

For operations that require delay, the RTU provides the SetTmr function. The end of the timer is regarded as an event.

Note that in systems with I/O expansion a certain delay is involved from the time that an event occurs in an I/O expansion frame until it is available to the GtEvnt function. See the ‘Timer event main frame delay time’ parameter in the Timer Event section of Appendix A: Site Configuration Parameters.

Event Driven Tables

The Event Driven software includes one System Table, named PRMEVENT. When you open the PRMEVENT table, the following is displayed.

The PRMEVENT Table includes the following parameters:  ___Typ – defines the type of event, as follows:

0 - there is no event in the queue (all other parameters are meaningless). 1 - there is an event in the queue (see other parameters).

2 - the event is caused by a delay timer (set by the SetTmr function).

3 - The RTU's time was set by the STS (using the STS Date & Time utility or Sync command).

(31)

4 - The event is a power failure report.

5 - The existence of the time's parameters in the TmMost and TmLeas columns, is a result of calling the Time function.

 ___Tbl – the table number in the RTU database.  ___Row – the row number in the table (___Tbl).  ___Col – the column number in the table (___Tbl).  ___Bit – the current status of the input.

 ___Val – the value for the timer (in x10 msec).

 ___TmMost – a four byte real number. Represents the following: Day, Month, Year and Hour (1 byte each).

 ___TmLeas – a four byte real number. Represents the following: Minutes, Seconds and milliseconds.

The two columns at the right of the PRMEVENT Table, show the time and date (TmMost and

TmLeas), in a readable format. The user may read these parameters on-line, by activating the

Monitor mode in the Application Programmer.

How to Use the Event Driven Software

The RTU provides you with three functions in order to implement the Event Driven concept, as follows:

 GtEvnt – to retrieve an event from the event queue.  StEvnt – to perform various functions, as follows:

 0 – to clear the event queue (set value to 0).

 1 – to disable the event-driven mechanism (set value to 1).

 2 – to enable the event-driven mechanism (system default) (set value to 2).

 SetTmr – to start a timer after an event. The termination of the timer is also regarded as an event (this timer does not depend on the Scan time). The value of the timer should be set in the ___Val variable (in x10 msec).

(32)

Part of MAIN process

StEvnt ( CALL ) #2 GtEvnt ( CALL ) Procs1 ( JSP ) __Typ __Tbl = #0 #9 Procs2 ( JSP ) __Typ __Tbl = #0 #11 (1) (2) (3) (4) Procs3 ( JSP ) __Typ __Tbl = #0 #13 (5)

As part of the MAIN process, the above rungs check that an event has occurred, and fulfilling certain conditions, activate appropriate subprocesses. The above rungs are described below: Rung 1: The StEvnt function is called with a parameter of 2 to enable the Event Driven

mechanism. It is recommended to put this rung in the Init process.

Rung 2: The GtEvnt function is called; the system retrieves an event from the event queue into the PRMEVENT table, including the event type, table number, column number, row number, and data of COS.

Rungs 3-5: These rungs check the ___Typ variable and the affected table number; if ___Typ is not 0 (meaning that there is an event in the queue), the system jumps to perform a specific process according to the table number. For example, in rung 4 the system jumps to the Procs2 subprocess since the table number is 11.

(33)

Part of Procs2 subprocess

I ( MOVE ) __Row Send2C ( JSP ) __Typ Inp1, I / #1 (1) (2) Send2C ( JSP ) __Typ #2 (4) Inp2, I Inp1, I Inp2, I / __Val ( MOVE ) #30 __Typ Inp1, I #1 (3) Inp2, I Inp1, I Inp2, I / / SetTmr ( CALL ) ( RET ) (5)

Rung 1: This rung stores the row number (___Row) in the I index.

Rung 2: If it is an event (not caused by a timer; ___Typ=1), and Inp1,I is not equal to Inp2,I, then the system jumps to the Send2C subprocess to send specific bits to the central.

Rung 3: If it is an event (not caused by a timer; ___Typ=1), and Inp1,I is equal to Inp2,I, then the ___Val variable gets the value of 30 (thus, setting the timer to 300 msec), and the SetTmr function is called to activate the timer. Note that the parameters of the event are still kept in the PRMEVENT table.

Rung 4: If the event is caused by a timer (___Typ=2), the system jumps to the Send2C subprocess to send the current status of Inp1,I and Inp2,I to the central. Rung 5: Returns to the MAIN process.

In the MAIN process, you should add appropriate rungs to perform a loop, that checks if there are additional events in the queue.

(34)

Reading the TmMost and TmLeas Columns

The following rungs demonstrate how to read the time parameters from the PRMEVENT table. The time parameter columns in the PRMEVENT table has two variables with seven parameters each. When a specific parameter is required, the user should use the rotation functions LSL or LSR (see Appendix B: Ladder Diagram Language in the ACE3600 STS User Guide) as needed.

The following rung checks the analog value ANA1, and according to its value, activates the Time function. This option allows the user to get the occurrence time of an analog event.

Time ( CALL ) ANA1

500+

To obtain the date and time, decode TmMost and TmLeast, as follows (provided that TmMost and TmLeas are not zero and contain date/time information to be decoded):

Step 1. Define a set of user variables, as illustrated below. Variables 0 through 6 will get the date and time components; variables 8 through 11 are auxiliary variables:

Data type: Integer Value (int)

Ind Name Value

0 Myear 1 Mmonth 2 Mday 3 Mhour 4 Mmin 5 Msec 6 Mmsec 7 8 Mv1 9 Mv2 10 Lv1 11 Lv2

Mv1, Mv2 (for TmMost) and Lv1, Lv2 (for TmLeas) must be consecutive. Step 2. Define the following constants:

Data type: Int Constant

Ind Name Value

0 #4 4

3 #255 255

(35)

Step 3. Move the values as follows:

Mday ( MOVE ) Mv1 C P Y Mv1 TmMost #4 C P Y Lv1 TmLeas #4

Rung: r6

Mday ( LSR ) #8 A N D Mmonth Mv1 #255 MYear ( MOVE ) Mv2 MYear ( LSR ) #8 A N D Mhour Mv2 #255

Rung: r7

(36)

Accessing Database Variables via Coordinates Mmin ( MOVE ) Lv1 Mmin ( LSR ) #8 A N D Msec Lv1 #255 Mmsec ( MOVE ) Lv2 Rung: r8

(37)

Fast Events

In order to execute the control program defined in the user application, the RTU performs all functions written in the Ladder Diagram, one after the other. This is called a “scan”. After a certain period of time, the RTU repeats this procedure. The period between two scans is called “scan time.” During the scan, the RTU can respond to events or status changes in the devices in the field, represented by database variables and values.

When an application requires a faster response to events than the scan time permits, fast event, interrupt-driven triggers can be defined. Such a trigger activates a high priority fast process which can react quickly to the physical change.

Events Triggers

The elements which can trigger fast events are:  Digital Inputs

 Pushbutton PB2  Delay Timers

Note: Analog inputs cannot be used to trigger fast events. If the application includes analog inputs which require an immediate response, the user application itself should sample the analog values frequently and activate the immediate process if needed.

Fast Event Definition and Configuration

Using the ACE3600 STS, the user can define the number of triggers, the number of fast processes per trigger, and the size of the fast events queue.

The actual triggers and the high priority fast processes are defined using either the STS Application Programmer (ladder diagram) or the ACE ‘C’ Toolkit (‘C’ code).

IMPORTANT: Fast events should not be operated both from a ladder diagram and ‘C’ code. One event can trigger more than one fast process, and the same fast process can be activated by more than one trigger.

The application can choose to activate the fast process(es) after a certain delay.

DI filtering (sampling to ignore spikes) and AI filtering (averaging of successive readings to compensate for slight changes in analog readings) is generally defined in the advanced I/O parameters during site configuration. In addition, APIs in the C toolkit enable the user to change the filtering definitions during runtime.

(38)

Fast Events

Fast Event Scheduling

An application which is constantly involved in fast scans and triggers, or a fast process which is too time-consuming, may load the RTU to the point where it cannot function properly. The proper balance between fast events and other runtime tasks should be found to ensure that the system balance and scheduling are not impacted. In addition, the system keeps track of the execution times of the fast processes and will produce an alert if they are too time-consuming. The user is responsible for managing the fast events. If an error message is received that a fast event process is consuming too many system resources, the user should act accordingly. The system will not take any action other than reporting an error message.

Enabling/Disabling Fast Events

Triggers for fast events are enabled/disabled from ladder applications (using the TEN/TDS operators) and from ‘C’ applications (using the MOSCAD_fastevent_enable_trigger, MOSCAD_fastevent_disable_trigger services.) Proc Trig P1 T E N Proc Trig P1 T D S

where Proc is the process to be operated, Trig is the trigger (PB pressed, DI change of state, or delay), and P1 is the trigger value (i.e. PB2, DIx, # of delay seconds). See the application database Trigger States constants table for the list of trigger definitions.

Notes:

 When enabling a trigger from the ladder application (using the TEN operator), make sure to add a condition to the ladder rung.

 When enabling a pushbutton or DI trigger, the call to TEN should not be in a loop, because once the trigger has been enabled, it is meaningless to enable it again.  Generally, the ignition of a fast event trigger is preceded by the relevant logic in the

ladder. Ignition of a delay trigger does not necessarily include logic before triggering a process.

 If there is a jump from the fast process to another rung, the compiler will produce a warning, because this might lead to an infinite loop.

Proc1 FE_DI_COS DI,x T E N

enables process Proc1 after DIx goes to state DI-COS. Proc1 FE_PB_UP PushB2 T E N

enables process Proc1 after pushbutton PB2 is pressed.

ACE3600 STS Advanced Features

Advanced Features

ACE3600 System Tools

Suite (STS)

Version 15.50

6802979C15-J

AB

Table of Contents

Scope

ACE3600 I/Os

I/O Configuration

I/Os and the Application

I/Os Hot Swap

I/O Module States

Sleep Mode

Hardware Tests

Freeze Mode

Select Before Operate DOs

Site Configuration for SBO Relays

SBO DOs in User Ladder Applications

SBO Reserved Values

SBO DOs in User ‘C’ Applications

I/O Expansion

I/O Expansion Frames in the ACE3600 Database

I/O Expansion Configuration

Time & Sequencing Synchronization of I/O Expansion

Automatic I/O Recognition

Power Management

Configuration

Constraints

Safe Firmware Download

Flash File System

General

User Generated Flash Files

Accessing Flash Files

Writing Flash Files

Logging Flash Files

Flash File Headers

Flash Files Diagnostics

Accessing Database Variables via

Coordinates

Definitions

Event Driven Software

Definitions

Data Type

I/O Link

Event Driven Mechanism

Event Driven Tables

How to Use the Event Driven Software

Reading the TmMost and TmLeas Columns

Rung: r6

Rung: r7

Fast Events

Events Triggers

Fast Event Definition and Configuration

Fast Event Scheduling

Enabling/Disabling Fast Events