Control/Compact Logix crash course

[shoelesscraig]

Nope, I'm not giving one, I'm hoping someone else will.

I have LOTS of experience with RSLogix 500 and the processors that go with it (SLC/MicroLogix). We have them all over the plant and I have gotten plenty of practice going out and setting up the communications I need to communicate with them.

But, not so with the Control/Compact Logix platform. I have been using RSLogix 5000 for a while now with the 2 ControlLogix processors that run our plant. But, I always access the program from the same computer that was set up by our automation "contractor" when they installed the system. I never have to figure out which file has the documentation, set up communications, etc. Since it is our main system and the plant cannot run without it, we NEVER touch the hardware at all, and rarely mess with the program except to make minor online changes. So, I have searched the forum and read lots on the AB website, but I still have some basic questions for the experts (you guys) if you don't mind.

1. Is the documentation for Control/Compact Logix processors still saved on the computer and not in the processor (the same as a SLC or ML)?

2. The motion instructions in Logix 5000...are these strictly for use with AB servos (Sercos, is that right)?

3. If I want to get ethernet on a SLC, I use a 5/05 or an ethernet adapter. On ML I use the 1100 or 1400. On a Control or Compact Logix, am I correct in understand that you have to insert a card such a ENBT into the chassis and assign the IP address that I wish it to have??

4. I know in a SLC setup, you only have 1 processor and in a ControlLogix (and CompactLogix as well i believe) you can have more than 1. Why would you want to do this, and can either processor control the output/input modules that are also in the chassis?

Sorry it was long, thanks in advance!

 

[rdrast]

1. Is the documentation for Control/Compact Logix processors still saved on the computer and not in the processor (the same as a SLC or ML)?

On the Logix 5000 platform, tag 'alias' names, tagnames themselves, and comments are stored on the processor. A raw, cold, upload will get any documentation entered.

2. The motion instructions in Logix 5000...are these strictly for use with AB servos (Sercos, is that right)?

Nope. Depending on the interface card, the motion instructions can use detailed information about specific AB drives and motors, but they aren't required to use AB Drives and Motors. I have some running very well (the M02AE's, I believe) with external encoder inputs, and analog outputs to older DC Drives.

3. If I want to get ethernet on a SLC, I use a 5/05 or an ethernet adapter. On ML I use the 1100 or 1400. On a Control or Compact Logix, am I correct in understand that you have to insert a card such a ENBT into the chassis and assign the IP address that I wish it to have??

Basically correct, yes. The -E models of Compactlogix CPU's have an Ethernet/IP interface built in. For the 1756 Series, you do need another card in the rack. Current Ethernet cards for 1756 are the ENBT, the EWEB, and the EN2T.
The BOOTP/DHCP utility from Rockwell can be used to assign an IP address, and it can usually be done directly from RSLinx through the who window.

4. I know in a SLC setup, you only have 1 processor and in a ControlLogix (and CompactLogix as well i believe) you can have more than 1. Why would you want to do this, and can either processor control the output/input modules that are also in the chassis?

With Logix, you can have a rack full of processors (not that that would accomplish much). Each processor in a rack can control specific I/O. If a processor is not controlling I/O, it can monitor it in "Listen Only" mode. They can also share information with each other over the backplane.
Why do it? Well, sometimes it is easier to split a task down to multiple processing units. Sometimes it's easier to have a large, but relatively self-contained program that you can pop on a CPU, drop into a rack, and make a small interface window of data to the main CPU, rather then modifying the program on the main CPU in a massive fashion.

Also, they might be doing totally unrelated things. Flexibility is key.

Note also, that no 1756 parts (except power supply) are location dependent. Any module, CPU, comms bridge, whatever can go into any slot.

If you are using Ethernet in a system, I strongly suggest putting it in Slot 0 of the CPU rack. If you aren't using Ethernet YET, but might, I suggest leaving Slot 0 free.

 

[dash]

As of the current version (V17) not all comments are stored in the processor. The only comments that are stored is in Structured Text (ST) and Function Block Diagrams (FBD). Comments in ladder and the tag descriptions (the actual tag names are in the processor) are not stored in the processor. There has been a long running rumor that this was going to be enabled by using a compact flash card for all text descriptions, but it hasn't happened yet. Maybe in the upcoming V18, who knows.

The MO2AE motion module rdrast refers to is an analog motion card, which you can use with any analog motion device that you can interface to. They also have slight variations of that depending on the feedback type and one for Hydraulics (although I have used any of them for hydraulics).

By the way rdrast, I have never heard that Ethernet cards should be in Slot 0. What is the reasoning behind that?

Thanks,

Darren

 

[rdrast]

By the way rdrast, I have never heard that Ethernet cards should be in Slot 0. What is the reasoning behind that?

Thanks,

Darren

Simplest of reasons... If you ever do any offline development and test, with RSEmulate, LinxEnterprise wants to emulate an Ethernet module in slot 0. By leaving 0 free for a real Ethernet module, you have no conflicts switching between RSEmulate and the real hardware.

 

[shoelesscraig]

Ok, so if I'm understand correctly, since we never use structured text or anything other than ladder, I still need to make sure I have the "documented" version of a program if I am going to really be able to understand it easy (assuming whoever wrote it labeled and described everything).

 

[OZEE]

But the tag names DO reside in the processor. And they can be MUCH larger than in the past. So -- if you intentionally, carefully select your tag names, you can make the program somewhat "self-documenting". For example, what used to be b3:0/1 might now be M21_Alarm