Overview
15
NX-Series Controllers - WebConsole & Programming Guide
The code in PRGM EX. 1 would be better implemented using a timeline, as illustrated in PRGM EX. 2:
DEFINE_CONSTANTS
LONG FEEDBACK_TIMES[1] = {500}
INTEGER FEEDBACK_TIMELINE = 1
DEFINE_START
TIMELINE_CREATE(FEEDBACK_TIMELINE, FEEDBACK_TIMES, 1, TIMELINE_RELATIVE, TIMELINE_REPEAT)
DEFINE_EVENT
TIMELINE_EVENT[FEEDBACK_TIMELINE]
{
[dvTP,1] = [dvDev,1]
[dvTP,2] = value1
[dvTP,3] = ![dvTP,3]
}
PRGM EX. 2
Using feedback statements in a timeline
The code in PRGM EX. 2 evaluates the feedback statements every half second regardless of other program activity. If a shorter
feedback refresh is needed, you can specify a smaller constant in the FEEDBACK_TIMES constant. Even a time of 100ms executes
far less frequently than a DEFINE_PROGRAM section stuck in an infinite execution loop due to a global variable change.
By moving all code out of the DEFINE_PROGRAM section, you ensure your NetLinx application is executing only when needed, and
therefore not expending unnecessary CPU cycles.
If you choose to continue to use the DEFINE_PROGRAM section, it is critical that you ensure that you are not modifying a variable
within the section. Any variable change will force a repeated execution of the section, thereby creating an infinite execution loop.
Variables should never fall on the left-hand side of an evaluation statement, as in PRGM EX. 3.
DEFINE_PROGRAM
Var1 = !Var1
PRGM EX. 3
Variable declared within the DEFINE_PROGRAM section
You must also take care to not inadvertently change a variable. For example, if a function is called within DEFINE_PROGRAM, then
that function must likewise not change a global variable. Additionally, accessing global “values” such as TIME and DATE constitute
a variable change. Take for example the code in PRGM EX. 4:
IF (TIME = ’22:00:00’)
{…}
PRGM EX. 4
Time check
At first glance, this code does not appear to change a variable. It is simply checking to see if the current time is equal to 22:00:00.
However, this code effectively changes the TIME variable by retrieving the current system time and assigning it to the TIME variable.
If this code were present in a DEFINE_PROGRAM section, it would infinitely re-execute the DEFINE_PROGRAM section. You should
place evaluations such as this in a TIMELINE_EVENT similar to the feedback timeline described earlier.
CPU Usage
The new NX masters provide several diagnostics that can be used to determine if your program is overloading the CPU and, if so,
what might be causing its excessive use. All of these commands are accessible through a Telnet or USB terminal connection with
the master.
>cpu usage
Gathering CPU usage over a 10 second period. Please wait ...
CPU usage = 2.10% over a 10 second period.
An idle application normally runs below 5% of the CPU. If your idle application shows more usage than this, then it is probable that
your application is experiencing excessive execution of the DEFINE_PROGRAM section.
You can use the following diagnostic to diagnose executions of the DEFINE_PROGRAM section:
>superuser 10
>enable interp stats
>show interp stats
-- Mainline Executions due to:
Variable Change : 0
Pending Int Event : 0
Pulse Expiration : 0
Hold Expiration : 0
DoPush Expiration : 0
Wait Expiration : 0
Until Expiration : 0
Timeline Expiration : 0
Periodic Mainline : 0
Current internal event count = 0
