The test record is longer than 64 characters, the alarm message field is not, and one completed test lands in the log as three broken lines. Every fix that starts at the panel makes that worse. The record belongs to the CPU that produced it — build it there and push it out whole.
Try These First, Then Stop
These are the fixes that come up on shift, roughly in the order people reach for them.
| Quick fix | What it does | Why it fails |
|---|---|---|
| Split the record across two or three alarm messages | Chops the row into 64-character chunks and fires them together | Alarm history orders and stamps entries by event, not by your intent. Real alarms interleave with your chunks, and acknowledge/clear entries add rows you never wrote. Every import turns into string surgery. |
| Shorten the record until it fits | Drops operator, part number, limits | The dropped fields are the ones quality asks for six months later. You trade traceability for a wall you do not have to hit. |
| Use the panel's built-in tag logging to removable media | Writes a fixed column set on an interval or trigger | That subsystem samples tags; a test result is an event with variable content. Somebody has to pull the stick, and a full or missing stick fails quietly. |
| Add a second RS232 datalogger box | Doubles the ports so the long string fits | Same architecture, twice the hardware. No confirmation the write landed, and the record is still assembled somewhere other than where the data lives. |
| Watch it in Data View or a trend | Shows live values on the laptop | Debug tools, not loggers. Drop the programming connection and the record is gone. Trending samples a value over time; you want one row when the test ends. |
Understand Why 64 Characters Is a Wall
Alarm logging is a fixed-width event subsystem. The message field in the alarm database is dimensioned at 64 characters, and the history row it produces carries a trigger reference, a timestamp and a state — built for "Station 3 overtemp," not for . Depending on how the alarm is configured, a single trigger can also write more than one history entry as it activates, is acknowledged and clears, so one test generates several rows before you have done anything wrong. The history buffer rolls too: once it fills, the oldest entries are overwritten, which gives your test archive a shelf life set by unrelated alarm traffic.
Nothing on the CPU side carries that limit. Strings are a native data type in Do-more, and string memory is allocated in blocks of two different widths. Open Memory Configuration in Do-more Designer, read the width of each string block and how many the H2-DM1E has allocated, then size your record against the wider block if it needs it.
Move the Record Build into the CPU
The H2-DM1E has the string instructions and the on-board Ethernet port to do this with no middle box. STRPRINT formats registers, timers and text into a single string with explicit field widths and decimal places; PRINT sends a formatted message to a device you pick from the device list in Do-more Designer. Pick the output path by what is on the shelf tonight, not by what is elegant.
| Output path | Needs | Behavior | Fails when |
|---|---|---|---|
| File on a PC via the logger utility installed with Do-more Designer | Logger running on a reachable PC, static IP on the CPU | Text file grows one line per record, PC adds its own arrival timestamp | Logger closed, PC rebooted overnight, subnet changed |
| Serial PRINT to the RS232 datalogger already installed | Second serial port wired, baud and parity matched | Keeps the existing box and file, but the record is now built in the CPU with no 64-character cap | No flow control — a busy receiver drops characters silently |
| TCP client to a listener or SCADA node | Device configured with the PC address and port, something listening | Records stream as they are produced | No listener: retries, backlog, dropped rows |
| Buffer in CPU memory, drain on demand | Retentive string array plus a write index | Survives PC downtime, flushes when the link returns | Outage outlasts the buffer and it wraps |
Get it running on the serial path if that box is already mounted; move to the PC file at the next maintenance window.
Build and Send One Row Per Test
- Size the record first. Add the worst-case width of every field, the delimiters, and the CR/LF pair. Round up and allocate a string that wide — if the total clears the short-string width, use the wider block.
- Format with
STRPRINTon the leading edge of the test-complete bit, not on the level. Give every numeric field an explicit width and decimal count so column positions stay stable. - Put the CPU's own date and time in the row from the system clock. The PC timestamp records arrival, not completion; carry both and you can prove where a delay came from.
- Pick one delimiter and stick to it. Comma works until a part description contains one — tab or pipe ends that argument. Quote any free-text field.
- Terminate every record with a CR/LF pair so the file reads as one row per test.
- Send with
PRINTand watch its status and error outputs. If the device is busy, hold the record and retry; do not re-arm the one-shot until the send has completed. - Set file rollover on the receiving side — one file per station per day, station ID in the file name.
Verify Before You Call It Done
- Run 20 tests back to back at the fastest cycle the station allows. Twenty rows. No duplicates, no blank lines.
- Force the longest record you can build: maximum digits on every numeric, longest part number, failure text in every optional field. Truncation shows up at the buffer boundary, never on average records.
- Import the file into a spreadsheet. Every row must have the same column count. A row with extra columns means an unescaped delimiter got into a text field.
- Open the file with line endings visible: exactly one CR/LF per record, nothing stray mid-record.
- Pull the Ethernet cable or close the logger mid-run. Decide now whether missing rows are acceptable or the CPU has to buffer and flush.
- Compare scan time before and after. A format-and-send running every scan instead of once per test shows as scan growth and a file measured in megabytes per hour.
- Power cycle the CPU with a record queued. If the queue comes back empty, that string memory is not in a retentive range.
Watch These Failure Modes
- Level-true done bit. One row per scan instead of one row per test. This is the most common cause of a log file that fills a drive in an afternoon.
- The PC becomes production-critical. If the record is the only proof the unit was tested, buffer in the CPU and treat the PC as a destination, not as the record of truth.
- Non-retentive string memory. Queued records vanish on a power blip. Set the retentive range in Memory Configuration deliberately.
- Two stations, one file. Lines interleave and nothing tells you which station wrote which. One file per station, merge later.
- DHCP anywhere in the path. The CPU address or the PC address moves and logging stops without an alarm. Static both ends, same subnet or a route that actually exists.
- Serial without handshaking. At high baud a busy receiver drops characters and you get half a row with no error indication on either end.
- Alarm history as an archive. It rolls. Anything you need in six months goes in the record file.
- Spreadsheet locale. A PC set to decimal comma turns a comma-delimited numeric file into garbage on import.
Stop if the record still truncates after you have sized the string, confirmed the one-shot and watched the send status bits — that is no longer a rung problem. Save the project file, a sample of the record you expect and the file you actually get, and take it to AutomationDirect technical support rather than rewriting the logic a fourth time on night shift. Same call if the CPU drops Ethernet sessions under load; that is a configuration or firmware question, not something to chase with more string logic.
FAQ
Why does my C-more alarm message stop at 64 characters?
The alarm message field in the panel's alarm database is dimensioned at 64 characters. It is an event subsystem, not a record writer — a longer test row has to be split across entries, and the split pieces get interleaved with real alarms and with acknowledge/clear entries.
Why does the H2-DM1E log the same test result over and over?
The test-complete bit is level-true and the format-and-send rung fires on every scan while it is on. Drive STRPRINT and PRINT from a leading-edge one-shot and do not re-arm it until the send status confirms completion.
Why does my logged file open as one long column in a spreadsheet?
The records are not terminated. Append a CR/LF pair to the end of every record so each test becomes its own line. If instead the rows are correct but fields land in the wrong columns, a free-text field contains an unescaped delimiter — quote it or switch to tab or pipe.
Why do records go missing when nobody is at the logging PC?
PLC-to-PC logging is a push: if the logger application is closed or the PC has rebooted, the records have nowhere to land. Buffer them in a retentive string array in the CPU with a write index and drain the queue when the link comes back.
Can the H2-DM1E write a log file to a USB stick or memory card by itself?
No — that CPU has no removable-media slot, so the record has to leave over serial or Ethernet. Send it to the existing RS232 datalogger, to the file logger utility that installs with Do-more Designer, or to a TCP listener on a PC.