Controllogix ADC Errors

Hello,

Thanks for taking the time to read this.

I have a rack with an L61 with firmware revision 20.55 and 3 ENBT cards. It's purpose was to be a slave to an old PLC5 with 1305 drives. One ENBT is supposed to be for a plant connection. The other 2 were intended for controlling 77 PF525s (40 on one and 37 on the other) installed when a 1305 fails using auto device configuration. I looked up the maximum number of CIP connections available for the controller and ENBTs and all should work.

I just installed the rack today (without any drives on the local networks)and started reading the drive information from the PLC5 but am getting a "No buffer memory" error on the MSG instruction. I tried reading from other PLCs of newer families on the plant network but get the same error.

I figured there must be too many drives in the tree of my program, but had to cut it all the way down to 10 from the error to go away. I'm figuring: Surely you aren't limited to 10 drives per controller even though it's an L61. We have CompactLogix L43s running 10 drives over ADC.

I'm figuring I'm missing something else. Any thoughts?

How many MSG instructions are you firing from the ControlLogix to the PLC-5 ? Are you sending one for each PowerFlex drive individually ?

How are you conditioning the messages; are they firing one at a time, or grouped to limit the number that are concurrently active ?

Are you also sending messages to the AC drives, or are they just in the I/O tree as scheduled connections ?

Post the exact error code. I'm curious about whether the error message is being generated at the buffer level in the ControlLogix, or if it's getting a rejection from the PLC-5 because of buffers on that end.

Thank you for responding Ken.

There's only one MSG instruction being fired. I condensed the words together into the same file in the PLC5 so I could read them all (166) at once. At being said, I've tried only reading 1 word with the same result. The MSG instruction is current on a delay timer of 1s.

The drives are just in the IO tree as scheduled connections.

Error code is 16#0001
Extended error code is 16#0000_0301
Error path: Plant, 2, 192.168.0.204
Error text: Commection failure

I've tried reading from other PLCs. Including controllogix and PLC5s but with the same result.

You get 301 because you are sending messages off after one another before the first one has finished. Try changing to manual trigger and wait for the msg to complete and see what error you get. You might have to wait a couple of minutes before your buffer clears.

I suspect it is going to timeout, which points to misconfigured msg instruction, misconfigured enbt, misconfigured network, or Plc 5 at the wrong version.

These other CLX that don't work suggest the plc5 version is ok.

Actually, do you have heaps of faulted connections to pf525s that are in your io tree? Rockwell KB21193 suggests these will use your default message buffer trying to re-establish comms. Strange!

The same KB article suggests if you increase the unconnected buffer size, the extra ones are ONLY for MSG instructions. Try finding out how to increase the unconnected buffer size by 10 and let us know if it helped.

I re-read the part about the PowerFlex 525's in the I/O tree being ready to run when the 1305 fails.

So most of them don't actually exist on the network ?

I can see that using up a lot of the controller's buffers attempting to establish CIP connections. The initial connection establishment goes through a backplane buffer, then it gets a CIP connection with reserved resources in order to perform Configuration or Auto Device Configuration.

I recommend inhibiting the I/O connection to any of the items in the I/O tree that are not physically on the network. You can un-inhibit them programmatically with an SSV when you do your failed drive migration.

I am doing something like this right now where I have drives on Profibus and we're going to switch them to Ethernet as they fail. Neither drive is an A-B VFD. The drives are all in the I/O tree but they're inhibited, and I have a routine that will allow the operator on the HMI to migrate from one network to the other, and an abstraction layer in software to handle the different mapping.

Thank you AustralIan. I was going to check the update rate on the drives Monday. However, now I'm leaning towards the unconnected drives being the problem. All 77 of the drives are unconnected right now because none of the existing 1305 drives have been updated yet.

Thank you for the suggestion Ken. Dealing with drive upgrades through an HMI isn't an option if have, as developing an HMI is the next project for this line and the 1305s tend to go out in the summer. You have me wondering if I could develop a routine that would enable a drive then use a GSV to see if it's connected and if it isn't then disable it again. Afterwards I could move to the next drive and disable the scan for that drive if the previous was found and enabled.

If I can't figure it out programmatically, I'll have to add a second used controller to the rack until we get over half of the drives online if 40 is the limit.

Thank you all for the help!

I've always thought that ADC was a little over-sold; if a system is so downtime-sensitive that ADC is necessary, it usually also has somebody available to at least go online and check a box.

But I digress.

What I would do is put in a routine that sends Read commands for the Identity object (the Product Type attribute) to each of the IP addresses of the drives that are Inhibited. Let it just cycle through and do each one, and allow the timeout to occcur before going to the next IP address. Yes, you'll have to write some code to go from one address to another. Changing IP addresses in a MSG is a little subtle and I can comment on that later.

If one of these usually-not-connected addresses returns a valid reply, the code can then use an SSV to de-inhibit the connection, and ADC can take off and do its thing.

Thanks Ken.

When I first started this project, I had thought of using an expression in the place of a tag name in hopes of saving writing 6 lines of logic for each drive (add a string onto the beginning and end of a counter's accumulated value). However, neither RSLogix 5000 nor TechConnect seemed to agree with that idea. I'm guessing I'll run into the same scenario when relating an IP address returning a valid reply. Do you have a work around for not being able to serialize the names of the drive connections?

I go into grumpy old man mode pretty quickly with my junior guys when they spend time trying to make the PLC operating system have a feature they expect from the higher-level OS'es they learned in college.

If there's a brute-force way to do it fast, I recommend using that method. Spend your time learning shortcuts in Notepad++ or Excel or Python to auto-generate code, rather than trying to make the controller do something it doesn't do.

In the case of messaging in ControlLogix, the CIP path uses IP addresses, not text object names. There's no DNS resolution or similar lookup going on.

The problem I encountered was when my last octet went from two digits to three digits. I never did figure it out properly: instead I had MSG instruction for the first 99 and another one the next 28.

What would be the Latin phrase for "Inelegant But Robust" ?

Lol. Point taken. You've opened up quite a few doors for me. Thank you.