C-more treats the rolling history shown by a trend object separately from files written to CF or USB storage. Set the trend’s stored-sample capacity for the chart history you need; do not expect that setting to rotate or erase external log files. A screen-clear operation’s effect on stored files must be tested on the exact panel and project before using it in production.
Separate chart history from external log files
Use two different requirements when planning the configuration:
- On-screen history: The trend object keeps a limited number of historical samples for cursoring through the chart. The legacy information describes the chart dropping its oldest point when the stored-sample limit is reached. This is a rolling history buffer, not a week-by-week file archive.
- External data log: The panel writes log files to removable storage. A reported configuration created date-named files daily, starting at midnight. Those files are separate from the chart’s displayed history and were not reported to have automatic age-based deletion.
Clearing a displayed trend and deleting, truncating, or retaining its external log file are different operations. Do not infer one from the other. The original question about whether a screen clear also clears flash was not resolved by a confirmed test; use the controlled test below to determine the behavior on your panel.
Read the trend sample settings before changing them
Record the configured sample interval and TOTAL STORED SAMPLES for each trend object. Also record the number of pens and objects, the panel’s exact model, the project/software version, and the current storage destination. These readings tell you whether the immediate goal is a rolling chart or persistent file logging.
For a chart intended to show one week, estimate the required stored-sample capacity from the interval:
samples per week = 7 × 24 × 60 × 60 ÷ sample interval in seconds
For example, at a one-second interval, the arithmetic gives 604,800 samples for one week. That is a capacity calculation, not a guarantee the panel can allocate that much project memory. If the interval is not one second, use the actual configured interval. Also verify whether every trend object uses the same interval and whether the panel’s sampling behavior produces one stored point per interval.
Decision: if the need is recent chart history, size the stored-sample setting and check memory before transfer. If the need is week-long or month-long archival files, inspect the external logging configuration and storage lifecycle separately. Do not increase the chart buffer as a substitute for file retention.
Check memory before adding samples, pens, or objects
A trend consumes memory based on more than its number of pens. The legacy troubleshooting report identifies total stored samples as a major factor: the historical trend data occupies project memory, while SRAM temporarily buffers trend logging data pending storage. Larger sample counts increase the project-space requirement even when the trend object and pen count stay unchanged.
In one reported blank-project test, the software accepted six objects with 16 pens each plus a seventh object with eight pens, but rejected a different arrangement with 13 objects of four pens each. The transfer failure was PTC-010: There is not enough memory. This is evidence that a simple pens-per-panel limit is not a reliable sizing rule; it is not a universal maximum object or pen count. A separate legacy explanation states that the programming software did not include those trend data points in its project-size estimate, so the panel could report the memory error after transfer rather than the software warning before transfer.
Decision: if the panel reports PTC-010, reduce TOTAL STORED SAMPLES first, then re-transfer and test. If the error remains, reduce object or pen count and check the panel’s project-memory status. Avoid making several changes at once; otherwise, you will not know which change restored a successful transfer.
Distinguish daily files from automatic log rotation
A reported C-more setup created a new date-named data-log file each day at midnight on CF or USB media. That behavior creates daily files; it does not establish a rolling one-week retention policy. Another reported configuration had no built-in automatic deletion, and the operator planned to replace and archive a CF card periodically.
The legacy help quotation lists a maximum of 18 logging files allocated by category, including 16 for trend graph/PID trend data and one each for alarm-message and message-database logs. Treat this as a limit on log-file types or allocations described by that help, not as a promise to retain only 18 daily files or to delete old files automatically. The report of two alarm-message text files with different dates is compatible with separate dated log files; it does not define the retention or overwrite rule.
Decision: if dated files accumulate, check actual free space and the generated filenames on the target panel. If files are not being created at the expected interval, confirm the logging destination and active project settings first. Do not wait for a presumed rollover or overwrite to protect the storage device.
Test screen clearing without risking production records
Do not use a production clear command as an experiment when historical records matter. Make the test on a spare panel or a controlled copy of the project and storage media. The exact behavior can depend on the panel/software generation and the command being used.
- Back up the project and copy existing log files to a separate computer or removable medium. Record the current file names, sizes, and latest timestamps.
- Configure a test trend with a known tag and sample interval, then collect enough data to show chart history and produce a log file. Record the chart display and the storage contents.
- Use the specific screen-clear operation under evaluation. Do not delete files manually during this test.
- Inspect the chart and the external storage separately. Determine whether the old chart points disappear, whether the existing log file remains, and whether new samples append to a file or appear in a new file.
- Power-cycle only after recording the first result, then inspect the restored chart and files again. This checks persistence separately from the immediate clear behavior.
If no spare panel or controlled media is available, leave production records untouched and consult the exact model’s current C-more documentation or AutomationDirect support before clearing. The test result should be recorded with panel model, software version, destination media, and the clear command used.
Reduce the chart buffer when transfer fails
For a project that fails at panel transfer with PTC-010, preserve a copy of the current project, then reduce the stored-sample count and retry. Keep the change focused so the fault’s cause remains identifiable.
- Record the failing object count, pen count, sample interval, and
TOTAL STORED SAMPLES. - Lower the stored-sample count to the minimum that meets the chart-history requirement. Recalculate the desired capacity from the interval rather than copying a sample count from another project.
- Transfer the project and check whether the panel accepts it. If it still reports
PTC-010, reduce trend objects or pens in a controlled step and retry. - Once transfer succeeds, test representative trends and confirm cursor history, sampling, and file logging still meet the operating requirement.
Changing the sample interval alone was reported not to resolve one memory test; the memory explanation points to total stored samples and project-space use. Verify the actual stored-sample value after editing rather than assuming a changed interval has reduced the allocated history.
Verify the storage plan before returning to service
Keep chart capacity, daily-file generation, and storage capacity as three separate acceptance checks. A chart that rolls correctly can still coexist with growing log files. Likewise, files on a card do not prove that the trend can display the desired historical window after a restart.
- Confirm the trend rolls at its configured sample limit and that the oldest chart point drops off as expected.
- Confirm the expected dated log files are created on the selected media and remain readable after a power cycle.
- Confirm the clear operation’s tested effect on both chart history and external files; document the result for the exact panel/project combination.
- Check available card or USB capacity on a schedule based on measured file growth. A legacy user reported over a year of capacity on a 2 GB card for two trends logged once per minute, but their tag widths and application differ; do not use that anecdote as a sizing guarantee for a one-second, many-pen project.
The legacy report also describes Ethernet access to CF files through FTP for copying. Treat remote deletion or an automatic FTP cleanup program as a separate, unvalidated maintenance method; verify access, permissions, file behavior, and recovery on the actual panel before relying on it.
FAQ
What happens if the C-more trend reaches its total stored-sample limit?
The reported chart behavior is to continue rolling and drop the oldest point. Set the capacity for the history window you need, and verify on the target panel that its memory can support that sample count.
What happens if I clear a C-more trend on screen?
Do not assume the external log file is also erased or retained. Test the exact clear operation on a backed-up project and separate storage media, then inspect the chart and files independently.
What happens if C-more reports PTC-010 during transfer?
Reduce TOTAL STORED SAMPLES first and retry. If the panel still reports PTC-010, reduce trend objects or pens in controlled steps and verify project transfer and logging after each change.
Stop before clearing production data or automating file deletion if the test result is unknown, files are missing, or capacity continues to fall unexpectedly. Escalate to AutomationDirect support with the panel model, programming software version, project backup, error text, and observed file behavior.