Search This Blog

_____________________________________________________________

Join Our Site To Subscribe

Monday, September 29, 2014

Debug file strategies

Debug files can be the most powerful tools in RSLogix Emulate. This section provides some strategies for using and manipulating debug files.
When to use debug files
Debug files are ladder logic. Your program uses ladder logic to control a process; a debug file uses ladder logic to simulate the process.
Anytime your program acts on a specific sequence of events (e.g., parts coming down an assembly line), you can simulate the process by programming ladder logic in a debug file. The following is an example.
Let's suppose you have a process that monitors a part's progress down an assembly line. There is a bit in your process that controls the conveyor motor. You have proximity switches that trigger operations when a part reaches specific areas of the assembly line. A debug file can easily simulate the part moving down the assembly line.



The first rung is conditioned on the start button for the process. The process starts, and TR1 starts timing. The preset should be approximately the time to get a part to the first station.
When TR1 is done timing, the PROX_1 proximity switch turns on. Since the proximity switch is on, the process at station 1 should activate.
By expanding on this concept, you could emulate the movement of a part down the entire assembly line.

Emulating block transfer reads

By using debug files, you can emulate the activity of Block Transfer Read (BTR) instructions.
BTR instructions take a specific number of words from an I/O module, and place those words in an area of the processor's data table. Since there is no real I/O while emulating a process, BTR instructions have no data to read.
To emulate a BTR, place a Sequencer Output (SQO) instruction in a debug file. Program the SQO so that the destination address of the SQO is the same as the BTR's Data File address. Enter the test data into the source words of the SQO. (You might want to enter a few values that are out of range for your process to test how the ladder logic program handles the erroneous data.)
When the SQO is executed by the emulator, it passes the data to the BTR's Data File. Your process can then use the data. You can execute the SQO automatically by triggering it off the done bit (.DN) of a free running timer in the same debug file.

Emulating many inputs

You can use the SQO instruction to emulate inputs. Program an SQO with a destination address in the input data table file. This way, you can send entire bit patterns to the input words instead of changing the individual bits.
Note Remember that the inputs will remain in their last states while emulating. If you want to reset your inputs, you will need to reset them manually. You could use an FFL instruction for this purpose.

Emulating fault routines

The status and fault bits in the processor are used by RSLogix Emulate. If you have a fault routine or shutdown sequence in your ladder program, you can test it by generating a fault or shutdown signal in a debug file.

Limit your debug files

If you try to program a single debug file to simulate the inputs for your entire process, you could end up with a debug file that is larger than your entire ladder logic program! Try to break down your process into pieces and create debug files to handle each piece. As you debug the pieces of your ladder program, you can combine your debug files to test a larger portion of your ladder program.

Uploading and downloading with debug files
With all of these debug files in your project, you may wonder what happens when you download to your processors. What happens to the debug files? The programming software filters out debug files -- they are not downloaded to your processors. That's both a good thing and a bad thing: it's good that the processor doesn't get filled with debug logic that could mess things up, but it's bad that your debug files aren't saved online. When you upload from a processor into a project that has debug files, the debug files get overwritten.
You will want to save debug files in a separate ladder logic project, or save the debug files as libraries to load back into your project. See the documentation for your ladder logic editing software for information on saving projects to different file names and using program libraries. 

Emulation

Emulation is simulation of operation -- in the case of RSLogix Emulate, the software emulates a programmable logic controller. 

Monday, September 5, 2011

Program tracepoints

Tracepoints are programmed with the Tracepoint output instruction (TPT). When the inputs on a rung containing a TPT instruction are true, the TPT instruction writes a trace entry to a trace display or log file. (To configure how traces are displayed or logged, see Configure trace displays.)
Programming the TPT instruction
The Tracepoint (TPT) instruction has two kinds of parameters:
This parameter:
Contains:
Requires:
Format
A string that sets the formatting for the trace reports (both on-screen and logged to disk).
Trace This:
The tag you want to trace.
An INT, BOOL, SINT, DINT, or REAL tag.
You cannot trace tag structures (for example, entire timers or counters). However, you can trace individual structure members.
You can trace a large number of tags with the TPT instruction, but the formatting string can contain only 82 characters. Because two characters are required in the formatting string for each tag you want to trace, the maximum number of tags you could trace with a single TPT instruction is 41. However, you will probably want to include spaces and other formatting to separate tag data in your traces, so the resulting number of tags that can be traced by one TPT instruction is significantly lower than 41.
Example:
The following rung triggers a trace of three analog values when any one of them exceeds a given value (30.01).

We want to display the tracepoint information in a particular format. That format is contained in the Format string (myformat). In this case, the format string contains the following text:
Analog inputs trace:Analog inputs = %f, %f, and %f
When the tracepoint triggers, the characters before the colon ("Analog inputs trace") appear in the title bar of the trace window. The other characters make up the traces. In this example, the "%f" characters represent the tags to be traced ("analogvalue1," "analogvalue2," and "analogvalue3"). Click here for more information about formatting strings.
The resulting traces appear as shown in the following illustration.



When this trace is logged to disk, the characters before the colon appear in the traces. This indicates which tracepoint caused which trace entry. The following is an example of a trace entry. "Analog inputs trace:" is the heading text from the tracepoint's format string.
Analog inputs trace:Analog inputs = 31.00201, 30.282000, and 30.110001
Related Posts Plugin for WordPress, Blogger...