SLC 5/04 Rack fault - How to Ignore?

Hello All,

I am trying to test some code inhouse with a I/O config set-up that is different than the one out on the field.

FIELD SETUP: SLC 5/04 - 10 Slot rack with I/O

Inhouse Set-up: SLC 5/04 - 5 Slot Rack & No I/O modules.

I keep getting Rack config fault (obviously) when i try to run the code on my test rig with I/O disabled. (Slot 0 to 20 disabled).

How do I get around this rack fault so I can run my logic on the CPU?????


Thanks

I have found the easiest way is to do it is with a global search and replace, for example replace I:6/* with say N52:2/*, I:7/* with N52:3/* and so on.
This will replace all of you I/O and allow you to test and simulate the rest of the code.

The search/replace option is the only option you've got for this circumstance. The program's rack size and the actual rack size must match for an SLC program to download. There's no way around that.

A good reason for most things.

While doing some protocol analysis and radio modem troubleshooting today, I learned that RSLogix 500 continually (about twice a second) sends two "Host ID" requests to the connected controller. The response to the first request is the controller type and model, and the response to the second request is the controller's application program name.

This is done to verify (very often !) that RSLogix 500 is still connected to the same controller whose offline program it is displaying.

This got me thinking about the A-B product designers' thought process when deciding that you couldn't load a program into an SLC that doesn't have the same size rack defined.

One of the worst things you can do in a factory setting is to use a network to load the wrong program into a controller. About the only thing worse would be to go into run mode and start turning on outputs.

I use RSEmulate 500 extensively to test logic, and I understand that it doesn't provide hardware communication interfaces, but one of the reasons it was built was to provide a product that could be used for emulation and testing without having to install the same size rack and I/O modules.

Thanks Mark & Ken,


Appreciate your help and feedback.


Thanks again.

For this reason, we have standardized on all I/O is mapped to a "working address" in a designated program file. This way it is only used once in the program, and can be easily disabled when placing code on our test bench.

Note, we also have a designated data table for the SCADA system. This keeps the data in a consolidated area thereby optimizing the IO server communications.

If your rack sizes match you can disable modules in your program that are not physically there to put the PLC in run without faulting, However the rack size must match which can be a headache if you have an expansion rack in your program.

Why not use Emulate?

When you mention disableing the modules, is that on the I/O tab and setting the slot enables to 0? That would be very cool.

Marc

Marc,
I think this is what they are talking about.
Edit. Picture didn't display.

Thanks Bob,

Thats where i figured it was, funny I never new that it was possible. I have always converted real I/O to data for program testing purposes. This will be huge for me. Thanks guys, learn something new every day, and sometimes what you learn is actually good!

Marc