PLC5-40 Major Fault Code 88

J

Thread Starter

Jeff Laird

I have just installed a new Rack and some new code to an existing PLC5-40 that is communicating RIO.

Here is the configuration information:
PLC 5-40 Series C Rev. B
RIO Baude Rate 115K
Panelview 1200 on RIO (Full Rack)
Panelview 1400e on RIO (Full Rack)

Besides the local Chassis
Racks 2-5 use 1771-ASB Modules
Rack 6 uses 1794-Flex IO (New Rack)
RIO is communicating at 115K BAUD.
Both ends of the RIO are terminated.

During normal run time there is no communication retries.

If I try to do any online edits, Every 1 out of 7 edits, the PLC will Fault. The error code I get is Error Code 88 - Scanner Channels are overloading the Remote I/O Buffer; too much data for the processor to process.

The file number and the rung number where the error occured stay at 0.

This PLC is running an entire dairy plant and making troubleshooting difficult because there can be no down time.

If anyone has any experience with this error or has some ideas I would greatly appreciate it.
 
S

ScienceOfficer

Jeff---

To state the obvious, you must be operating very near to some internal resource limit in the 5/40. Your I/O space is really not that large, but I'm wondering about Block Transfers and messaging. Online editing needs memory space (probably not your problem) and messaging resources. I think you are near the edge in messaging and online editing is pushing you over the edge.

Is this PLC servicing a lot of external network communications, say from an HMI, other PLCs, or other data clients? If so, can some of that be stopped while you are doing online changes?

Similarly, are you doing a LOT of Block Transfers to intelligent modules or the PanelViews? If so, can you stop some BTs while you are doing online editing?

Hope this helps!

Larry Lawver Rexel / Central Florida
 
Larry ---

Thanks for the input... I've seamed to have stumped Rockwell also on this. I agree that adding this little bit of code and a new rack has pushed the PLC5 over the edge - but from the vustomers perspective - it worked before you got here. The program is not using a lot of BTR/BTWs - but one thing I might try is instead of just using the Enable bit from the block tranfers, I might try putting a timer with the enable bit, just to slow down the RIO network traffic a little. Also I ordered a new PROM from for the PLC5 - there's is REV B - Current Prom Rev is Q.

Thanks.
 
B

Bradley Hite

Hello Jeff,

I agree with Larry Lawver. You need to take a hard look at how many BTR/BTW instructions you have in the program and how they are being activated. If they are set for continuous mode or are cycling directly off of their .EN bits you are probably overflowing the Block Transfer Buffer.

If the above is indeed the case then the solution is to take better programatic control of the BTR/BTW instructions. They need to be managed so that they do not free run and overflow the buffer.

Bradley G. Hite
Intertech Inc
mailto:[email protected]
Teaching Practical Skills for a Technological World
 
A

Andy Quisler

Jeff -

I almost exclusively program in dairy and whey plants... if you'd like to discuss challanges and quirks in our industry please feel freee to email me.

Andy Quisler
[email protected]
 
H
Jeff,

A couple of things to look at are: Can you increase the RIO Baud rate (if the remote cable is short enough), that could buy better throughput. Another item are the PanelViews, how is their data transfer set up with the processor? If there is some block transferring used you might optimize that based on what display screen is up. Have you tried separating the RIO (of course only possible if there is the cabling in place) into two different channels?

Aside from that, this is another one of those lessons about putting all eggs into one basket!

Let us know what you find.

Hugo
Rockwell Solution Provider
http://www.plc-control.com
 
M

Marty Vander Plaats

One other thing you can do is look at the block transfer queue status. If you go to the processor status and go to the rack tab you can look at the status word for the queue. Word 7 for racks 0-7. If you are trying to do too many block transfers, you will get a queue full bit that you can examine in the logic.

Also, you should check the rates of the cards you are looking at. Most analog input cards, and output cards have a fairly slow update rate. you may be reading them faster than necessary.

Also, you should look at if you are writing to input cards continually, or just on configuration change.

Also, are you reading your analog output cards? It is not necessary to read them continually. Placing timers on the BTR/BTW instructions will help you control when the communications happens.

Marty Vander Plaats
Interstates Control Systems Inc.
 
S

Stephan Markwalder / Switzerland

I would set S:77 (communication timeslice) to a higher value, assigning a fixed time as may be even 3 or 4 ms. This helped on some of my applications to get a more constant BTR-response. I have a 5/11, which communicates over RIO (as an adapter) to a 5/40C, RIO speed set to 230kB/s with one BTR. As per the manual, I sould receive a new BTR-message every 6.5ms, but sometimes before changing S:77, there was a delay of up to 30ms!
If you can, try also to seperate the racks into different channels:
Channel 0 and 1 are handled by the same communication processor where channel 2 uses its own communication processor.
So, if you can move your racks to channel 2A and 2B that also should help, freeing channel 1 for your (assuming) DH+ communication!
 
Top