Some standard content:
National Standard of the People's Republic of China
Real-time FORTRAN for the control of industrial processes
Industrial real-time FORTRAN-Applicatlon for the control of industrial processes This standard is equivalent to the international standard ISO784685 for industrial process control-0 Subject content and scope of application 1
GB9362-88
Industrial real-time FORTRAN
This standard describes a task model and a set of related subroutines that enable the control of multitasking systems using FORTRAN as the programming language. This standard specifies external procedure references for industrial computer control systems. These external procedure references provide access to time and date information, provide interfaces between programs and execution systems and with process input and output functions, allow bit string processing, and provide methods for file processing.
These procedures are applicable to FORTRAN programs written in accordance with GB3057-182 "Programming language FORTRAN". These programs should be executable in a single program environment and in a multi-program environment under the control of a real-time execution system. It is the responsibility of the implementation system to handle exceptions and errors such as division by zero or reference to SQRT(-1.0) so that such errors do not have serious consequences, such as causing unexpected or uncontrolled abnormal terminations, or affecting other tasks. This standard applies to all FORTRAN systems that require multitasking features. Note that other content in this standard should not be expanded or changed when implemented, except for processor-related features explicitly pointed out in this standard. 1 Referenced standards
GB3057 Programming language FORTRAN
GB5271.10 Data processing vocabulary 10 Part 10 Operation techniques and equipment 2 Definitions
The following definitions apply to this standard
In the definition, the terms printed in bold are defined in this chapter, however, in each definition, the term is printed in bold only when it first appears.
2.1 Access mode
The right or permission to access (read or write) a file granted by the processor in response to a request for access permission. Basic clock counts
The count of the basic unit of the system real-time clock, which is applicable to user programs. 2.3 Computation
A set of operations performed on a set of data, which is applicable to user programs. Instructions for use,
1] Since this standard adds a chapter of referenced standards, in order to make this standard correspond to the main technical content of ISO 7846-85, the introduction and chapter 1 of ISO 7846-85 are merged into Chapters 0 to 1 of this standard. Approved by the Ministry of Electronics Industry of the People's Republic of China on April 20, 1988 and implemented on October 1, 1988
2.4 Critical region
GB 9362-8B
A part of a sequential operation that operates on shared data, so this part of the program must have exclusive access to the shared data during execution.
2.5 Potential DORMANT
A certain task state.
The execution system knows about the potential task, but it is not in the pending state, running state, or suspended state. 2.6 Event: event
A meaningful single thing or occurrence that is used to affect the execution of a task in a predictable way. The event itself occurs instantaneously and sets the event mark. 2.7 Event mark eventmark
An internal variable of the execution system used to indicate that an event has occurred. If the user's system contains parallel tasks, then the event mark is a shared data element for these tasks. 2.8 execution
the set of actions performed by a computer processor when instructions are executed in a sequential manner. 2.9 executable program a program in which all functions and subroutines are in a form suitable for execution. 2.10 executive routine the part of an executive system processor that supports the procedures described in this standard. 2.11 file
a collection of related records processed as a component. For the purposes of this specification, records are considered to be of fixed length. Record storage and access are independent of the internal format of the records. 2.12 initiation
the actions performed by the executive system to begin execution of a task at the first execution statement. 2.13 multiprocessing
a mode of operation that provides parallel processing by two or more processors in a multiprocessor. 2.14 multiprogramming a mode of operation that provides interleaved execution of two or more computer programs on a single processor. 2.15 mullitasking
A multiple operation that provides concurrent performance or interleaved execution of two or more tasks. 2.16 NON--EXISTENT
A defined (formal) task state. The execution system is unaware of the non-existent task. 2.17 objecttask; designated task, referenced task; a task that is requested or expected to be started, paused, or stopped: in other words, a task that is affected by a system subroutine call. 2.18 operation
A defined rule for generating one finite set of data from another finite set of data. 2.19 overrun
What happens when the condition of a task that starts becomes true while a task is still running due to a previous start. 2.20 concurrent tasks; concurrent taskse; a group of tasks whose operations can overlap in time. 2.21 PENDING
A defined task state.
The pending task has been linked to a hardware or time condition, so when the condition occurs: the task will be transferred to the running state and then started.
2.22ProcessorProcessor
GB 9362—88
A combination of a data processing system and a mechanism by which a program is transformed so that it can be used in the data processing system. 2.23Processordependentprocessordependent indicates processor actions that are not specified in this standard. 2.24repetitivecxcutianThe situation that occurs when a task is repeatedly started, whether at fixed intervals or due to repeated events. 2.25resoucemarkresoucemark
An internal variable of the execution system used to indicate resources reserved exclusively for a task. 2.26RUNNING
A certain task state.
A running task is executed in its virtual processor. 2.27 semaphore
variable of the execution system used to exchange synchronization information between interacting parallel tasks. All semaphore operations in this standard implicitly include critical section protection provided by the execution system. 2.28 sequential order of operations an order of operations that results in the same operation as if they were performed strictly one after the other. 2.29 SUSPENDED
a defined task state.
the task has temporarily suspended execution of its virtual processor and is waiting for a specified condition to resume execution of its virtual processor.
2.30 task
a computation that can be scheduled.
the operations of this computation are executed in a strictly sequential order. (See 2.17 and 2.28)
2.31 time
2.31.1 absolute time
absolute time
a complete time and date specification.
2.31.2 Relative time relative time time increment or difference.
virtual processor virtual processorot
The environment in which a task can run from the time it is first started to the time it ends, regardless of the availability of resources, which are managed by the processor and not by the user program.
A set of virtual processors can be mapped to a set of real processors using a specific implementation method. This mapping is processor-dependent.
Part 1 Multiprogramming and Real-time Characteristics 3 Introduction
This part describes several process references that can be used by user programs and involves multiprogramming, especially real-time operations. For all calls given in this part, the operations are generally considered to be inseparable, that is, these operations are as if they were not interrupted. 4 Date and time information
GB 9362—88
For programming in a real-time environment, the user must access the time variables of the execution system. These time variables can be obtained through the system calls described below.
Explicit time specifications require a unique time identifier, including the complete date and the universally recognized calendar, as well as the definition of time zero. Execution of a reference to the subroutine DATIM provides all the information. The date is referred to the Greenwich calendar. The calls are:
CALL DATIM(t1) is used to obtain the current date and time. CALLCLOCK(.1.R2) is used to obtain the master clock count. 4.1 Obtaining Date and Time
The call format is:
CALL DATIM(t1)
Where t1 is an integer array, the first 8 elements in the array will hold the absolute time, which is represented by the real-time clock time of the execution system when this call is executed. These elements are as follows: 1st element: master clock count;
2nd element: milliseconds (0 to 999) #
3rd element: seconds (0 to 59);
4th element: minutes (0 to 59) ||t t||The fifth element is the hour (0 to 23),
The sixth element is the day (1 to 31)
The seventh element is the month (1 to 12);
The eighth element is the year.
4.2 Obtaining the clock count
Executing a reference to this routine enables the user program to obtain the current value of the system real clock, which is expressed in master clock counts. The calling form is:
CALL CLOCK .kl.k2
Where: j is an integer variable or an integer array element, which stores the current value of the clock expressed as a positive integer. It is counted to the maximum value given by 2, then set to zero, and counted again. It is the master clock count value per second. It is an integer value sent back by the system. This independent variable should be an integer variable or an integer array kl
element.
2 is the maximum value that can be reached. It is an integer value sent back by the system. This independent variable should be an integer variable or an array element. The modulus size given by the independent variable 2 (modulus = 2 + 1). In practice, this is usually equal to the modulus of the hardware counter that implements the clock.
5 General case of task allocation
5.1 States and transitions
At any time, a task is in one and only one state. Actions performed by the execution system, other tasks, or the specified task itself can cause a task to transition from one state to another. These transitions are instantaneous, i.e., theoretically they take no time. The mathematical model of a task can be represented graphically using a "state diagram". In the following "state diagram", states are nodes, represented by circles, and transitions are represented by arrows from one node to another. A multitasking system consists of several parallel tasks and can be modeled using a number of disjoint but similar graphs. It is feasible to use three-dimensional graphs, where similar graphs are oriented on top of each other so that the same states of each graph are slightly different from each other. 936288
·State transitions are generally caused by routine calls, event occurrences, or timeout expiration. The names, forms, and interpretations of routine calls are standardized as described below.
In this standard, tasks are described by means of a mathematical model, which is illustrated by the state diagram in Figure 1. The model follows the following basic principles:
Transitions are unambiguous, i.e., given a stimulus in a given state, a task can only transition to one possible new state. Transitions are immediate, i.e., the time taken is zero. b
A task can only be in one state at a time. d.
From the application programmer's point of view, the state model describes the behavior of the task. SUSPEND
SIRTAT
CYCLAT
STRTAEIGYCLAF
CREATE
NOTEXISTS
In the state diagram, the following symbols are used for transitions: RESET
CANGET
STOP END
Figure 1 State model and transition diagram
Events, time
English letters in boxes: the effects imposed on a task by another task, that is, a routine call in a task will impose the effects specified in the box on the specified task. English letters not in boxes: the effects imposed on the task itself when it is in the running state. A Chinese character not in a circle: represents a certain condition, under which the execution system implements the specified state transition. Based on the above principle d, there is no attempt to describe the execution system actions that are transparent to the application programmer. Therefore, the running state is related to the virtual processor of the task (see Section 2.32). Regardless of whether the physical processor is assigned to the task or because the available physical processors are The fact that the execution system temporarily blocks the execution of a task due to a limited and low priority task is not essential to the state of the task. Therefore, this model is applicable not only to single-processor computers but also to multiprocessors. 5.2 Multiple Active Calls
Obviously, different tasks may issue conflicting transition calls to the same target task. This can occur both during normal operation and under error conditions, since the state of the target task is unknown when another task makes a transition call. Based on the principle that a task can be in only one state at a time (see 5.1), a distinction is made between a state transition and a call to make such a transition. Transition calls are received by the execution system, which then applies its own scheduling policy to handle them. Depending on the available resources, such as the execution system's internal table space, the transition call will be accepted or rejected. An argument is returned after the reference with the appropriate value set to indicate that the reference has been accepted or rejected normally. 5.3 Synchronization Concepts
GB9362—88
This standard provides three concepts for synchronization between tasks and for resolving resource contention: event tags: resource tags, and semaphores.
Event tags and semaphores are mainly used for synchronization, while resource tags are mainly used to resolve resource contention. Event tags, resource tags, and semaphores are all local variables of the execution system. These variables cannot be accessed except through the mechanisms described in this standard.
5.3.1 Event Tags
In concurrent task management, certain tasks must be associated with certain events. These events can be both external and internal events. External events are certain physical phenomena, such as contact closure, but the connection between external events and their event tags is beyond the scope of this standard. Internal events are generated by specific program actions (see the introduction to CALL POST in Section 6.9.1). The event flag is selected by referencing a numeric selector in the range 1 to n, where n is processor-dependent. The event flag has two states,
. The event is associated with a task through the subroutine calls CALL.SKED (see 6.4), CALLCON (see 6.5.8), CALLSUSPND (see 6.7) and CALL HOLD (see 6.8.1). When an internal or external event occurs, the event flag turns ON. If one or more tasks are associated with this event, the execution system will cause each associated task to start or continue execution. The event flag is turned OFF by direct program control or by the execution system when the execution system services the task associated with the event flag. Event flags can only be changed by reference to the program procedure defined in this standard or by the execution system servicing the event. The event marker can also be set to the OFF state by a special program action CALLCLEAR (see 6.9.2). The event marker can be shielded and the screen knock can be removed (see 6.9.4 and 6.9.5). In addition, the value of the event tag can be tested by the logic function TESTEM (see 6.9.3). 5.3.2 Resource Tags
The resource tag concept provides us with a simple way to resolve resource contention. At a time, one and only one task is allowed to use a resource.
The resource tag is selected by referencing a numeric selector in the range of 1 to n, where n is processor-dependent. The resource tag has two states:
LOCKED
UNLOCKED
This standard does not define what can be considered a resource. It is the user's responsibility to associate a resource with a resource tag. If the user requires that a resource be reserved for exclusive use by the running task, the resource tag of the resource should be selected and a CALLLOCK call (see 6.10.1) should be executed. Assuming that the resource tag is in the unlocked state at this time, in order to make the corresponding resource reserved for exclusive use by this task, the resource tag will be changed to the locked state. .This reservation is later released by the task by executing a reference to EXIT (see 6.12) or UNLOCK (see 6.10.2).
If a task attempts to lock a resource tag that is already locked by calling the LOCK subroutine, the execution system will transfer this task to the suspended state, where it will remain until another task unlocks the resource tag. If several tasks are waiting for the resource tag to be unlocked, the execution system will select only one of them to be executed (see 6.10.2 for details). This is the main difference from the concept of event tags. If the event tag is set to ON, all tasks waiting for the event tag are transferred to the running state.
A resource tag can also be set to the locked (LOCKED) state by calling the logic function TLOCK (see 6.10.3). 5.3.3 Semaphores
..comGB9362-88
Semaphores give another similar concept, which is very useful when you want to use a higher-level mechanism than resource tags and event tags. The semaphore is selected by referencing a numeric selector in the range of 1 to 1, where 1 is processor-dependent. Unlike event tags and resource tags, semaphores have an integer value s. The value s of the semaphore must be initialized and can be set later by calling CALLPRESEM (see 6.11.1).
If the task needs to wait until the value of the semaphore is greater than or equal to a certain pending value, the task should use the call CALLWAITS (see 6.11.2). By executing CALLWAITS, the execution system tests whether the specified decrement i is greater than:. In this case, the calling task is transferred to the suspended state, and the task remains in this state until the semaphore value 5 is increased to greater than or equal to 5 by another task. If not greater than:, then the value s is decremented by $, and the calling task continues to execute. By executing CALLSIGNAL (see Section 6.11.3), the execution system increments the value s of the specified semaphore. If $ becomes greater than or equal to the value of the pending task, then this increment causes the task waiting for this semaphore to transition from the pending state to the running state. If multiple tasks are waiting for this semaphore and they are all candidates for running, then the order in which these tasks transition to the running state after $ is incremented is processor-dependent.
By setting 5 to a certain value and choosing different values of j, various advanced synchronization concepts and various methods of resolving resource contention may be implemented.
In addition to the above calls, the integer function IRDSEM (see Section 6.11.4) can also be used to read the value of the semaphore. 6 Procedure references
6.1 Terminology and overview of procedure references
This chapter contains an overview of subroutine calls and function references described in subsequent chapters. The following parameter names apply to some of the subsequent calls. If the strict meaning of these parameter names deviates from the following description, they will be specifically marked in the detailed description of the call. If their meaning is completely the same as the following definition, the parameter description will be omitted in the description of the call, and it will be pointed out that this clause is referred to.
1 is the affected task (target task). This white variable should be an integer array. t, t1, t2 are integer arrays, and its first 8 elements contain absolute and relative time specifications. Negative values are not allowed for these elements. The meanings of these elements are as follows:
1st element: master clock count
2nd element: milliseconds,
3rd element: seconds;
4th element: minutes,
5th element: time;
6th element: day
7th element: month,
8th element: year.
For absolute time, if the value zero is used in one of the three date elements, the execution system will interpret it as "the current day", "the current month", or "the current year".
The interpretation of relative time specifications that include a non-zero month or year is processor-dependent. ㎡ is a parameter set when returning to the calling program, which indicates the handling of the request. The meanings of various values are as follows: 0 or less than 0: undefined 1
1. The request is accepted;
2 or greater than 2: The request is rejected (error condition). This argument It should be an integer power or an integer array element. The processor can define a specific value greater than or equal to 2 to distinguish various rejection reasons.
Table 1 is a list of function and subroutine calls, which will be described in detail in subsequent clauses. ..com Clause
.6.5.8
CALLCREATE(im)
GB9362—88
Table 1 List of function and subroutine calls
i+Identifier of the task to be created and the related program CALL KILL(m) (same as CREATE)
CALL SKED(1,$+el,t1+*2+e2,m) (general purpose)CALL STRT(i,m) (start immediately)
CALL STRTAF(i,t1,m (start after delay time)CALL STRTAT(i,1,m) (start according to absolute time)CALI. CYCI.(i,+2,m)
(execute the first restart immediately and then loop)CALL CYCLAF(i+1,2,m)
(initialize the first time after delay time, then loop)CALL CYCI.AT(1,t1,t2,m)
(initialize the first time according to the running time, then loop)CALL CON(i,e+m) (create event statement)CALL DSKED(2,s,e,m) (cancel the trick)CALL DCON( i,e,m )(cancel event connection)CALL CANCEL(i,m )(cancel time scheduling)CALI SUSPND( s+e,t+n,m )
(continue to suspend the calling task according to the time period, or suspend until an event occurs)
CALL HOLD(e,) (suspend until an event occurs)CALL DELAY(t,m) (hold the task until an event occurs)CALL POST(,m) (set event mark)
CALL CLEAR(e,m) (clear the event mark)TESTEM(e,m>(test the status of the event mark)CALL MKEM(e, set the screen of the event mark)CALLUNMIKEM(em) (clear the shield of the event mark)CALLLOCK(r,m) (lock the resource mark)8; mode selector
el: event mark reference
11 + the absolute or relative time t2 of the first initialization ,Time period of loop initialization
22, Overlapping operation event marker reference
1: Delay time before initialization
1; Absolute time of initialization
12 Time interval length
11; Delay time t2 before the first initialization; Time interval length
41:; Absolute time of the first initialization
t2; Time interval length
Event marker reference
"Mode selector
e:event tag reference
; event tag reference
5 mode selector
e delayed end event tag reference
time delay
1 end delay reason indicator
e: delayed end event tag reference
time delay
: event tag reference
e: event tag reference
e: event tag reference
function value, event tag status
; event tag reference
e, event tag reference
: resource tag reference
clause
6, 11,1
GB 9362—88
continued table 1
CALL UNLOCK(r,烘)(unlock the source tag)TLOCK(Tm)(test, and lock the resource tag)CALL PRESEM (r, s, m) (initialization of semaphore) CALLWAITS (r, m) (special semaphore)
CALLSIGNAL (r, j, m) (release semaphore) IRDSEM (m) (read semaphore value)
CALL EXIT (terminate execution)
6.2 Create a new task
: resource tag reference
1 resource tag reference
function value, resource tag status
factory: semaphore reference
: initial value of semaphore
next semaphore reference
main: decrement
r: semaphore reference
jt increment
semaphore reference bZxz.net
function value: semaphore variable value
Introduce the new task into the actual system by referencing the subroutine CREATE. The specified task will be associated with a pending program that is required for the execution of the task. This program is considered to be a resource like any other resource. The associated program is usually considered to exist in executable form. Formally, according to the state model, the effect of this reference is to transform the task from a non-existent state to a potential state (see Figure 1 and 5.1).
It is assumed that there is a mechanism outside the scope of this standard that creates and initializes at least the first task (the parent task), which in turn can create other tasks.
The call form is:
CALL CREATE(i,m)
is an integer array that contains all the information necessary to specify the task and the program associated with it. The latter includes (among other
items) the name of the program, where it can be found (e.g., the file description), where it resides if it exists (main memory resident or exchangeable), etc. This array may also contain the processor priority of the task. Typically, this array will also contain output information, i.e., references to distinguish this task from other tasks created by the same program code, references to various data sets, etc. This information can also be used by other procedure references in Chapter 6. For a description of parameter 1, see Section 6.1. All details of this array are processor-dependent. Same as described in Section 6.1.
6.3 Cancelling a Task from the Real-Time System
A reference to the subroutine KILL will cancel the specified task from the real-time system by converting the task to the non-existent state, immediately if the specified task is in the potential state or pending state. If the specified task is in the running or suspended state, the task can only be terminated by a future execution. Therefore, the specified task will continue its current execution without being interfered with by this call. The call is of the form:
CAEL KILL(i,m)
where t,m-
is as described in Section 6.1.
6.4 Scheduling Tasks
Executing a reference to subroutine SKED, or to a subroutine listed in clause 6.5, will schedule the initiation of the specified task, establishing the conditions for subsequently transitioning it to the Running state. If the specified task is in the Potential state when the call is executed, then the task is transitioned to the Pending state. If it is already in the Pending state, then the reference will add conditions to it, based on the arguments of the call, for subsequently transitioning it to the Running state, whereupon the specified task will transition to the Running state when any of the conditions that are still valid are true. The transition to the Running state requires that the task is in the Pending state, otherwise overlapping Running conditions may occur. Adding Running conditions is subject to any processor resource restrictions, and any violation of such restrictions results in an error return. When a task transitions to the Running state, the condition that caused the transition is removed from the possible set of combined conditions, while the other conditions remain. When the running task exits later, the task is changed from the running state to the potential state. Any scheduling conditions that may exist from the previous scheduling call will cause the task to immediately change to the pending state. (Note: The definition of the term "single stack running" and its representation are described below.) Each normal acceptance of the reference to the subroutine SKED will have the following effects. After the specified delay time expires or the desired absolute time is reached or the specified event occurs, the target task is converted to the running state and execution begins at the first executable statement of the program. The actual time resolution available in a particular industrial computer system is governed by the resolution of the system's real-time clock. If the target task is initialized by the occurrence of an event, the execution system will set the event flag to OFF as part of the initialization. If more than one task is waiting for the specified event flag to change to the ON state, then all of these tasks will change to the running state when this change occurs. The form of this procedure reference is,
CALL SKED(i,s,el,t1,t2,e2,m) where: im-
As shown in 6.1 As described in the clause.
is an integer expression, which specifies the following three task schedules: when the value of variable s is between 10 and 15, the task is started once; when the value of independent variable s is between 20 and 25, the task is started periodically on time; when the value of variable s is between 30 and 35, the task is started whenever the specified event mark is ON.
is the event mark of the schedule, which is an integer expression. el
is an integer array, which contains the absolute or relative time to be scheduled (the term relative time of the schedule refers to the time delay from the execution reference tl
time to the expected operation, see clause 6.1). is an integer array, which represents the time period of the loop operation (see clause 6.1). 2
is the re-entry run event mark. If overlapping operation occurs, it turns to ON. The action executed by the national standard task is related to the processor.
If the value of the independent variable s is between 10 and 15, it defines the first and only one execution of the task. If s = 10: Start immediately;
If s==11: Start at the absolute time red; If s=12: Start after delay 1;
If s=13. Start when event e1 occurs (once); If s=14: Start at absolute time 1 or when event e1 occurs (once): If 5 = 15; Start after delay or when event e1 occurs (once). If the value of the independent variable 5 is between 20 and 25, it defines the first execution of the task and the subsequent repeated execution according to the time period t2. If s = 20; Start immediately and loop according to 2; If 3 = 21; Start at t1 and loop according to t2 If s = 22 ; Start after delay, and repeat 1 by r2 If s= 23: Start when event e1 occurs, and repeat 1 by r2: If: =24: Start at t1 or when event e1 occurs, and repeat 1 by t2: If s=25: Start after delay 1 or when event e1 occurs, and repeat 1 by t. If the value of the independent variable s is between 30 and 35, it defines the first execution of the task, and the task is repeated every time the event flag specified by e1 becomes ON.
GB 9362--88
If s = 30: Start immediately, and repeat according to e1; if s = 31, start at t1, and repeat according to e1: if s = 32: start after delay t, and repeat according to el: if s = 33, start when event e1 occurs, and repeat according to e1: 1 If: = 34: start at 1 or when event e1 occurs, and repeat according to el: if nest 5 = 35: delay start after t1 or when event e1 occurs, and repeat according to el. 6.5 Start task by simple call
The following calls are used for scheduling, which is a subset of CALL SKED functions. They are just easier to program. CALL STRT (1, m),Start immediately
CALL STRTAF(ttl,m), start after delay; CAL1. STRTAT(i,t1,m), start at t1: CALL CYCI(i,12,㎡), start immediately, and loop according to 12; CAL CYCLAF(i,tl,t2,m), start after delay t1, and loop according to t2 CALL CYCLAT(1t1,t2,m), start at +1, and loop according to t2: CALL CON(i,el,m), start when event el occurs, and repeat according to el. 6.5.1 Start a task immediately
Executing a reference to the subroutine STRT will establish the conditions for the specified task to immediately transition to the running state through the pending state, and the task will start execution from the first executable statement. If the specified task is in the potential state when the reference is executed, the task will transition to the pending state and immediately continue to transition to the running state. The calling form is:
CALL STRT(t,m)
where i,m
as described in Section 6.1.
6.5.2 Starting a task after a specified time delay
Executing a reference to a subroutine STRTAF will establish a time delay as a condition for the specified task to change from the pending state to the running state.
After the reference is executed, when the specified time delay expires, the specified task is expected to be converted to the running state. If the task is in the pending state at this time, the state transition is performed. If the task is in the potential state when the reference is executed, the task will be converted to the pending state. In the running state, the task will start executing from the first executable statement. The calling form is:
CALLSTRTAF(i,l,m)
as described in Section 6.1.
where: 1, spell--
is an integer array, which represents the time delay for starting to execute the target task. 6.5.3 Start task execution at the specified absolute time Reference to the subroutine STRTAT will establish the absolute time as the condition for the specified task to be converted from the pending state to the running state.
When the specified absolute time is reached, the target task shall be converted to the running state. If the task is in the pending state at this time, this state transition will be made. If the task is in the potential state when the reference is executed, it will be converted to the pending state. When in the running state, the task will start execution from its first executable statement. If the specified absolute time has passed when the reference to STRTAT is executed, the task will be started immediately.
The calling form is:
CALL STRTAT(i,tl,m)
where; i,m-
as described in Section 6.1.
GB 9362—B8
1—is an integer array, which specifies the absolute time at which the target task will start execution. 6.5.4 Tasks that are executed repeatedly
Calls to CYCL, CYCLAF, CYCLAT, and CON are used for repeated execution and have the following common characteristics. If the current state of the task is the potential state or when the task becomes potential, the specified task will be transferred to the pending state. This reference then establishes the conditions for the specified task to subsequently change from the pending state to the running state for the first execution and future repeated executions.
A reference to a subroutine CYCL, CYCLAF, CYCLAT, or CON has the same immediate effect as a reference to a single execution, and in addition, after it ends (for example, by executing EXIT), the target task will immediately change from the potential state to the pending state for the next repeated execution, as indicated by "Repeat" in Figure 1. When a task is in the running state, the actual execution may be unintentionally delayed due to other programs running. For periodically repeated tasks, these delays will not be accumulated. If the execution is not completed before the time of the next execution, an overlapped execution situation will occur, and the actions to be taken by the repeated task are processor-dependent. The rescheduling under the specified conditions will continue until it is actively ended by calling the subroutine CANCEL (see 6.6.2) or DCON (see 6.6.1).
The above statement is also valid for CALL SKED (with parameters 3-20-25 and 30-35), however, the special parameter e2 of SKED is set to ON in the case of overlapping operation. 6.5,5 Immediate start
The calling form is:
CALL CYCL(i,t2,m)
As described in Section 6.1.
Where i,m
t2——is an integer array, which specifies the nominal length of the time interval (see Section 6.1). 6.5.6 The call for initial startup after a specified time delay is of the form:
CALL CYCIAF(i,tl,t2,m)
where i,m are as described in 6.1.
is an integer array specifying the time delay of the initial stimulus, the delay being measured from the time the call is executed (see 6.1). 2 is an integer array specifying the nominal length of the time interval (see 6.1). 6.5.7 The call for initial startup at a specified absolute time is of the form:
CALL CYCLAT(i,tI,t2,m)
where i,m are as described in 6.1.
is an integer array representing the absolute time at which the specified task is considered to have entered the running state. This argument is strictly equivalent to the parameter t1 of the call routine STRTAT (see 6.1). …—is an integer array that specifies the nominal length of the time interval (see 6.1). 6.5.8 Connection between tasks and events
Executing a reference to a routine (ON) will establish the specified event as a condition for transitioning from the pending state to the running state. If it is in the potential state or becomes potential when the reference is executed, the task is first changed to the pending state. Then, if the associated event flag is ON or becomes ON, the specified task will transition from the pending state to the running state and start executing from its first executable statement. The connection between the event and the specified task remains until it is actively cancelled by calling DSKED or DCON (see 6.6 and 6.6.1).
The calling form is:
CALL CON(i,e,m)
Where:,m
As described in 6.1.3 Start task execution at the specified absolute time. Reference to the subroutine STRTAT will establish the absolute time as the condition for the specified task to be converted from the pending state to the running state.
When the specified absolute time is reached, the target task should be converted to the running state. If the task is in the pending state at this time, this state conversion will be made. If the task is in the potential state when the reference is executed, it will be converted to the pending state. When in the running state, the task will start execution from its first executable statement. If the specified absolute time has passed when the reference to STRTAT is executed, the task will be started immediately.
The calling form is:
CALL STRTAT(i,tl,m)
where; i,m-
as described in Section 6.1.
GB 9362—B8
1—is an integer array, which specifies the absolute time, and the target task will start execution at this time. 6.5.4 Tasks that are executed repeatedly
Calls to CYCL, CYCLAF, CYCLAT, and CON are used for repeated execution and have the following common characteristics. If the current state of the task is the potential state or when the task becomes potential, the specified task will be transferred to the pending state. This reference then establishes the conditions for the specified task to subsequently change from the pending state to the running state for the first execution and future repeated executions.
A reference to a subroutine CYCL, CYCLAF, CYCLAT, or CON has the same immediate effect as a reference to a single execution, and in addition, after it ends (for example, by executing EXIT), the target task will immediately change from the potential state to the pending state for the next repeated execution, as indicated by "Repeat" in Figure 1. When a task is in the running state, the actual execution may be unintentionally delayed due to other programs running. For periodically repeated tasks, these delays will not be accumulated. If the execution is not completed before the time of the next execution, an overlapped execution situation will occur, and the actions to be taken by the repeated task are processor-dependent. The rescheduling under the specified conditions will continue until it is actively ended by calling the subroutine CANCEL (see 6.6.2) or DCON (see 6.6.1).
The above statement is also valid for CALL SKED (with parameters 3-20-25 and 30-35), however, the special parameter e2 of SKED is set to ON in the case of overlapping operation. 6.5,5 Immediate start
The calling form is:
CALL CYCL(i,t2,m)
As described in Section 6.1.
Where i,m
t2——is an integer array, which specifies the nominal length of the time interval (see Section 6.1). 6.5.6 The call for initial startup after a specified time delay is of the form:
CALL CYCIAF(i,tl,t2,m)
where i,m are as described in 6.1.
is an integer array specifying the time delay of the initial stimulus, the delay being measured from the time the call is executed (see 6.1). 2 is an integer array specifying the nominal length of the time interval (see 6.1). 6.5.7 The call for initial startup at a specified absolute time is of the form:
CALL CYCLAT(i,tI,t2,m)
where i,m are as described in 6.1.
is an integer array representing the absolute time at which the specified task is considered to have entered the running state. This argument is strictly equivalent to the parameter t1 of the call routine STRTAT (see 6.1). …—is an integer array that specifies the nominal length of the time interval (see 6.1). 6.5.8 Connection between tasks and events
Executing a reference to a routine (ON) will establish the specified event as a condition for transitioning from the pending state to the running state. If it is in the potential state or becomes potential when the reference is executed, the task is first changed to the pending state. Then, if the associated event flag is ON or becomes ON, the specified task will transition from the pending state to the running state and start executing from its first executable statement. The connection between the event and the specified task remains until it is actively cancelled by calling DSKED or DCON (see 6.6 and 6.6.1).
The calling form is:
CALL CON(i,e,m)
Where:,m
As described in 6.1.3 Start task execution at the specified absolute time. Reference to the subroutine STRTAT will establish the absolute time as the condition for the specified task to be converted from the pending state to the running state.
When the specified absolute time is reached, the target task should be converted to the running state. If the task is in the pending state at this time, this state conversion will be made. If the task is in the potential state when the reference is executed, it will be converted to the pending state. When in the running state, the task will start execution from its first executable statement. If the specified absolute time has passed when the reference to STRTAT is executed, the task will be started immediately.
The calling form is:
CALL STRTAT(i,tl,m)
where; i,m-
as described in Section 6.1.
GB 9362—B8
1—is an integer array, which specifies the absolute time, and the target task will start execution at this time. 6.5.4 Tasks that are executed repeatedly
Calls to CYCL, CYCLAF, CYCLAT, and CON are used for repeated execution and have the following common characteristics. If the current state of the task is the potential state or when the task becomes potential, the specified task will be transferred to the pending state. This reference then establishes the conditions for the specified task to subsequently change from the pending state to the running state for the first execution and future repeated executions.
A reference to a subroutine CYCL, CYCLAF, CYCLAT, or CON has the same immediate effect as a reference to a single execution, and in addition, after it ends (for example, by executing EXIT), the target task will immediately change from the potential state to the pending state for the next repeated execution, as indicated by "Repeat" in Figure 1. When a task is in the running state, the actual execution may be unintentionally delayed due to other programs running. For periodically repeated tasks, these delays will not be accumulated. If the execution is not completed before the time of the next execution, an overlapped execution situation will occur, and the actions to be taken by the repeated task are processor-dependent. The rescheduling under the specified conditions will continue until it is actively ended by calling the subroutine CANCEL (see 6.6.2) or DCON (see 6.6.1).
The above statement is also valid for CALL SKED (with parameters 3-20-25 and 30-35), however, the special parameter e2 of SKED is set to ON in the case of overlapping operation. 6.5,5 Immediate start
The calling form is:
CALL CYCL(i,t2,m)
As described in Section 6.1.
Where i,m
t2——is an integer array, which specifies the nominal length of the time interval (see Section 6.1). 6.5.6 The call for initial startup after a specified time delay is of the form:
CALL CYCIAF(i,tl,t2,m)
where i,m are as described in 6.1.
is an integer array specifying the time delay of the initial stimulus, the delay being measured from the time the call is executed (see 6.1). 2 is an integer array specifying the nominal length of the time interval (see 6.1). 6.5.7 The call for initial startup at a specified absolute time is of the form:
CALL CYCLAT(i,tI,t2,m)
where i,m are as described in 6.1.
is an integer array representing the absolute time at which the specified task is considered to have entered the running state. This argument is strictly equivalent to the parameter t1 of the call routine STRTAT (see 6.1). …—is an integer array that specifies the nominal length of the time interval (see 6.1). 6.5.8 Connection between tasks and events
Executing a reference to a routine (ON) will establish the specified event as a condition for transitioning from the pending state to the running state. If it is in the potential state or becomes potential when the reference is executed, the task is first changed to the pending state. Then, if the associated event flag is ON or becomes ON, the specified task will transition from the pending state to the running state and start executing from its first executable statement. The connection between the event and the specified task remains until it is actively cancelled by calling DSKED or DCON (see 6.6 and 6.6.1).
The calling form is:
CALL CON(i,e,m)
Where:,m
As described in 6.1.And it starts to execute from its first executable statement. The connection between the event and the specified task remains until it is actively cancelled by calling DSKED or DCON (see 6.6 and 6.6.1).
The calling form is:
CALL CON(i,e,m )
Where:,m
As described in 6.1.And it starts to execute from its first executable statement. The connection between the event and the specified task remains until it is actively cancelled by calling DSKED or DCON (see 6.6 and 6.6.1).
The calling form is:
CALL CON(i,e,m )
Where:,m
As described in 6.1.
Tip: This standard content only shows part of the intercepted content of the complete standard. If you need the complete standard, please go to the top to download the complete standard document for free.