Max Unconnected Buffers in Control Logix

[RSL]

I recently had a problem with a system that is several years old. It has grown a LOT in the last couple of years. I needed to get Data from a PM3000 power monitor on EtherNet, so I configured a message. It failed again and again.

I researched the error and eventually found I was out of "unconnected buffers". I have read all there is to read on the Rockwell site. I still only have really vague grasp of what an unconnected buffer is. anyway....

I discovered that the processors default number of buffers is 10. I could see by using the task monitor that my high water for them was in fact 10. I wrote a message and changed the max to 20. My high water imediately went to 12. I can see I was stacking up a bit I guess? Anyway, my problem was solved. My new message now executes just as it should.

My questions are, Will the processor retain this new max number of unconnected buffers after a power cycle? I did an upload and saved afterwards too. Will the processor retain my new value if I do a download? I set my message that changes the max number of buffers to execute on first pass just in case. Was this necessary?

RSL

 

[Contr_Conn]

My questions are, Will the processor retain this new max number of unconnected buffers after a power cycle? I did an upload and saved afterwards too. Will the processor retain my new value if I do a download? I set my message that changes the max number of buffers to execute on first pass just in case. Was this necessary?

Processor will not retain new max number after power cycle, you will need to do it in the program on the first pass or after few seconds of runnung.

EDIT:
Processor will not retain updated value if you re-download the program without cycling the power.

From Design Considerations Manual:

execute a CIP generic message to configure that change each time you transition from Program mode to Run mode

Here is a good place to find more info about unconnected buffers:
Design Considerations Manual, Chapter 7
http://literature.rockwellautomation.com/idc/groups/literature/documents/rm/1756-rm094_-en-p.pdf
Common Procedures Manual, Chapter 9
http://literature.rockwellautomation.com/idc/groups/literature/documents/pm/1756-pm001_-en-p.pdf

I would recomend you to review your application to see where unconnected buffers used and determine if you can optimize your ladder to stay within 10 buffers.

 

[Ken Roach]

I've dealt with this issue quite a few times and aways grudgingly, since the buffer issue only comes up if MSG instruction programming has been done without regard to buffer management.

In your case, just condition your CIP Generic message that expands the buffer memory to run a few seconds (I would do 15 or 20 seconds to allow for ENBT bootup in the case of a cold boot) after transition to Run mode. Condition your other MSG instructions to not run until the buffers have been expanded.

Much of the data in the PowerMonitor 3000 can also be obtained through I/O connection to the Configurable Assembly. In that case the communications is handled by the 1756-ENBT firmware and you don't have to program anything (once you've configured the Assembly in the PM3000).

 

[RSL]

First, thank you both for replying.

I have my MSG configuring my unconnected buffers to execute at power up ahead of all my other MSG's. I was not sure if I had to do it that way. Why does the MSG need to execute after the ENBT is up and running? I thought this was a controller resource?

This system has several "groups" of MSG instructions that do cascade, but they are not linked together because their update intervals are different. This controller is used mostly as a "data concentrator" for 3 RSViews and 2 RSEnergyMetrix applications. For various reasons beyond my control they all use their own local OPC topics. It has 3 ControlNets and 3 EthernetIP networks. There are multiple controllers and PM3000's it polls for data. With all this going on, I finally used up all the buffers.

I am guilty of not understanding the unconnected buffers resource as it pertains to MSG instructions. I really did not think about them until after I had a problem. I can see after reading more about it that in most cases it is TOTALLY avoidable. (point taken Ken)

I do recognize that It could be coded to get by on 10 buffers. I will try and economize it and see if I can get below 10 again. This will take some work though.

Besides eating memory what other resources are used by raising the buffers from 10 to 20?

Ken, I thought you could only do an I/O type connection on series B PM3000's? Mine are all series A. If I am wrong, I will definitely change them all to an I/O connection. I am using the user defined data table already, to organize the data I want.

I do appreciate the links and advice from you both.

RSL