Help
  • Explore Community
  • Get Started
  • Ask the Community
  • How-To & Best Practices
  • Contact Support
Notifications
Login / Register
Community
Community
Notifications
close
  • Forums
  • Knowledge Center
  • Events & Webinars
  • Ideas
  • Blogs
Help
Help
  • Explore Community
  • Get Started
  • Ask the Community
  • How-To & Best Practices
  • Contact Support
Login / Register
Sustainability
Sustainability

Join our "Ask Me About" community webinar on May 20th at 9 AM CET and 5 PM CET to explore cybersecurity and monitoring for Data Center and edge IT. Learn about market trends, cutting-edge technologies, and best practices from industry experts.
Register and secure your Critical IT infrastructure

Logic Execution

Geo SCADA Knowledge Base

Access vast amounts of technical know-how and pro tips from our community of Geo SCADA experts.

cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Show  only  | Search instead for 
Did you mean: 
  • Home
  • Schneider Electric Community
  • Knowledge Center
  • Geo SCADA Knowledge Base
  • Logic Execution
Invite a Co-worker
Send a co-worker an invite to the portal.Just enter their email address and we'll connect them to register. After joining, they will belong to the same company.
You have entered an invalid email address. Please re-enter the email address.
This co-worker has already been invited to the Exchange portal. Please invite another co-worker.
Please enter email address
Send Invite Cancel
Invitation Sent
Your invitation was sent.Thanks for sharing Exchange with your co-worker.
Send New Invite Close
Top Labels
Top Labels
  • Alphabetical
  • database 32
  • Web Server and Client 31
  • WebX 19
  • Request Form 18
  • Lists, Events & Alarms 16
  • ViewX 15
  • Application Programming 12
  • Setup 12
  • Telemetry 8
  • Events & Alarms 7
  • Lists 7
  • Mimic Graphics 7
  • Downloads 6
  • Support 5
  • IoT 5
  • SCADA 5
  • Geo SCADA Expert 5
  • Drivers and Communications 4
  • Security 4
  • DNP 3 3
  • IEC 61131-3 Logic 3
  • Trends and Historian 2
  • Virtual ViewX 2
  • Geo Scada 1
  • ClearSCADA 1
  • Templates and Instances 1
  • Releases 1
  • Maps and GIS 1
  • Mobile 1
  • Architectures 1
  • Tools & Resources 1
  • Privacy Policy 1
  • OPC-UA 1
  • Previous
  • 1 of 4
  • Next
Latest Blog Posts
  • OPC UA - Driver and Server
  • Requirements for Generating a Valid OPC UA Server Certificate
  • Load Events Using LoadRecord and LoadRecords
  • Geo SCADA Embedded Component Licenses
  • Geo SCADA 2023 Known Issues
Related Products
product field
Schneider Electric
EcoStruxure™ Geo SCADA Expert

Invite a Colleague

Found this content useful? Share it with a Colleague!

Invite a Colleague Invite
Anonymous user
Not applicable
‎2021-06-09 07:12 PM
1 Like
0
1741
  • Bookmark
  • Subscribe
  • Email to a Friend
  • Printer Friendly Page
  • Report Inappropriate Content

Link copied. Please paste this link to share this article on your social media post.

‎2021-06-09 07:12 PM

Logic Execution

Originally published on Geo SCADA Knowledge Base by Anonymous user | June 10, 2021 04:12 AM

📖 Home  Back  

 

The logic engine is single threaded, this means that Geo SCADA can only run one logic program at a time. To protect logic programs from being affected by poorly written programs which cannot execute correctly, Geo SCADA includes an instruction limit. This instruction limit prevents programs with large or infinite loops from locking out other programs, refer to Maximum Number of Opcodes Executed for more information on this error.

A Logic Program Will Run...

 

  • At regular intervals (On Interval). The intervals are defined in the logic program's configuration.

 

  • At regular intervals but only if its inputs have changed (On Interval with Input Change Detection enabled) The intervals are defined in the Logic program's configuration.

 

  • At regular intervals only if the source of the trigger has changed value (the trigger is a value that is not used as an input in the logic program). The source of the value is defined in the trigger setting of the logic program's configuration.

 

  • At regular intervals only if the trigger has changed value or the logic program's inputs have changed.

 

  • When its inputs are processed (On Input Processed). Each point update is queued and the logic program will run once for each input update. The input updates are queued according to the time at which the server receives the updated values. See On Input Processed Execution for examples and further information.

 

  • When it is triggered by a change to a value in the database

 

  • When the Execute method is triggered by a user, master station schedule, script, automation interface, etc.

 

How to Stop Logic from Executing

The following applies to logic where the execution method is "On Interval".

On busy systems with large numbers of logic there can be a large amount of Overruns. This is caused when logic is being triggered faster than it can be executed. Some logic only needs to run under certain circumstances and most of the time the logic can be turned off, once it is required a script or other logic will turn it on and when the logic has finished performing its task it can be configured to turn itself off. This is not as easy to achieve as one would think.

Using the method DisableExecution will stop the logic program from executing, however it still loads the logic into the execution queue. With this setting, overruns still occur indicating that the logic is placed in the execution queue. The contents of the logic never execute while execution is disabled.

Using the InService property (set to false) will stop the logic program from executing, however it still loads the logic into the execution queue. With this setting, overruns still occur indicating that the logic is placed in the execution queue. The contents of the logic never execute while execution is disabled (or at least the outputs are never written). The frequency of the overruns increasing is less in this method than the DisableExecution method.

Using the InService property (set to false) and the ExecutionInterval property (set to 0) will stop the logic program from executing and stops the logic being loaded into the execution queue. Using this method will stop the logic overruns from increasing.

Example of turning off a Structured Text Logic Program:

VAR
InServiceProperty AT %M(.LogicObject.InService) : BOOL;
ExecutionIntervalProperty AT %M(.LogicObject.ExecutionInterval) : REAL;
END_VAR
ExecutionIntervalProperty := 0; (* Disable the logic *)
InServiceProperty := 0;

Order of Execution

When a logic program is scheduled to run it is added to an execution queue. If there are no other logic programs waiting in the queue the logic program will run immediately. However, if there are other logic programs in the queue or another logic program is already running at that time the logic program will not be executed immediately - it waits in the queue. When the running logic program has executed successfully, the next queued logic program in executed.

Essentially, there are a number of phases to the triggering and execution of a logic program, and every logic program is run sequentially. The important considerations are:

  • In each phase of the triggering and execution a Database Write Lock may be held, and long duration activities could affect the performance of the whole database server

 

  • Slow / long duration activities, even those occurring under just a Database Read Lock, will delay the execution of subsequent logic program(s)


A primary example of a 'long duration activity' is the execution of any SQL statement. The SQL activity could be an explicit SQL-initialised variable or could be implicit through the use of Linked-Tables (which are populated behind-the-scenes by ODBC access to another database, which can be very slow and unreliable). Any SQL query compared to a directly accessed variable such as %M, %I or %O is an order of magnitude slower but when used in a single logic program the effects of that SQL query may not be noticeable. However, if used in Templates as the database scales up the impact may become noticeable and as such SQL statements can be too slow to use in logic. When any query is used in logic it needs to be specifically reviewed to ensure the query is as optimal as possible. All queries should be enclosed in NOCACHE declarations otherwise additional performance issues may be observed.

Refer to the Linked Tables section below for additional information regarding queries and linked tables.

Giving proper consideration to what 'long duration activity' means requires an understanding the execution flow of a structured text program:

Triggered Execution
(Triggering / execute from a method or "On Input Processed" => Write Lock)

Gain write lock
Request to execute...
Read all ["cache"] input variables and queries. (Avoid using "cached" SQL-initialised variables)
Add execution request, along with cached inputs values, to the execution queue.
Release write lock.

[small delay]

Gain read lock
Read all [NOCACHE] input variables and queries (everything declared with NOCACHE; any SQL-initialised variables should be NOCACHE).
Release read lock

Execute

Gain write lock
Write all outputs
Execute all methods
Execute SQL commands
Release write lock

[small delay]

Issue SYSTEM commands.

Scheduled Execution
Gain read lock
Read all input variables and queries (both cached and non-cached).
Release read lock

Execute

Gain write lock
Write all outputs
Execute all methods
Execute SQL commands
Release write lock

[small delay]

Issue SYSTEM commands.


The [small delay] is because the request gets put on a request queue rather than it being in a sequence, so depending on the current queue size it could be a few milliseconds but could be longer.

If multiple programs are ready to execute, the execution will be interlaced to minimize lock transactions. I.e. two programs A and B are both triggered at the same time the inputs for both programs will be read under the same lock, and the outputs for both will also be written under the same lock:

Get read lock
Read inputs for program A
Read inputs for program B
Release lock

Execute A
Execute B

Get write lock
Write outputs for program A
Write outputs for program B
Release lock


Whilst this interlacing will increase overall system efficiency, it does mean that if program B is dependent upon the results of program A, you will have problems as program B executes before program A writes its outputs, not even the NOCACHE keyword will help.

Priority

Each logic program can be allocated a priority number (0 by default). If multiple logic programs are set to run at the same time, the priority numbers of the logic programs are used to determine the order in which the logic programs are run. Geo SCADA will run the Logic program with the lowest priority number first. The priority number is only used when multiple logic programs are set to run at the same time. At all other times, the logic programs are run according to the time at which they were added to the execution queue.

If there are Logic programs set to run at the same time and these programs also have the same priority numbers, Geo SCADA will run the logic programs according to the amount of time for which they have been queued. The logic program that has been queued the longest will be executed first.

Priority Example

There are three logic programs: ST Program 1, ST Program 2, and ST Program 3. ST Program 1 has a priority number of 3, ST Program 2 has a priority number of 5 and ST Program 3 has a priority number of 0. All of the ST programs are scheduled to run at 10:00.

A Function Block Diagram named 'FBD 6' has a priority number of 0 and is scheduled to run at 10:01.

At 10:00, Geo SCADA runs ST Program 3 as it has the lowest priority number (0). When ST Program 3 has run, Geo SCADA will run ST Program 1 as it has a Priority number of 3, and when ST Program 1 has run, Geo SCADA will run ST Program 2 as that has the highest Priority number (5).

ST Program 2 is not run until 10:02. The Function Block Diagram 'FBD 6' has not been executed, despite being scheduled to run at 10.01 and having a lower priority number than ST Program 2. This is because ST Program 2 was scheduled to run before 'FBD 6'. The priority number is only used if logic programs are scheduled to run at the same time.

Configuration Settings
  Execution Method   Trigger   On Input Change   Executed When
  On Input Processed   N/A   N/A   Whenever any of the inputs are processed, regardless of change. See On Input Processed Execution for more clarification.
  On Interval   No   No   On every Interval
  On Interval   Yes   Yes   On the Interval if the Trigger or any Input has changed since last execution
  On Interval   No   Yes   On the interval if any of the inputs have changed since last execution
  On Interval   Yes   No   On the interval if the trigger has changed since last execution

Change Detection

 

  • A change is detected if on interval a trigger/input has a different value to that at the last execution.

 

  • If an input/trigger changes but reverts to its original value between intervals the logic will not execute.

 

Linked Tables

Linked tables in Geo SCADA are a useful feature to provides an integrated environment for all your data. The Geo SCADA database may be linked to other Geo SCADA databases, Microsoft SQL Server, Oracle or any other third party database. The issue with linked tables however is that:

  • Typically the linked-table database is located remotely to the Geo SCADA database and so network issues, transient or permanent, such as congestion and TCP packet retries will affect the query's performance and as the query is done under a write lock the performance of the Main server in general

 

  • Connection to third party databases require third party components that are outside the control of Schneider Electric and their behaviour may not be as desired. We have seen some third party which do not respond to query requests from Geo SCADA and so the server deadlocks waiting forever for a reply; with applications such as Excel the lack of a responding query can be easily handled however in the Geo SCADA server it must wait for a reply from the third party components

As such it is not recommended to use linked-tables in logic given it executes at the core level in Geo SCADA. Linked tables in scripting and directly as a list in ViewX and WebX, whilst may still have performance issues due to the network or third party components, will not direct impact Geo SCADA's core functionality.

If data from a third party is required an application may be required to transfer data from that third party into a data table for use by logic, effectively providing a cache.

Go: Home Back

Author

Biography

Anonymous user

Link copied. Please paste this link to share this article on your social media post.

  • Back to Blog
  • Newer Article
  • Older Article
To The Top!

Forums

  • APC UPS Data Center Backup Solutions
  • EcoStruxure IT
  • EcoStruxure Geo SCADA Expert
  • Metering & Power Quality
  • Schneider Electric Wiser

Knowledge Center

Events & webinars

Ideas

Blogs

Get Started

  • Ask the Community
  • Community Guidelines
  • Community User Guide
  • How-To & Best Practice
  • Experts Leaderboard
  • Contact Support
Brand-Logo
Subscribing is a smart move!
You can subscribe to this board after you log in or create your free account.
Forum-Icon

Create your free account or log in to subscribe to the board - and gain access to more than 10,000+ support articles along with insights from experts and peers.

Register today for FREE

Register Now

Already have an account? Login

Terms & Conditions Privacy Notice Change your Cookie Settings © 2025 Schneider Electric

This is a heading

With achievable small steps, users progress and continually feel satisfaction in task accomplishment.

Usetiful Onboarding Checklist remembers the progress of every user, allowing them to take bite-sized journeys and continue where they left.

of