Consolidating systems on ControlLogix

We have a number of conveyor systems originally controlled by A-B PLC-2/30s which have since been converted to Softlogix5. There's been chit chat for some time about cutting the number of processors by combining two or three selected existing systems under the control of a single processor.

They're all already connected (and communicate with each other) via data highway so the plumbing, if not the cabling, is in place.

Each existing processor has rack 1, 2, 3, etc. and all the field wiring is numbered with the I/O addresses. So, in a combined system there will be duplicate addresses, like I010/13, O006/06, etc. The recurring question is this: How to keep these duplicates separate or somehow uniquely identify the original system each belonged to? The intent here is to avoid having to re-tag hundreds of I/O addresses on the racks and field wiring. Is there some kind of CLX tag magic which would allow this?

If push came to shove I guess even consolidating on the current Softlogix might be considered. If this route were taken I'd go with creating new I/O files for the systems being grafted in, something like I30:xxx/yy and I40:xxx/yy for original systems 3 and 4 respectively.

I've little idea how to proceed using CLX.

Any ideas?

Each existing controller can be a unique program in a combined SoftLogix/ControlLogix environment.
The tags would be program scoped meaning they can have the same name as tags in another program.

ie program called "Process 1" can have a tag called "tag_01" and a seperate program in the same controller called "Process 2" can also have a tag called "tag_01"

Regards Alan Case

Alan Case said:

The tags would be program scoped

Click to expand...

Alan, thanks for the reply.

I'm not that up on CLX but if tags can be program scoped it would follow that data files can also be program scoped. This is a consideration because there are barcode scanners in each program and each scanner has its own associated files and subroutines.

Could the subroutines also be put under their original programs and thus inherit the program-scoped features?

Apologies offered if I'm not making sense, I don't really know enough about the CLX platform yet to know the right questions.

No such thing really in CLX as data files. There is just a big memory area where you make tags. What you once used to assign to N7:0 for say the count of widgets made now becomes a tag called "Widgets_Made" of a data type Dint or Int.
These tags can be program scoped or global scoped, ie controller tags.
All IO has to be controller tags but if they are from diffferent racks then they will have a different names.
For example you can have 10 identical machines and each can have its own program in a CLX processor. The tags will be all program scoped except for the real world IO which will be mapped into program scoped tags.
There is a lot to know and Rockwell has a lot of good manuals on their website for getting started on CLX

If at all possible, spend the time during the conversion process to convert your non-I/O data elements to meaningful names and datatypes in ControlLogix.

I really dislike trying to interpret a ControlLogix program where all the tags have named like "B3[2]/0" instead of what they could have been, even just "SandPounder_A.SpoutPosition.0"

When I do bulk edits of tags in in PLC->Logix conversions, I export the project to *.L5K format and use UltraEdit do script my search/replace processes. UltraEdit is a terrific value if you save even a couple hours of brute force editing (and even a handful of typos).

The digital I/O tags can be the hardest part; all those wires and terminals out there in the field are numbered, usually with the memory address of the PLC (so they're Octal)

The last PLC-3 conversion I did, we went ahead and created a Boolean tag alias for every digital I/O point. The tag name identified the machine, the Rack number, the Slot number, and the Bit number: "SandPounderA_I03_04_12" was aliased to the 1771 I/O chassis point "SPA_R03:I.Data[4].14"

This contributed to a very large I/O database and searching was slower than we'd like. This was a system with twenty-seven 1771 I/O racks, all digital.

If I had it to do over again, I would write "Mapping" logic with COP or MVM instructions so that I could use a UDT for each I/O module with sub-elements that have octal bit numbers as element names. I think that means I'd have a lot fewer BOOL tags in the Controller Database.

Ken Roach said:

If at all possible, spend the time during the conversion process to convert your non-I/O data elements to meaningful names and datatypes in ControlLogix.

Click to expand...

I don't see a problem there, there's no deadline (yet).

Ken Roach said:

I really dislike trying to interpret a ControlLogix program where all the tags have named like "B3[2]/0" instead of what they could have been, even just "SandPounder_A.SpoutPosition.0"

Click to expand...

No problem there either since nearly everything has at least some description text and many already have symbol names.

Ken Roach said:

When I do bulk edits of tags in in PLC->Logix conversions, I export the project to *.L5K format and use UltraEdit do script my search/replace processes. UltraEdit is a terrific value if you save even a couple hours of brute force editing (and even a handful of typos).

The digital I/O tags can be the hardest part; all those wires and terminals out there in the field are numbered, usually with the memory address of the PLC (so they're Octal)

The last PLC-3 conversion I did, we went ahead and created a Boolean tag alias for every digital I/O point. The tag name identified the machine, the Rack number, the Slot number, and the Bit number: "SandPounderA_I03_04_12" was aliased to the 1771 I/O chassis point "SPA_R03:I.Data[4].14".

This contributed to a very large I/O database and searching was slower than we'd like. This was a system with twenty-seven 1771 I/O racks, all digital.

If I had it to do over again, I would write "Mapping" logic with COP or MVM instructions so that I could use a UDT for each I/O module with sub-elements that have octal bit numbers as element names. I think that means I'd have a lot fewer BOOL tags in the Controller Database.

Click to expand...

So, using that approach, module UDT names would be on the order of "PLC3_010", "PLC3_011", etc. and then the bits would be given their original symbol/description as a name?

What I'm getting from Alan and Ken is that this is definitely doable, there's just more than one way to do it.

Alan Case said:

There is a lot to know and Rockwell has a lot of good manuals on their website for getting started on CLX

Click to expand...

Brother, you said a mouthful there! Sounds like it's time to go to the Rockwell website and do some searching and printing .

On the subject of real I/O

Since there are multiple duplicate rack numbers, separate I/O scanners would be required, no? It would be nice to have just one scanner do it all but then the physical rack addresses would have to change and my thinking is this would not be a good thing. Or, is there a way around this too?

Also, a small thing I forgot. The original post indicated the controllers are connected by data highway - it's actually DH+. It used to data highway in the bad old PLC-2 days but there's a bridge now in the processor cabinet where the drop from the host comes in.