On one screen, RTE-004 Log buffer memory is full means the panel's internal DRAM log buffer has no device it can drain to. Set all three data storage selections and every logging object's destination to the USB drive that is actually inserted; if the message still returns with the drive present and busy, lengthen the sample interval until the write load drops.
An HMI screen that shows RTE-004, Log buffer memory is full, is telling you one thing: the panel's internal DRAM log buffer has filled because nothing drained it. Logged records land in that buffer first and write out to the storage device each logging object selects. When the message appears on one screen only, the cause sits on that screen: an object aimed at a device that is not present, or more data arriving than the drive can write. This article separates the two causes, names the settings that fix the first, and works the arithmetic for the second.
What RTE-004 tells you
The message is literal. The panel holds every record a trend, data-log object or log object writes in an internal DRAM buffer, then drains that buffer to the selected storage device. The panel maker's runtime error documentation lists the code for one configuration: the project is set to log to USB and no USB flash drive is installed. A full buffer is therefore the shared symptom of both failure modes, a missing device and a device that cannot keep up.
Two more facts narrow the search. The code is left out of some help files, so a search for RTE-004 comes up empty, and that result tells you nothing about the fault. And the code follows objects, not the panel: a screen with no logging object never feeds the buffer, so it never raises the code. The screen where the message appears is the screen whose objects are writing, or trying to write.
Queued records that wait for a device come up wherever a panel keeps history. The alarm case works the same way; see logging PLC alarms to a circular event buffer with separate pointers.
Symptoms and what each points to
- Message appears the moment the screen opens and its logging starts: a destination that is not present. The buffer cannot find the device an object or panel selection names.
- Drive is present and its files open over the network, yet the message still shows: at least one object still points elsewhere, most often CF1 or CF2 when the panel has no card fitted.
- Drive indicator blinks steadily, new files appear on the drive, and the message still returns: the write load outruns the drive. Records reach the device more slowly than the objects produce them.
- Power cycle clears it and it comes back on the same screen: the cause is still in the project. Cycling empties the buffer and changes no setting.
Checks, in order
- Note the screen where RTE-004 appears. That screen's objects are the suspects.
- Open the project in the programming software and list every object on that screen that writes data: trends, data-log objects, log objects. In a project converted from an older HMI package, every print selection converts to a log object, so screens inherit log objects nobody asked for.
- Open each object's properties and read its storage destination. Flag every object aimed at CF1 or CF2 when no card is fitted, or at a path that no longer matches the drive in the port.
- Open the panel manager in the programming software and read all three data storage selections. Any one left on a missing device keeps the buffer from draining.
- Confirm the USB drive is inserted and recognized. If the panel does not see the drive at all, work through the checks for a USB drive an HMI panel does not recognize first.
The fix when a destination is missing
Set all three panel manager data storage selections to USB. Leave none on CF1 or CF2 unless a card is fitted and you mean to use it. One stray selection gives the buffer a destination that does not exist, and the buffer never drains. Correct every object flagged in the checks too: the panel selections and the object destinations are separate layers, and the code persists until both name a present device.
Transfer the project, keep the drive inserted, and open the screen that failed. Make the change during planned downtime.
If you are still deciding where logging should live, the storage locations an HMI panel can write PLC data to covers the options.
The fix when the drive cannot keep up
If every destination already names the inserted drive and the code still returns, work on the arrival rate. Two levers reduce it: a longer sample interval on the screen's trends, and fewer trends or logged tags on that screen. Adding logging objects raises the load, and moving objects to another screen helps only if the objects that move take their writing with them.
Lengthen the interval in steps until the drive indicator blinks in short bursts with the message gone. If the process needs every sample, cut the trend count first and keep the interval.
Example: sixteen trends at one sample per second
A screen logs 16 trends, the maximum the panel software documents. Suppose each trend samples once per second, an interval of 1 s; substitute your own interval and the arithmetic scales the same way.
Arrival rate at the buffer: 16 trends × 1 sample/s = 16 samples/s. Over a minute that is 16 samples/s × 60 s = 960 records per minute the drive must write, plus file overhead. Its indicator stays lit for long stretches and RTE-004 returns.
Two repairs, same arithmetic:
- Double the interval to 2 s: 16 trends × 0.5 samples/s = 8 samples/s, a 50 percent cut in the write load.
- Keep the 1 s interval and log 8 trends: 8 trends × 1 sample/s = 8 samples/s, the same load.
Both halve the rate the drive must sustain. If the code still returns at 8 samples/s, halve again to 4 samples/s. The screen is fixed when the code stays away for a full logging cycle and the indicator blinks in short bursts instead of long unbroken stretches.
Confirm the buffer drains again
- Leave the failing screen displayed through a full logging cycle. RTE-004 must stay away.
- Open the drive over the network and confirm new files carry current timestamps. A drive whose files open answers a different question; the timestamps answer yours.
- Watch the indicator. Short bursts are normal. A steady light while the message returns means the load is still too high.
- Pull the drive once at a moment when a gap in the log is acceptable. The code should reappear within the logging cycle, which confirms the buffer drains to that drive. Reinsert it, confirm logging resumes, then release the machine.
What brings the code back
- One of the three data storage selections left on CF1 or CF2.
- The panel selections corrected but one object left aimed at an empty slot, or the reverse.
- A converted project put back on the panel without reviewing the inherited log objects.
- A drive removed or swapped mid-run. Keep the port where the stick stays put while that screen logs.
- The power cycle used as the repair. It clears the message only until the buffer fills again.
Recommendation: Set all three panel manager data storage selections and every logging object's destination to the drive that is actually inserted, transfer, and re-run the failed screen. If RTE-004 still returns with the drive present, double the sample interval first, then cut the trend count, until the drive indicator blinks in short bursts and the code stays away for a full logging cycle.
Questions
Does power cycling clear RTE-004 for good?
It clears the message for the moment. The DRAM buffer empties when power drops, so the panel starts with room again, and the code returns the next time the same objects log to the same missing destination or at the same overload. Use a power cycle to finish a run, then change the destination settings or the sample rate. Those settings are the repair; the power cycle is not.
Why does the message mention memory when the drive is the problem?
The text names the buffer because that is where the panel holds records before writing them out. The buffer fills only when the write to the device stalls, so a full buffer points upstream, at the destination or the data rate. Searching memory sizes or buffer settings sends you down the wrong path; the storage selections and the object destinations are where this fault lives.
What should you have ready if the code persists after both fixes?
If every storage selection and object destination names a present drive, the log rate is reduced, and the code still returns, take the fault to the panel maker's technical support. Have the panel model, the programming software version and the project file ready, plus the screen number where the code appears and the trend count and sample interval in use on it.
Can I log to a CF card instead of USB?
Only if the panel has a card fitted in the slot you select. An object aimed at CF1 or CF2 with no card is the most common single cause of this code, so pointing logging at a CF card is safe only while the card stays present. If you use one, set all three panel storage selections to the same card so no selection names a device that is not there.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.