A numeric data log records numbers and leaves string tags behind, because text becomes a record only inside a logged message or a saved alarm file. Embed the string tag in a message database entry and select Log Message, or embed it in an Event Manager alarm action and select Save File to..., then prove the route with two known test strings.
Your numeric data log fills in on schedule and the text never arrives. That gap is how the panel is built: a numeric data log samples numeric tags, and a string tag never becomes a numeric record no matter how the screen displays it. Text reaches a log through two documented routes on the panel: a message database entry with message logging turned on, or an alarm action that saves a file. Both routes work the same way at the core. The String Tag goes into the message or alarm text, and the setting that saves that message or alarm as a record goes on. This article takes you through checking the tag, choosing the route, the exact settings, and the two-string test that shows the log holds live text before the panel goes back on the floor.
Why does my data log show numbers but not the text?
A numeric data log samples numeric tags only. A string tag sitting in the project never becomes a record there; the text reaches a log only when you embed the string tag in a logged message or in an alarm action that saves a file.
Two details explain the symptoms you usually see. If the log shows nothing at all for the string, the log object has no string route to it; a numeric log carries no setting that accepts a string tag. If the log shows odd numbers where the text should be, the project is addressing the string's character data word by word. An address into that character data returns the numeric code of one character, usually the first. Those codes are the bytes of the text, not the text.
Leave the numeric log alone while you add the text route. It keeps sampling on its own interval, and choosing a 10-minute logging interval for switch states is the article for that side of the setup.
Is the value actually a string tag?
Open the tag's definition and the screen object that shows the value. If the panel stores it as a string tag holding ASCII characters, a message can embed it. If it is a number formatted as text, no logging route will ever capture characters.
Tag databases keep separate tag types, typically analog, digital and string, and only a string tag carries text a message can embed. Check three things before you build anything:
- The tag's type in the database is string.
- A screen object shows the live text correctly while the line runs.
- A known test value written into the tag appears on that object unchanged.
If the display is blank or wrong, fix the tag source first; logging cannot recover text the tag does not contain. If the display is right and the log still holds only numbers, the tag is fine and the missing piece is the logging route in the next sections.
Which route logs the text, a message or an alarm action?
Use the message database route when the text belongs to a running process or operator message. Use the alarm action route when the text belongs to an event condition. Both need the string tag embedded, and each writes a different kind of record.
| Route | The text belongs to | Setting that writes the record | Where the record goes |
|---|---|---|---|
| Message Database with a Lookup Text Object | A process or operator message shown while the line runs | Log Message selected on the message entry | The panel's message log |
| Event Manager Database with an Alarm Action | An alarm or event condition | The Alarm Action with Save File to... selected | An alarm log file on the memory device set in the Panel Manager's Data Storage Alarm Save To box |
Recommendation: Keep the working numeric data log exactly as it is and add the text route beside it. Pick the Message Database with Log Message for running text such as lot codes, batch names and station IDs. Pick the Event Manager Database alarm action with Save File to... when the text belongs to a condition the panel should record as an event. Run the two-string test from the worked example below before the panel returns to service.
Does logging strings slow the panel's communications?
Yes, they can: one panel software reference states that each ASCII string travels in its own communication telegram. Reading a large number of strings on a fast poll adds telegrams to every scan, while event-time logging keeps the cost off the wire.
That reference is about project reads, and the same arithmetic applies to any path that refreshes the tag often. A station name that changes once per lot adds one telegram per change. The same string polled once per second to keep it fresh adds 3,600 telegrams per hour (1 per second x 60 x 60), for text that did not change. So write the string in the PLC only when it actually changes, trigger the message or alarm on the event that goes with it, and keep the count of string reads in the project low.
How do you log a string with the message database?
Create the message in the message database, embed the string tag in its text, and select Log Message for that entry. The Lookup Text Object then shows the message on screen, while the Log Message setting is what actually writes it to the log.
- Create or open the message entry for this condition in the Message Database.
- Embed the String Tag in the message text where the live value should appear. This is the same embed mechanic as putting a live value inside an HMI message, and embedding a PLC variable in an HMI message string walks through it.
- Select Log Message on that entry. The entry stays display-only until this is selected; this check is what writes the record.
- Place the Lookup Text Object on the display so the application can show and select the message the way the screen needs.
- Run the project, trigger the message once, and open the log. The newest record must contain the string's live value.
If the message draws on screen with the right text but the log has no record, check the Log Message setting first, before any tag or communication setting.
How do you save string text with an alarm action?
Define the condition in the Event Manager Database, embed the string tag in the alarm text, and select the alarm action Save File to.... The saved file lands on the memory device chosen in the Panel Manager's Data Storage Alarm Save To box.
- Define the triggering condition in the Event Manager Database.
- Embed the String Tag in the alarm text so the record carries the live string.
- In that entry's Alarm Action, select Save File to...
- Set the Data Storage Alarm Save To device in the Panel Manager so the alarm log file has a memory device to land on.
- Trigger the condition once under control and open the saved file. The record must contain the expected string.
The panel record and the controller's own alarm history are different stores. If the PLC also keeps the event, logging PLC alarms to a circular event buffer with separate pointers is the controller-side pattern that keeps the last events when a trigger is missed.
What does a worked example look like on a packing line?
A packing line wants each case count message to carry the lot code. The engineer logs the 16-character string STATION-07-LOT42 through a message database entry and proves the route with a second string that differs in one character.
A case packer writes a lot code into a string tag at every lot change, and the supervisor wants each change in the log with the code attached. The engineer builds one Message Database entry, embeds the String Tag, selects Log Message, and keeps a Lookup Text Object on the line view so the message still shows during the run.
| Step | String in the tag | What the record must show |
|---|---|---|
| Trigger 1 | STATION-07-LOT42 | STATION-07-LOT42 |
| Trigger 2 | STATION-03-LOT42 | STATION-03-LOT42 |
STATION-07-LOT42 is 16 characters, and plain ASCII stores one byte per character, so each record carries 16 bytes of text payload: 16 characters x 1 byte = 16 bytes. Two triggers produce two records, 2 x 16 = 32 bytes of string payload in total.
The decision comes out of trigger 2. If the second record reads STATION-03-LOT42, the entry captures the live tag and the route is good. If the second record still reads STATION-07-LOT42, either the message text holds a typed literal where the tag belongs, or the tag did not update between triggers; fix that before trusting any record from this entry. The numeric case-count log keeps running untouched through both triggers.
How do you check the text actually reached the log?
Trigger the condition twice with two known strings and read the saved records the same hour. Record one must carry the first string, record two must carry the changed string, and the numeric log must still hold its samples.
Work through these checks in order:
- Read three things against each other: the live value on the screen object, the message or alarm as the panel presents it, and the saved record. All three must carry the same string.
- Change the test string to a second known value and trigger again, exactly as the worked example does. One record with the right text can come from a typed literal; the changed string is what separates a live tag from a fixed one.
- Note the wall-clock time of each trigger to the minute so you can match records by timestamp when you open the file.
- Confirm the numeric log still holds its samples after both tests.
Then sort the failure by what you see. No record at all means the logging option or the save action is off: check Log Message on the entry, or Save File to... on the Alarm Action. A record with missing or stale text means the embed or the live tag value is the problem, and no numeric log setting will fix it. When the second string lands in the second record, put the panel back in service.
Questions
What if the panel software has no message database or event manager?
Most panel packages include message or alarm logging under another name. Look for a message list, an alarm history or an event viewer whose entries can carry a text variable and be saved to a file, and check the help for the entry's logging option. If the package truly has neither, the string tag can only be displayed on that panel, and the text history has to be collected in the PLC instead.
Can the PLC keep the text history instead of the panel?
Yes. Copy the string into a block of controller registers when the event fires and let the controller's own record keep the most recent events. A circular buffer with separate read and write pointers holds the last events even when a trigger is missed, and the HMI can display the buffer contents on a screen later.
How long can a logged string be?
The character limit for a message entry is printed with the message settings in your panel software's help, so size the entry against the longest string the line will actually write. Each ASCII character is one byte, so a 40-character shift comment needs 40 bytes of message text plus the fixed words around it. If the limit comes up short, shorten the string in the PLC before it reaches the tag.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.