SLC500 No network buffer space available

Hi all,

We have an SLC505 that has been running for years. It uses a MSG command to pull data from another remote SLC505. The MSG is now in error, with the message "No network buffer space available".

Both PLC's are healthy, and I can connect to both over ethernet. To my knowledge, nothing has changed on either PLC.

I'm not overly familiar with the SLC brand - I can't see any tools like processor/memory/communication monitoring tools that the Control/Compact Logix processor family has available.

I've tried clearing the errors, and nothing works. I'm currently seeing if the plant can take the PLC down for a download.

Any suggestions before I try this?

snoochems said:

Hi all,

We have an SLC505 that has been running for years. It uses a MSG command to pull data from another remote SLC505. The MSG is now in error, with the message "No network buffer space available".

Both PLC's are healthy, and I can connect to both over ethernet. To my knowledge, nothing has changed on either PLC.

I'm not overly familiar with the SLC brand - I can't see any tools like processor/memory/communication monitoring tools that the Control/Compact Logix processor family has available.

I've tried clearing the errors, and nothing works. I'm currently seeing if the plant can take the PLC down for a download.

Any suggestions before I try this?

Click to expand...

Anyone add additional MSG instructions lately? If multiple MSG instructions are active concurrently it will overrun the buffer...you have to stagger their activity.

You might want to look at these status bits:

Comms Servicing Selection S:2/15

When set, only one communication request/command can be serviced per END, TND, REF, or SVC. When clear, all serviceable incoming or outgoing communication requests/commands can be serviced per END, TND, REF, or SVC. When clear, your communication throughput will increase. However, your scan time will increase if several communication requests/commands are received on the same scan. To prevent inadvertent changes to this setting, program an unconditional OTL instruction at address S:2/15 to ensure one request/command operation, or program an unconditional OTU instruction at address S:2/15 to ensure multiple request/command operations.

Msg Servicing Selection S:33/7

This bit is only valid when the Comms Servicing Selection bit (S:2/15) is clear (which selects service all commands). When S:33/7 is set and S:2/15 is clear, all outgoing channel 1 MSG instructions are serviced per END, TND, SVC, or REF instruction. Otherwise, only one outgoing channel 1 MSG command or reply is serviced per END, TND, SVC, or REF instruction.

If the machinery can run without the messages working, unplug the ethernet cable from the SLC with the message for at least 30 minutes and plug it back in. Then you don't have to halt production.

I believe the default network inactivity timeout is 30 minutes. I have been in a similar situation where we could live without the message that had failed, but it would have been a Major Payne to shut down. You may have to disable the messages with the cable unplugged to get the buffer to clear.

http://www.plctalk.net/qanda/showthread.php?t=53152

I'd be curious to know how the messages are programmed too. Just because it has worked right for years, does not mean that the logic can't be improved. Maybe your network has been in ideal condition for years and then recently suffered a disturbance.

I write message logic to wait for a DN or ER bit before processing (or repeating) the next message. This has always served me well.