Multiple ControlLogix Controllers in the same Chassis

daba · Jan 23, 2017

ebolbol said:
Operaghost,

It took me a while, sheeesh... but I finally get it. It also makes complete sense. I have to see if I can fetch the other projects that contain the code for the other controllers. Thanks tons gents

If you can't "fetch the other projects that contain the code for the other controllers". then you can at least see the code and the tag databases, by performing an "upload" from the controller(s) into a new project(s) in your programming software.

For the L73 module it may be that the programmer selected to store the documentation in the controller as well (it's a new option from V21 upwards), otherwise you will just see plain undocumented code.

If you really want to get to the nitty-gritty of how the controllers are interacting, then in the tag-databases you can apply filters to the display to show only Produced or Consumed tags (unfortunately you can't do both at the same time). Look at the configuration of Consumed tags to see what data they are consuming, and from where. Mostly people use the same tag-names in both controllers as it helps when debugging, but it isn't necessary to do so.

Also look out for (search) MSG instructions. Any message that has a "Communications Path" of one of the other controllers name in the I/O tree is either reading from, or writing to, the other controller, depending on MSG configuration.

ebolbol · Jan 23, 2017

daba said:
If you can't "fetch the other projects that contain the code for the other controllers". then you can at least see the code and the tag databases, by performing an "upload" from the controller(s) into a new project(s) in your programming software.

For the L73 module it may be that the programmer selected to store the documentation in the controller as well (it's a new option from V21 upwards), otherwise you will just see plain undocumented code.

If you really want to get to the nitty-gritty of how the controllers are interacting, then in the tag-databases you can apply filters to the display to show only Produced or Consumed tags (unfortunately you can't do both at the same time). Look at the configuration of Consumed tags to see what data they are consuming, and from where. Mostly people use the same tag-names in both controllers as it helps when debugging, but it isn't necessary to do so.

Also look out for (search) MSG instructions. Any message that has a "Communications Path" of one of the other controllers name in the I/O tree is either reading from, or writing to, the other controller, depending on MSG configuration.

Thanks daba,

Yeah, having trouble locating the other projects. I have already found the Produced and Consumed tags. Will look for MSG’s tonight didn't even think of that. Now since the L73’s have on-board SD cards, shouldn’t I be able to find projects on each of the SD cards for their respective controllers?

daba · Jan 23, 2017

ebolbol said:
Thanks daba,

Yeah, having trouble locating the other projects. I have already found the Produced and Consumed tags. Will look for MSG’s tonight didn't even think of that. Now since the L73’s have on-board SD cards, shouldn’t I be able to find projects on each of the SD cards for their respective controllers?

Only if the SI put them there, it's not a requirement....

ASF · Jan 23, 2017

daba said:
Only if the SI put them there, it's not a requirement....

And also, they may or may not be up to date. My first move would be (as daba suggested earlier) to just straight-out upload from each processor. Hopefully you'll get lucky and the comments will have been stored in the PLC, and then you're away. If not, you'll at the very least have something to compare any SD card programs against to see if they're up to date.

ebolbol · Jan 24, 2017

ASF said:
And also, they may or may not be up to date. My first move would be (as daba suggested earlier) to just straight-out upload from each processor. Hopefully you'll get lucky and the comments will have been stored in the PLC, and then you're away. If not, you'll at the very least have something to compare any SD card programs against to see if they're up to date.

ASF,

Thank you! I will do exactly that. It's already very evident that they're using produced and consumed method to make the controllers talk. Any quick tricks on who's producing and who is consuming? Or is that like a shadow process similar to linked tags to HMI's where it's super hard to know if a tag is linked via topic config or not?

thingstodo · Jan 24, 2017

ebolbol said:
Any quick tricks on who's producing and who is consuming? Or is that like a shadow process similar to linked tags to HMI's where it's super hard to know if a tag is linked via topic config or not?

Monitoring the datatable in Controller Tags, tab Edit Tags, shows the produced and consumed ... at least, it used to. We don't use produced and consumed any more. If a processor gets switched to program mode, faults, etc there is no easy way (that I found at least) to determine that the source of your data is not up to date. I ended up doing message instructions between L73's so at least each PLC could tell if the other PLCs were online and executing code.

We had - in our 'OLD' control room - a 17 slot rack with 5 Cnet, 5 L63s, 2 Prosoft modules and 4 Enet cards. Produced and consumed made for fast communication on the backplane ... the RPI was 10 ms I think ... but we had a couple of floods before we determined that the product tags just remained at last state when a PLC faulted.

We are now up to 10 L73s and 2 L63s spread around the site. That 17 slot rack still has 4 L73s but we have a ... 5 year .. plan to distribute the processors to where most of their IO lives.

Something to watch for with multiple ControlLogix - you can have an 'owner' of the input or output card as well as more than one 'listen' controller. That avoids having messages between ControlLogix that only transfer IO. But if it is an IF16 that is 'listened' then you have to change the scaling in both ControlLogix. If you only change one, it is a race condition on which one powers up first so the analog card may not scale the changed channel properly, even though the ControlLogix that 'owns' the IF16 is correct. Just a bit of weirdness.

You can also have a 'rack-optimized' rack of IO that is owned by one ControlLogix but a single card, like an IF16, owned by another ControlLogix. Very confusing and we are working our way away from that as well.

daba · Jan 24, 2017

ebolbol said:
ASF,

Thank you! I will do exactly that. It's already very evident that they're using produced and consumed method to make the controllers talk. Any quick tricks on who's producing and who is consuming? Or is that like a shadow process similar to linked tags to HMI's where it's super hard to know if a tag is linked via topic config or not?

On the tag database "Monitor" view, apply a filter... there's a drop-down that lets you see only Produced, only Consumed, but not both at the same time.

daba · Jan 24, 2017

thingstodo said:
Monitoring the datatable in Controller Tags, tab Edit Tags, shows the produced and consumed ... at least, it used to. We don't use produced and consumed any more. If a processor gets switched to program mode, faults, etc there is no easy way (that I found at least) to determine that the source of your data is not up to date. I ended up doing message instructions between L73's so at least each PLC could tell if the other PLCs were online and executing code.

RED : Not any more, you have to use the "Show" filter.

MAG : Since version 17 I believe, you can produce your tag as a member of a UDT. As first member of the UDT, include a tag called Connection_Status (well anything you like really), of Data-Type CONNECTION_STATUS. There's 2 bits in that status tag, the first tells consumers that the Producing controller is in RUN mode, and the second is a "Connection Faulted" bit. If they are (respectively) ON and OFF, then that tells you the data is valid.

thingstodo · Jan 24, 2017

daba said:
MAG : Since version 17 I believe, you can produce your tag as a member of a UDT. As first member of the UDT, include a tag called Connection_Status (well anything you like really), of Data-Type CONNECTION_STATUS. There's 2 bits in that status tag, the first tells consumers that the Producing controller is in RUN mode, and the second is a "Connection Faulted" bit. If they are (respectively) ON and OFF, then that tells you the data is valid.

Thanks for the info. That's about the time I switched from produced/consumed to message instructions. I guess I should have investigated more thoroughly before switching ... but I'm not switching back now!

daba · Jan 24, 2017

thingstodo said:
... but I'm not switching back now!

I would, lol... I'm like that

ebolbol · Jan 27, 2017

thingstodo said:
Monitoring the datatable in Controller Tags, tab Edit Tags, shows the produced and consumed ... at least, it used to. We don't use produced and consumed any more. If a processor gets switched to program mode, faults, etc there is no easy way (that I found at least) to determine that the source of your data is not up to date. I ended up doing message instructions between L73's so at least each PLC could tell if the other PLCs were online and executing code.

We had - in our 'OLD' control room - a 17 slot rack with 5 Cnet, 5 L63s, 2 Prosoft modules and 4 Enet cards. Produced and consumed made for fast communication on the backplane ... the RPI was 10 ms I think ... but we had a couple of floods before we determined that the product tags just remained at last state when a PLC faulted.

We are now up to 10 L73s and 2 L63s spread around the site. That 17 slot rack still has 4 L73s but we have a ... 5 year .. plan to distribute the processors to where most of their IO lives.

Something to watch for with multiple ControlLogix - you can have an 'owner' of the input or output card as well as more than one 'listen' controller. That avoids having messages between ControlLogix that only transfer IO. But if it is an IF16 that is 'listened' then you have to change the scaling in both ControlLogix. If you only change one, it is a race condition on which one powers up first so the analog card may not scale the changed channel properly, even though the ControlLogix that 'owns' the IF16 is correct. Just a bit of weirdness.

You can also have a 'rack-optimized' rack of IO that is owned by one ControlLogix but a single card, like an IF16, owned by another ControlLogix. Very confusing and we are working our way away from that as well.

daba said:
RED : Not any more, you have to use the "Show" filter.

MAG : Since version 17 I believe, you can produce your tag as a member of a UDT. As first member of the UDT, include a tag called Connection_Status (well anything you like really), of Data-Type CONNECTION_STATUS. There's 2 bits in that status tag, the first tells consumers that the Producing controller is in RUN mode, and the second is a "Connection Faulted" bit. If they are (respectively) ON and OFF, then that tells you the data is valid.

Thanks to you both gents, all this could quickly drive a man to drinking heavily!

Usireland · Jan 30, 2017

Ebolbol clearly now understands about the 4 PLCs in one chassis but I still think this analogy might be useful to other people as its what made it clearer for me.

When you see multiple PLCs in one Chassis, don't think of it as a "Multi-core" CPU instead think of it as multiple individual desktop PCs connected together in a network. Just like in PCs connected together in a network all PLCs do not have access to all the "files" (Controller Tags) on all the PLCs, instead they only have access to what the other PLCs make available.

For anyone that hasn't had the "privilege" of doing a Multi-PLC project count yourself lucky! Certain things that you take for-granted in a single PLC project, such as Setting a flag in one part of the program and resetting it in another part, don't always work the same way in a Multi-PLC project (You cannot change the state of a consumed bit directly, you need to produce a bit to tell the other PLC to turn off that bit.).

If you can avoid putting multiple PLCs in a project, it greatly simplifies the code involved, but as in the case of the example ASF gave, sometimes its not always possible. Although with the new CompactLogix 5480 Controllers soon to be released and PLCs from other brands (Beckhoff, B&R etc) already available with Core i7 processors, Multi-PLC processes may become a thing of the past.

Ian

ebolbol · Jan 31, 2017

Usireland said:
Ebolbol clearly now understands about the 4 PLCs in one chassis but I still think this analogy might be useful to other people as its what made it clearer for me.

When you see multiple PLCs in one Chassis, don't think of it as a "Multi-core" CPU instead think of it as multiple individual desktop PCs connected together in a network. Just like in PCs connected together in a network all PLCs do not have access to all the "files" (Controller Tags) on all the PLCs, instead they only have access to what the other PLCs make available.

For anyone that hasn't had the "privilege" of doing a Multi-PLC project count yourself lucky! Certain things that you take for-granted in a single PLC project, such as Setting a flag in one part of the program and resetting it in another part, don't always work the same way in a Multi-PLC project (You cannot change the state of a consumed bit directly, you need to produce a bit to tell the other PLC to turn off that bit.).

If you can avoid putting multiple PLCs in a project, it greatly simplifies the code involved, but as in the case of the example ASF gave, sometimes its not always possible. Although with the new CompactLogix 5480 Controllers soon to be released and PLCs from other brands (Beckhoff, B&R etc) already available with Core i7 processors, Multi-PLC processes may become a thing of the past.

Ian

That actually is a great analogy! Clears things up even more.... I love this forum:site:

curlyandshemp · Jan 31, 2017

With multiple processors and communication cards in the same rack, you need to be careful of the power supply load, especially on the 5Vdc

Multiple ControlLogix Controllers in the same Chassis

daba

Lifetime Supporting Member

ebolbol

Member

daba

Lifetime Supporting Member

ASF

Lifetime Supporting Member

ebolbol

Member

thingstodo

Member

daba

Lifetime Supporting Member

daba

Lifetime Supporting Member

thingstodo

Member

daba

Lifetime Supporting Member

ebolbol

Member

Usireland

Member

ebolbol

Member

curlyandshemp

Lifetime Supporting Member

Similar Topics