The CX-Supervisor Sleep function is designed to create a short pause in script execution. The parameter specifies the duration of the pause in milliseconds.
In this example 'statements B' will begin executing immediately when 'statements A' complete, though 'statements C' will not begin execution until 100ms after 'statements B' have completed.
Note 1: In a well designed, truly event driven system use of the Sleep() statement should never be required. Always consider if the statements after the Sleep should be in their own script, executed when a Condition occurs.
Note 2: The Granularity (or intervals) differs between Operating Systems. In Windows NT (and 2000) expiration is checked every 10ms, so 'Sleep(100)' actually pauses for 100 to 109.99 milliseconds depending on when it was started. For Windows 98 and ME the granularity is 55ms so 'Sleep(100)' actually pauses for 110 (2 times 55) to 164.99 milliseconds (nearly 3 times 55). For this reason, Sleep statements can act differently on different Operating Systems making the application OS dependant.
Note 3: Sleep should never be used as a delay for timing processes, for the following reasons:
Note 4: Because of Note 2 and Note 3 above, Sleep should not be used for creating output or logic pulses e.g. setting a bit on, sleeping, then setting the bit off. Instead, just use the PC to set the bit and allow the PLC to clear the bit, either after a duration timed by the PLC real time clock or when the triggered process is complete.
The requirement for Sleep is quite simple but the implementation is actually very complex. In the example above, the application must continue to run during the pause i.e. read PLC data, log data, check alarms, animate graphics etc. For this reason, any script with a Sleep statement must be executed in parallel with the system. This can result in unexpected results when a Sleep is added, and previously functioning script commands are now running in parallel. Redesign the script considering parallel processing.
This can also result in unexpected behaviour when a Sleep is added to a Project initialisation or Page initialisation script as some parts of the system or objects may not be loaded at time of execution.
Sleep can cause problems during shutdown of the runtime, if a sleeping script is still running.
For example:
<statements A>
<statements B>
Sleep(100)
<statements C>
In this example 'statements B' will begin executing immediately when 'statements A' complete, though 'statements C' will not begin execution until 100ms after 'statements B' have completed.
Note 1: In a well designed, truly event driven system use of the Sleep() statement should never be required. Always consider if the statements after the Sleep should be in their own script, executed when a Condition occurs.
Note 2: The Granularity (or intervals) differs between Operating Systems. In Windows NT (and 2000) expiration is checked every 10ms, so 'Sleep(100)' actually pauses for 100 to 109.99 milliseconds depending on when it was started. For Windows 98 and ME the granularity is 55ms so 'Sleep(100)' actually pauses for 110 (2 times 55) to 164.99 milliseconds (nearly 3 times 55). For this reason, Sleep statements can act differently on different Operating Systems making the application OS dependant.
Note 3: Sleep should never be used as a delay for timing processes, for the following reasons:
- The actual time delay depends on the OS
- There is always an error of 0 to 1 granularity, depending on when the action is started.
- The frequency cannot be guaranteed as the OS may be busy, or handling other processes.
Note 4: Because of Note 2 and Note 3 above, Sleep should not be used for creating output or logic pulses e.g. setting a bit on, sleeping, then setting the bit off. Instead, just use the PC to set the bit and allow the PLC to clear the bit, either after a duration timed by the PLC real time clock or when the triggered process is complete.
The requirement for Sleep is quite simple but the implementation is actually very complex. In the example above, the application must continue to run during the pause i.e. read PLC data, log data, check alarms, animate graphics etc. For this reason, any script with a Sleep statement must be executed in parallel with the system. This can result in unexpected results when a Sleep is added, and previously functioning script commands are now running in parallel. Redesign the script considering parallel processing.
This can also result in unexpected behaviour when a Sleep is added to a Project initialisation or Page initialisation script as some parts of the system or objects may not be loaded at time of execution.
Sleep can cause problems during shutdown of the runtime, if a sleeping script is still running.
