Executing/Switching Modules

IWS is a SCADA system composed of modules that must be executed simultaneously. Based on the multi-tasking concept, each runtime module (Viewer, Driver, and so forth) is a thread and the operating system switches from one thread to other automatically. It is a common misconception that you execute a SCADA system when you execute a PLC program. A PLC program contains a simple loop:

Figure 1. PLC Program Loop

However, in a SCADA system, there are several modules running simultaneously, and most of them can read and write data. Because a SCADA system modifies data (tag values) continuously during task execution, the preceding diagram is not applicable.

IWS only has one process: Studio Manager.exe. When you execute a runtime project, the Studio Manager.exe process starts the Tags database and all of the runtime modules configured for the project. You can specify which modules (such as Viewer and Driver) will start during the runtime.

Each process keeps a list of active threads for the operating system. Actually, each process activates and deactivates each thread during the runtime, according to the algorithm of each process. Also, when you create a thread you specify a priority value. The operating system continuously scans all currently active threads, and executes the threads according to their priority value — executing the higher-priority threads first. When threads with higher-priority values are active, the threads with lower-priority values are not executed at all. If there is more than one thread with the same priority value, and there are no other threads with higher-priority values, the operating system keeps switching between the threads with the same priority.

Note: All IWS threads are set to priority 7, which is THREAD_PRIORITY_NORMAL. (Most programs contain this priority value.)

Real-time program (such as SoftPLCs and Device Drivers) threads are assigned a higher-priority value (THREAD_PRIORITY_HIGHEST); however, these programs must provide a mechanism to keep them inactive for some period of time or the threads with normal priority would never be executed.

IWS uses the UNICOMM.DLL library for serial drivers. This library creates a THREAD_PRIORITY_HIGHEST thread that "sleeps" (remains inactive) until data arrives in the serial channel. When IWS detects new data in the serial channel, the THREAD_PRIORITY_HIGHEST thread "wakes up" (becomes active) and transfers the data from the operating system buffer to the thread buffer, where it can be read by the Driver. This thread is the only highest-priority thread created by IWS.

If you allowed threads to remain active all the time, the CPU usage would be 100% all the time, which must be avoided for performance reasons. Every program provides a mechanism to prevent threads from staying active all the time.

IWS uses the following parameters to prevent threads from staying active continuously:

TimeSlice (from operating system): Causes the operating system to switch automatically between active threads with the same priority value.
By default, the operating system executes each active thread for approximately 20ms and then switches to the next active thread. In other words, if there are multiple active threads with the same priority value waiting to be executed, the operating system will not execute any one active thread for more than 20ms.
TimeSlice (from IWS): Specifies how long each IWS thread can remain continuously active.
You use this parameter in addition to the operating system's TimeSlice parameter. You configure a TimeSlice value for each IWS thread (except the Background Task) and specify how long each thread can remain continuously active. As long as a thread is active, the operating system can switch to that thread.
Period (from IWS): Specifies the maximum amount of time each IWS thread (except the Background Task) can remain inactive.

CAUTION:

We strongly recommend that you do not modify these default values unless it is absolutely necessary. Configuring these parameters incorrectly can cause the entire system to malfunction (for example, CPU usage will go to 100%) and/or cause some tasks to perform poorly.

If you must change the parameter defaults, note the values before making your changes so if a malfunction occurs you can return to the original settings.

To change the IWS TimeSlice and Period parameter default values:

From the IWS installation directory (for example, C:\Program Files\installation folder\Bin), double-click \BIN to open the folder.
Double-click the Program Settings.INI file to open the file in Microsoft® Notepad.
The following is a list of all parameters contained in this .ini file and their default values (in milliseconds).
```
[Period]
DBSpy=1000
UniDDEClient=200
UniDDE=200
Driver=20
LogWin=100
UniODBCRT=100
OPCClient=20
OPCServer=20
TCPClient=100
TCPServer=100
Viewer=50
   
[TimeSlice]
UniDDEClient=100
Driver=10
OPCClient=10
OPCServer=10
TCPClient=200
TCPServer=200
Viewer=200
```
Note: You may not see all of these parameters listed when you open your Program Settings.INI file. However, even if a parameter is not visible in your list, IWS still uses that parameter and its default value.
- To change the default value of a displayed parameter: In Notepad, delete the default value and type the new value in its place.
- To change the default value of a parameter that is not displayed in your list: In Notepad, type the parameter name exactly as shown in the following list, the equal sign, and then the new value.
Save the file (File > Save) and close Notepad (File > Exit).

The following figure illustrates how IWS executes a generic thread (such as the Viewer).

Figure 2. Executing a Generic Thread

Where:

Signal 1 is the Period time period (set to 50ms for this example).
Signal 2 shows when the thread is active for the operating system.
Signal 3 is the TimeSlice time period (set to 30ms for this example).
Signal 4 shows the execution of the thread itself.

In this example, IWS generates a Period message every 50ms (signal 1). When IWS generates this message, its thread becomes active and remains active until the specified TimeSlice time period (from IWS) expires. The thread then remains inactive until IWS generates the next Period message (signal 1).

While the thread is active, the operating system is responsible for executing that thread. However, just because a thread is active does not mean the operating system will execute it immediately — the operating system may be executing other threads, for example.

When the operating system executes the thread, the TimeSlice timer starts counting and the thread is executed for 20ms (TimeSlice from the operating system). After the 20ms period, the operating system automatically switches to the next active thread (such as the Driver), and so on.

In the above example, the TimeSlice time was set to 30ms, which means the operating system is not supposed to execute the thread more than once in each TimeSlice of IWS. However, if you specify higher values for the IWS TimeSlice time period, it is likely that the operating system will execute the same thread more than once in the same TimeSlice time period.

In the next example, the Period and the TimeSlice values were changed as follows, but the default operating system TimeSlice period (20 ms) was not changed.

Figure 3. Setting a Higher TimeSlice

Where:

Signal 1 is the Period time period (set to 100ms).
Signal 2 shows when the thread is active for the operating system.
Signal 3 is the IWS TimeSlice time period (set to 80ms).
Signal 4 shows the execution of the thread itself.

Notice that the thread can be executed more than once in the same TimeSlice time period. When the IWS TimeSlice time period expires, the operating system interrupts the thread execution; however, even though the IWS Period and TimeSlice parameters are set to 100ms and 80ms respectively, the operating system will not execute this thread continuously for more than 20ms, because the operating system TimeSlice time period is set to 20ms.

When the operating system is not executing the Viewer thread, the CPU can execute any other thread or remain idle (if there are no other active threads to execute). Remember, the IWS Period and TimeSlice parameters were created to prevent all threads from being active at the same time to prevent 100% CPU usage.

During thread execution, the thread must handle its pending messages. For example, the Viewer module must update any related screen objects. If there are no messages pending, the thread deactivates itself and gives control back to the operating system. The operating system immediately switches to the next active thread. In other words, a thread can interrupt its own execution — even if the operating system TimeSlice time period has not yet expired (which occurs frequently in real-world applications).

Note: The Database Spy, DDE Server, LogWin, and ODBC Runtime modules do not have a TimeSlice parameter. Consequently, after each thread handles all of its pending messages, the threads become inactive until the next Period message for each one of the threads occurs.

The Background Task is the exception to the execution/switching process just discussed. The mechanism for executing/switching the Background Task is described in the next section.