PLC5 Differences

Ok Ron, this is a good for you (if you have time of course) to chime in on...Your specialty.

I'll make this short. I deal mostly with SLC PLCs at work. I am pretty used to doing a good bit of work with analog outputs and inputs, scaling them as necessary, etc. I am also familiar with how the data tables work in a SLC, showing me the individual cards in my rack an so forth.

I was informed that I may have to do some work on one of our older PLC5 systems in the near future. Looks like I'll be adding a flowmeter (4-20mA) and making some other modifications. I have heard that the data tables are much different in PLC5, especially when it comes to analog stuff. Can anyone give me a crash course on what I need to know and or watch out for?? Or, give me a good place to read. I've done some searching of my own, but with no luck. Thanks guys.

Rockwell has all these manuals on their web site. You are going to want to read a little bit.

Check out this great tool:
http://tinyurl.com/ygajepg

From http://www.ab.com there is a link right on the front page for "Literature Library"

From http://www.rockwellautomation.com there is a "Products" menu at the top that has a "Literature Library" link.

From the Literature Library expand "Programmable Controllers" and you'll see "PLC-5 System" were you'll see 62 manuals on the PLC-5.

You could also select "I/O" from the Literature Library and then "1771 Universal I/O" were there are 168 different publications.

Ok, enough on the "how to search". Actually the data files are nearly identical in the PLC-5. The SLC was based on the PLC-5 so they are real close. Here are a couple highlights though.

#1 Input/Output Data Files
==========================
Main difference here is that all possible I/O addresses are automatically created. The PLC-5 does not need/use/require the I/O Configuration like the SLC does. The I/O Config in the PLC-5 is primarily for documentation purposes although it can be very useful for the analog (read on!).

So, when you place an I/O module in the chassis it will access the I/O bits automatically assigned to that slot. Get that? The bits are assigned to the slot whether you place a module in there or not. This can possibly affect the order in which you place I/O modules. In some cases it can be necessary to place the modules an an I/O/I/O style pattern.


#2 Welcome to Octal
===================
The PLC-5 is a 16-bit controller, but it sits in an 8-bit chassis. So whenever you deal with an Input or Output address it will be in octal. So for example bits are numbered: 0,1,2,3,4,5,6,7,10,11....... This is only for the Input and Output files though. All other files accept decimal values just like the SLC500.

#3 I/O Addressing
=================
You will need to read up on this. You will need to know the difference between "rack" and "chassis". You'll need to know what an "I/O Group" is and understand how slot addressing affects the groups. Read up on 1-slot addressing in particular and how using 16-pt modules affect where you can install them versus say a 32-pt module.

Check out Chapter Four in particular of this PLC-5 manual:
http://literature.rockwellautomation.com/idc/groups/literature/documents/um/1785-um012_-en-p.pdf

#4 Analog Modules
=================
The Input and Output Data Files are strictly for your discrete I/O. You analog modules will instead be using Integer (N) files. Analog modules in the 1771 system do not get read automatically like they do in the SLC500. We basically have to use a communication instruction to grab data from a module and bring it back and store it in the integer file. Or grab data from a data file and send it out to the analog module. You are going to need to read up on the Block Transfer instructions. The BTR (Read) and the BTW (Write) are necessary to communicate with these analog modules.

The manual I pointed you to before goes over the concept of the BTR/BTW and you will want to read up on it, again look over all of Chapter 4. But this manual is the Instruction Set Reference Manual:

http://literature.rockwellautomation.com/idc/groups/literature/documents/rm/1785-rm001_-en-p.pdf

Read through Chapter 15 and in particular the examples near the end. They are very helpful!

Lastly, the RSLogix5 software as I mentioned does not require you to perform an I/O Configuration. But doing so for the analog modules is very helpful as the software can actually insert the necessary BTR/BTW logic for you.

So you have some reading to do!! Good luck and let us know if you run into any problems or other questions.

OG

adding a "transmitter" ? ... or adding a "module" ? ...

one loaded gun that you'll need to watch out for is described in this post:

http://www.plctalk.net/qanda/showthread.php?postid=15500#post15500

going further, my distinguished colleague Operaghost has mentioned all of the "big ticket" ideas ...

the good news is that if all you need to do is add a new channel to an ALREADY EXISTING module, then all of the Block Transfer communications are PROBABLY already set up and ready to go ... things will get a lot more challenging if you have to add a new analog module from scratch ... nothing we can't handle – but definitely more buttons to push ...

the best plan of attack is to post your existing RSP program file (if it's not proprietary or trade secret stuff) and let us take a look at it ... (you can email a copy directly to me if a public forum post is not to your liking) ...

suggested game plan: find an already installed transmitter that's easy to identify – and easy to track down ... trace that one out to see how it's being handled – then use the information that you've gained from that experience to help you install the next one ... (chances are you're not going to have to reinvent a wheel – just add a new wheel to some other wheels that are already installed and working) ...

and MOST IMPORTANT ... most of the analog input modules for the PLC-5 system have INTERNAL JUMPERS which much be properly configured for each input channel ... you need to double-check to make sure that the new channel that you'll be using is properly configured (voltage/current, etc.) for the new transmitter that you're going to connect ... if this is a 1771-IFE module then you really should OPEN THE MODULE and look inside at the jumpers to make sure ... (there are some "tricks of the trade" that might be helpful - but too much to type up right now - since we're not really sure what type of module you're going to be working with at this point) ...

tip: make SURE that you're using the correct book for the module ... the newer "series /C" is quite a bit different from the older "series /A and series /B" modules ... (hint: if it's a 1771-IFE module (very common) then the A and B series modules are usually covered in an appendix at the back of the manual for series C ...

finally (for now) if this channel will eventually be used for PID control, make sure that you leave the channel scaled as "raw" – which ranges from 0 to 4095 in the data table ... (again, I'm assuming that you're working with a 1771-IFE module) ... basic idea: the PID expects its input signal to be scaled in that range ...

hope this helps ...

Yes that helps, a lot. Thnaks guys, I will definitely do some reading. Also, the ControlLogix systems that run our plant have RIO cards in them and they go out to dozens and dozens of 1771 style racks throughout the plant (the same rack as PLC5 I believe). I have learned that they can be configured for "full rack" and "half rack" etc. I'm assuming this is what you were referring to Opera? Also, I have learned the hard way about the I/O cards being labeled in octal (0,1,2,3,4,5,6,7,10,11, etc), so I think that this is what you mean as well...?? Thanks again, I'll do my research. Ron, I'll get fired for posting the file or sending it to you, even though its not anything "top secret", there's just so much red tape with big companies, I'm sure you know what I mean.

Ron, I'll get fired for posting the file or sending it to you, even though its not anything "top secret", there's just so much red tape with big companies, I'm sure you know what I mean.

Click to expand...

absolutely – I understand EXACTLY what you mean ... that's why I always mention the "be careful" warnings when I offer to look at a program for someone ... so definitely keep yourself out of the doghouse – but obviously the more we KNOW the more we can HELP ...

and just a quick tip on the "rack" addressing ... the official definition of a "rack" is as follows:

a RACK contains 8 words of INput data – AND – 8 words of OUTput data ...

so – a total of 16 words (each word contains 16 bits) – and remember that 8 of those words are INputs and 8 of those words are OUTputs ...

so – a "rack" (in the context that you've been discussing it) is NOT (I repeat NOT) a physical "chassis" into which you plug the I/O cards, etc. ... instead a "rack" is a unit measure – something like an acre of land, a ton of steel, a gallon of water, etc., etc., ...

so – when you say that something has been set up as a "half rack" what you're actually saying is that the "something" device is going to occupy 4 words on your processor's input table – AND – 4 words on your processor's output table ...

one of the most confusing things about addressing to many technicians is the way that people (and books) blur the distinction between "rack" and "chassis" ... I hope this helps ...

Yes it definitely helps. I did not know that at all. I was, like the other people you mentioned, under the incorrect assumption that a "rack" was physical. Thank you for clearing that up. I can see how that lack of information could cause big headaches.