Search This Blog


Join Our Site To Subscribe

Thursday, October 2, 2014

Cabling and adapter pinouts

Cabling and adapter pinouts

Under Channel 0 emulation, the configured serial port on the computer running the software acts like the Channel 0 port on a processor.
The following diagram shows the basic cabling for Channel 0 emulation. On PLC-5 processors, Channel 0 is a 25-pin female connector (requiring a 25-pin male connector on the cable). The cabling is basically straight-through, with a null modem on one end of the cable.

For serial devices and computers with 9-pin serial ports, use the Rockwell Software C13 or C13B adapters. The following diagrams show the pinouts for these adapters.

To connect to Channel 0 of a SLC 500 processor, use a null-modem (transmit and receive lines are swapped on one end) nine-pin to nine-pin serial cable, available at most electronics stores.

Tuesday, September 30, 2014

What are Debug files..??

Debug files are files used to simulate the actions of I/O in your system. RSLogix Emulate does not recognize I/O, and therefore does not emulate I/O operations. If you need to simulate actions of I/O to increase the accuracy of your emulation, you will need to program these files.

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. 

Related Posts Plugin for WordPress, Blogger...