SLC 5/02 Programming

PeterKulka

Member
Join Date
Mar 2005
Location
San Francisco
Posts
18
Question for experienced programmers:

I'm trying to build test fixture for SLC500 modules. I will create very simple program (at least I think) to verify each input and output is operational.

My setup is (in cage from left to right):
1746-P3 ---- 24V DC Power supply
1747-L524 ---- CPU 5/02
1746-OW16 ---- 16 relays Outputs
1746-OX8 ---- 8 isolated relays Outputs
1746-OW16 ---- 16 relays Outputs
1746-IB16 ---- 16 DC Sinc Inputs
1747-SN ---- Remote I/O Scanner
1746-IV16 ---- 16 DC Source Inputs

Then I do have on Remote I/O loop this modules:
1791-8BR ---- 8 relays Outputs
1791-16BC ---- remote I/O 16 DC Inputs and 16 DC Outputs
1791-24BR ---- remote I/O 16DC Inputs,8DCand 8relays Outputs

My idea is that input #1 will activate output #1, than input#2 will activate output#2 on the same module. And so and so.
This apply to my remote I/O modules 1791-16BC and 1791-24BR.
My remote module 1791-8BR will be activated same way ( IN1-OUT1, IN2-OUT2 ...) by Input module 1746-IV16 located in main cage.
All others Input modules will activate one of Output modules in same fashion as remote modules.

What do you think about this idea?
Will work?
My most concern is if I will have enought memory.
Any other limitations apply?
Thanks in advance.
 
MrQ said:
Why do you want to do this?

Troubleshooting?

For fun?

Is not for fun.
We are using these modules and some and a lot of them are in our shelf and nobody knows about their condition.
All my colleagues just grab the module and without any tag putting them back to shelf.
For me is the worst nightmare, when I take any spare part trusting, that is OK and after several ours will find out, that I installed defective module.
My goal is to clean-up all ours inventory of modules and seal them in bags, which will insure everybody that module is sure OK.
If you call this as fun, yes it is, at least for me.
I see best opportunity to learn to program these SLCs.
 
It should work fine with the simple rungs that you'll be using; shouldn't run out of memory.

To save time though I would just put one input and one output module at a time but if you're trying to burn up time have fun!
 
jstolaruk said:
It should work fine with the simple rungs that you'll be using; shouldn't run out of memory.

To save time though I would just put one input and one output module at a time but if you're trying to burn up time have fun!

Thanks for your comment.
I never did any programming with PLC 500.
For me all of this is very new.
What is your reccomendation for test all of this modules?
Should I program just one IN and one OUT module (as you reccomending) and then create other program for other modules?
If so, then I will have to upload always new program depend on what module I'm testing. Is this correct?
I like to create program and burn it in to EEPROM (memory module M2). This will eliminate to use my laptop.
I like to build stand alone test bench.
Thanks in advance for your input.
 
Last edited:
Peterkulka,

I think that what he meant is that if you only inserted two of your modules 1 Input and 1 Output, then your program would only need to look at those two, and if either is bad, then you will have less trouble figuring out which one caused your SLC 5/02 to go into fault mode.

Your SLC has to be "configured" for the specific modules that you have installed, so if you write a program for each type of module to be tested, then you can plug in the first module, test it, then shutdown, plug in the next module of the same type, test it, and so on. Then when you have tested all of that type, you change programs and test the next type. Also you do not have to burn a program into EEPROM. It will be in the PLC memory until you replace it or until your internal memory power supply fails.

On the other hand, if you write 1 program using several types of different modules, then when you go to RUN mode, those modules have to be present, or you will get a PLC Fault and your program will stop running.
 
Lancie1 said:
Peterkulka,

I think that what he meant is that if you only inserted two of your modules 1 Input and 1 Output, then your program would only need to look at those two, and if either is bad, then you will have less trouble figuring out which one caused your SLC 5/02 to go into fault mode.

Your SLC has to be "configured" for the specific modules that you have installed, so if you write a program for each type of module to be tested, then you can plug in the first module, test it, then shutdown, plug in the next module of the same type, test it, and so on. Then when you have tested all of that type, you change programs and test the next type. Also you do not have to burn a program into EEPROM. It will be in the PLC memory until you replace it or until your internal memory power supply fails.

On the other hand, if you write 1 program using several types of different modules, then when you go to RUN mode, those modules have to be present, or you will get a PLC Fault and your program will stop running.
Thanks Lancie1 for explanation.

This is what I was worry about. If I will program all modules, than in RUN mode CPU will look for these modules and if any of them is faulty, I'm stuck.
Definitely is smart to program just one by one module and test them. Only down fall of this is, that I have always to download particular program for testing each module.
My desire is to build stand alone unit (no PC needed) for testing all of my modules.
Another option is to create number of programs, than burn each of them to individual EEPROMS. This will allow me to just change EEPROM and restart my CPU and bingo my SLC will run program for my particular module. Only (I think) battery has to be permanently disconnected.
What do you think about this idea?
 
Last edited:
Peter,

How about this approach?

Go ahead and set up your PLC test stand using one of each type of module (delete the second 1746-OW16). Populate your test stand with good modules (label them as part of the test stand). When you want to test a module, remove the "good" module and replace it with the one to be tested. You do tie up some inventory while testing, but that shouldn't be a problem.
 
Last edited:
Another option is to create number of programs, than burn each of them to individual EEPROMS. This will allow me to just change EEPROM and restart my CPU and bingo my SLC will run program for my particular module. Only (I think) battery has to be permanently disconnected.
What do you think about this idea?

Or maybe you can create subroutines for each module and choose between them. Maybe dedicate one input card with some togle switches and assign one for each card.

Also if you rich in hardware create two racks one with good modules and another one with the one to be tested.
 
Eugen

Eugen said:
Or maybe you can create subroutines for each module and choose between them. Maybe dedicate one input card with some togle switches and assign one for each card.

Can you tell me more about "create subroutines for each module"?
How it works and so.
Thanks
Please excuse me this questions, but I'm just learning SLC500.
 
Peter,

I don't understand how the "subroutines" method could work when you have a fault in a bad module. Even though the subroutine could select a test for certain modules, still when a bad module is plugged into the chasis, it can cause a fault and shut down the PLC, regardless of what the program is doing. This also applies to using toggle switches.

Your method of using EEPROM modules should work. You just have to figure out how to make the PLC load the new program from the new EEPROM each time. One way to do that is to set Status file bits S:1/10, S:1/11, and S:1/12 (or some combination of them). If S:1/11 is set, then the progarm will be loaded from the EEPROM each time the PLC is powered on (provided the password match). If this bit is set, then you do not have to disconnect the battery to get the EEPROM program loaded.

Mellis also had an idea that will work. Build a TEST unit and load it up with good modules, one of each type. Then when you need to test another one, turn off the power, remove the good one of that type, insert the suspected bad one, then power back up. With this method, you could also write some subroutines that performed other On/Off tests on each module, because you would always have the same types present.
 
Last edited:
After the PLC powers up and recognizes the card.(the assumption) You can run different tests read writes on every single input on all the card different speeds of switching etc. pair-ing it with a good input or output as the case may be. dedicating one slot for a certain product and triggering the right subroutine for the right card.

If it faults the processor should be self explanatory. :unsure: I think this will force you to check one card at a time.

There are probably hundred ways to do it.
 
It would be so much easier if you always had a laptop/PC available to connect to it so that when you do get a fault you could at least look in the status file to try and get some clue as to the fault condition. Otherewise, you'll only know that there was a problem but won't have a clue as to why.
 
Thanks LANCIE1, EUGEN and JSTOLARUK for your advice.
My ideology behind this test unit is that from my experience, over 90% of malfunctions happen in Input or Output circuitry.
These malfunctions do not halt processor in other controls. I do not know if this is the same situation with SLC500 modules. Please let me know if this theory applies to SLC500.
In this case I should be able to test this modules inputs and outputs with any problem. Of course, if my module will cause to halt processor, then I can plug in my laptop and test it out. But what I will test? At that time I will now that this module is causing processor to halt, what else can I read prom laptop attached to SLC500? I do not think too much. And anyway if main communication chip on the module fail, there is not replacement for it. It is custom chip made for AB and there is no way AB will sell it to me.
I target modules with damaged inputs or outputs circuitry.
As I wrote this is 90% scenario in malfunction of module.
 
Eugen said:
After the PLC powers up and recognizes the card.(the assumption) You can run different tests read writes on every single input on all the card different speeds of switching etc. pair-ing it with a good input or output as the case may be. dedicating one slot for a certain product and triggering the right subroutine for the right card.

Can you please give me more details about subroutine?
How to program, trigger and where is stored.

I like to avoid need to use laptop for testing.
 

Similar Topics

I am just finishing up my project, which was my first experience with PLCs. I thank everyone that has helped me work through the RIO and analog...
Replies
11
Views
2,956
Hello, I've taken on yet another basket case old machine running an 7 slot SLC 5/03 PLC.... I have run into a situation where I see the same 4...
Replies
3
Views
5,611
Hello guys. Got Slc5/04 with 9pin d shell port in it. Have cheked some manuals and this port is an RS 232. I want to ask if I could use a generic...
Replies
3
Views
2,336
i have a slc 5/02, but i'm not sure wich software to use (i have both rslogix 500 and 5000) but the main problem is that i dont have the cable, i...
Replies
12
Views
5,663
On site computer is using 1784-PKTX. The computer is connecting to 1785-KA5. I can program the SLC 5/03 with DH+.(1784-PKTX to 1785-KA5 to SLC...
Replies
1
Views
1,723
Back
Top Bottom