Slc500 I/o Error Routine

[Guest andy]

Hi, I want to include a fault routine in a program that will detect a faulty I/O card in an SLC500 rack & then disable it to allow the program to carry on running , wich of the many I/O error codes should I use ? Thanks

[Guest]

Here are a few references to help get you started: Under the main menu selection for RSLogix500 Help - click Contents - and Find "xx52" Back in the RSLogix500 project tree - Under Processor Status - on the IO tab - press the Help button - take a look at "I/O Slot Enables" Also in the RSLogix500 project tree - Under Processor Status - on the Errors tab - press the Help button - take a look at "Fault Routine S:29" Also in the RSLogix500 project tree - Under Processor Status - on the Errors tab - press the Help button - take a look at "Major Error S:6" Also in the RSLogix500 project tree - Under Processor Status - on the Errors tab - press the Help button - take a look at "Major Error Halt S:1/13" If this isn't enough, post again and let us know what you've already tried. Good luck, Ron

[Ken Roach 194]

Gosh, can you do that without stopping the controller ? SLC's are generally extremely jealous about the stability of their backplane; that's why they Major Fault if an I/O card is missing. I've always thought that you couldn't reset a Major Fault and continue running, only User Faults (like overflows and so forth). I have some SLC's but I'm not willing to damage my controller or I/O modules to test this.

[Guest]

Yo, Ken, Yes, this can be done. Much of the confusion that most people have with this issue hinges upon the documentation's somewhat fuzzy definitions of "major faults" and "minor faults" and “user faults”. Added to this is more confusion about what constitutes a "recoverable error" or a "non-recoverable error". My personal (subject to mistakes) understanding is that we can fix a "recoverable error" within our ladder logic program - EVEN IF the error was caused by a "major fault". Done correctly, this can cause the processor to "reset" its own major fault and keep right on ticking. On the other hand, if we're dealing with a "non-recoverable error" then the processor will definitely shutdown and there's nothing that we can do to prevent that - no matter how clever we are with our ladder programming. I think what Andy is trying to accomplish is this: Suppose a program is running and is making use of an input module in Slot #2. The module "goes bad". In an SLC system, this would normally cause a fault and shut down the whole machine. But suppose that Andy has cleverly programmed a fault routine which will automatically cause the processor to skip the defective module in Slot #2 and keep right on running without shutting down the entire system. If your question is: "Can this be done?" - the short answer is "Yes, it can". But now for the disclaimer. When the module "went bad" how BAD did it go? If it went REALLY REALLY bad, then it might be shorting out the chassis back plane. If this happens, then the processor might not be able to communicate with any of the other modules plugged into the chassis. So the "automatic reset" that Andy is trying to achieve might not work in this particular situation. But then again, maybe Andy (or some other on-site technician) pulls the defective module out of the chassis and then cycles power to the processor. Then Andy's program would have an excellent chance of having the processor skip the "missing" module and keep on ticking along - using the rest of the modules in the chassis. Something else for Andy to think about: Is this particular module essential to the proper and safe operation of the system? In other words, are you painting yourself into a dangerous corner by telling the processor to simply ignore the fact that one of its modules is missing? Finally, I know you're not supposed to remove or insert a module in an SLC system with the power on. But I've done it many times without causing any damage to the system. Of course, I've always been playing with someone else's toys when I did this. So be careful out there kids - but one experiment is worth a thousand words. And that’s how I know that this can be done. I programmed - and I pulled - and the processor kept right on ticking along. Best regards, Ron