Specifications

RSLinx – Training Guide C - 13
scanned at all, either true or false, five times (e.g., I could find out if that subroutine were
being scanned).
Debug Files
Another special feature of the Emulator that functions to simulate I/O devices is the
concept of "Debug" files. Debug files are ladder programs that you include as part of your
application program. They are designated as debug program files which differentiates them
from the more standard program files in one significant aspect, they are not transferred to
the PLC processor during a download (and thus do not consume any actual PLC memory).
Developing and Using Debug Files
Operation of the Emulator does not necessarily require the use of debug files. Many means
of causing action are available, as mentioned earlier, such as writing to the data table, using
ladder logic such as recycling timers, or using an RSView32 HMI operator interface.
But debug files are a powerful tool for testing/troubleshooting your ladder logic programs.
Used to "respond" to your normal ladder logic, a debug file is modeled after machine
functions and is written in a familiar language - relay ladder logic.
As mentioned above, the primary difference between a normal ladder logic file and a debug
ladder file is that the debug file is NOT
transferred to the processor during a download.
Otherwise, Debug files are much the same; they are written in ladder logic, access the same
data table files and can "call" each other using the Jump to Subroutine (JSR) instructions.
While only one debug type file can be designated at any one time as the primary debug file,
you can develop a number of program files that could later function as this primary file.
The primary debug file is the one that will be used to actively simulate machine inputs.
Numerous Debug files (up to the limit of the number of PLC Program files) can be
programmed to permit you to develop the logic for a number of separate parts of the
application that you plan to test. Maintaining a number of separate debug files means that
you can switch rapidly between tests - there's no need to continuously modify a single file.
Multiple Debug files let you break-up the program such that smaller sections can be
executed and checked out. Each section operates independent of the surrounding software.
As an example, consider the situation where the "test" section contains inter-related math
instructions. In this case, complex chains of instructions can be broken-up such that the
intermediate results can be examined.
To completely separate one debug file from another (and from the rest of your normal
logic), take advantage of the option to create new data files as "local" to a particular Debug