Multi-state text indicator message log: where it saves

Why don't my multi-state text indicator messages appear in the history object?

Log Message and the history object are two separate destinations with nothing connecting them. The checkbox writes each message as a CSV record on compact flash or USB storage. The on-screen history lists alarm events. A message that is only logged never becomes an event.

The indicator's job ends at display. It shows the message that matches the tag's current value or bit number. It has no route into the alarm system, so an empty history object says nothing about the message definitions. It means no event exists for those states yet. If you are still choosing between object types, the article on multi-state text or lookup text for HMI messages covers which one fits which job.

Where does the Log Message CSV file save?

The destination is the device selected under Panel Manager, in Data Storage, which offers CF1, CF2 or USB. Open that page, read which of the three is chosen, and confirm the card or stick is actually fitted before you look anywhere else.

Three checks settle it:

1. Note the selected device in Data Storage.
2. Confirm that media is present and readable.
3. Force one known state change, then pull the card or stick and open the CSV on a PC. The file on the storage device is the log; the history object is the wrong place to test for it.

One documented restriction belongs in the check. On the panel family this behavior comes from, CF1 accepts data logging only when the project is transferred to internal flash. If the application itself is stored on CF1, point Data Storage at CF2 or USB. If USB is the destination and no file ever appears, the article on testing a USB drive an HMI panel refuses to read works through the drive-side causes in order.

How do I get multi-state messages into Alarm History on the touch screen?

Create an event for the state in the Event Manager, give it an Alarm Action, and check Show in Alarm History. That route, from event to alarm action to history, is the only one onto the screen. The indicator's Log Message checkbox never feeds the history object.

Key the event to the same tag condition the indicator displays for that state, and type the message text the operator should read. Copying the indicator's wording keeps the screen and the history consistent. The event can also be logged, so the same state change lands in the CSV as well; the two switches serve the two destinations, and you choose per state which destinations it needs. For a state that needs attention right now, add an alarm pop-up message box on the HMI so the fault announces itself instead of waiting in a list.

What does each test result point to?

Force one known state change and read the two destinations apart. A CSV record without a history entry points at the event path. A history entry without a CSV record points at Data Storage. Neither appearing means the change never reached the panel.

• CSV record appears, no history entry. File logging works. The state has no event, or its event lacks the Alarm Action or the Show in Alarm History check. Build or repair the event.
• History entry appears, no CSV record. The event path works. Check Data Storage: the selected device may be missing, or the project may sit on CF1, which logs only when the project runs from internal flash.
• Neither appears. The transition never happened at the panel, or the revised project was never transferred. Re-trigger with a tag value you can watch change, and confirm the download completed.
• Old entries vanish as new ones arrive. The history object is cyclic and has filled. Some panels keep as few as 64 entries, and the article on saving HMI alarms beyond the 64-entry history limit to USB shows the way out.

Must every state on a 600-state indicator get an alarm event?

No: map only the states an operator must review on screen. On a 600-state indicator that is the fault, hold and batch-end states, a few dozen at most. The CSV keeps recording every state change while Log Message stays ticked on all messages.

The CSV path is already complete, so events buy screen visibility for a chosen subset. Write the subset down before touching the software: which states must a supervisor be able to pull up at the panel a week later? That list is the event map, and everything off the list stays file-only. If the review list keeps growing, move the history into the controller; logging PLC alarms to a circular event buffer with separate pointers shows a structure that keeps the record count in the PLC, where the buffer size is yours to set. If the editor caps a new multi-state object at 5 states, raise the count in the object's setup; the walkthrough on creating a multi-state indicator beyond five states shows where that limit sits.

Example: a one-state test on a 600-state indicator

One forced state change tests both paths in about 10 minutes. The example indicator carries 600 messages. 18 of them are faults. The test maps those 18 fault states to events, forces one fault state by hand, and expects one new history entry plus one new CSV record. Pull the CSV within 24 hours of the test so the record you just made is easy to find at the top of the file.

Scenario: a packaging line HMI runs a multi-state text indicator off a recipe-step tag. All 600 messages have Log Message ticked. Operators must be able to review faults at the panel, and 18 of the 600 messages are faults.

1. Map the 18 fault states to events: one event per state, keyed to the step values that drive the fault messages, each with an Alarm Action, Show in Alarm History checked, and the message text copied from the indicator. The other 582 states get no event: 600 - 18 = 582, and every one of them still reaches the CSV through Log Message.
2. Transfer the project by the site's normal download procedure.
3. With the machine at a safe state, force the step tag to 419 from the programming software. A forced value tests the panel without driving a real fault. Expect exactly one new entry in the Alarm History object and one new record for message 419 in the CSV on the Data Storage device.
4. Read the result. Both appear: the path works, so map the remaining 17 fault events (18 - 1 = 17) and transfer again. Only the history entry appears: recheck the event setup. Only the CSV record appears: recheck Data Storage. Neither appears: the transfer or the trigger failed.

After the second transfer, the history shows the fault transitions carried by the 18 events, and the CSV holds every state change on the line, faults and ordinary steps alike.

How do I roll the events out and verify the panel?

Work in small batches with one transfer each, about 10 events per batch. Verify on the running panel before the next batch goes in. Trigger one state per batch and confirm its message lands in Alarm History. Test a second state whenever different ranges use different event definitions.

A batch that fails on the panel comes with two artifacts: the pulled CSV and the event configuration. Between them they name the broken path, so keep both with the batch record.

Recommendation: Leave Log Message ticked on every message so the CSV records all state changes, create events with Show in Alarm History checked only for the states operators must read at the panel, and test the route on one forced state change before mapping the rest. On an indicator with hundreds of states, that means the fault states go in as the first batch and everything else stays CSV-only.

Questions