Three settings fix it: enable Historic on the alarm table object so every rising edge of the set variable appends its own record, change the style in the Visualization Manager so the class background renders, and check the details field and string type when a historic record reads TRUE instead of the string.
All three behaviors come from settings, and each one has a fix you can check on screen. On CODESYS V3.5 SP8 Patch2, an alarm table that shows one row per alarm, ignores the background color of its alarm class, and prints TRUE where a string value belongs has three separate causes: the table runs without history, the active visualization style suppresses the class background, and the <currentvalue %s> placeholder in a stored record substitutes the BOOL trigger where the live row substitutes the string. Enable the Historic option on the alarm table object, change the style in the Visualization Manager, and work the placeholder checks in order. Every check below ends in a gate: a count of records, a color on a row, or a text value you can read.
Which setting causes each alarm table symptom?
Three settings decide all of it: the Historic option on the alarm table object, the style in the Visualization Manager, and the variable bound to the %s placeholder. Match your symptom to the list below and go straight to its fix.
- One row per alarm, updated in place. The table runs non-historic. Enable Historic on the alarm table object, and every FALSE-to-TRUE edge of the set variable appends its own record.
- Reset text that follows the reset bit. Same cause. In a non-historic table the text belongs to the single live row, so it comes and goes with the bit; a stored record keeps it frozen.
- Class background ignored while the font applies. The visualization style. The fix is in the section on class background colors below.
- TRUE printed where the string belongs, only in the historic table. The stored record substitutes the trigger value. Check the details field and the string type, then log the string by a second path if TRUE survives both checks.
Why does the alarm table keep only one row per alarm?
The table runs as a live view: one row per alarm, updated in place as the alarm changes state, so a second rising edge of the set variable reuses the row instead of adding one. Enable Historic and every state transition appends its own record.
A non-historic table answers "what is the state right now". A historic table answers "what happened, and in what order". If the requirement is a new record each time the set variable rises FALSE to TRUE, the table has to be historic; no change to the alarm definition produces that in a live view.
Where is the Historic option when the properties show none?
You are in the wrong object: the history setting belongs to the alarm table, not to the alarm configuration where alarms and classes are defined. Select the alarm table object in the project tree, open Properties, and enable Historic there.
The alarm configuration and the alarm table are separate objects in the tree. If the properties you have open list alarms and classes and offer no history option, you are looking at the configuration. Gate: enable the option, close the dialog, reopen it, and confirm the option still reads enabled. Then rebuild and download. A table that still overwrites rows at runtime is running the previously downloaded project, so repeat the check against the target, not the offline editor.
How do you freeze the reset text in the record?
Run the table historic: the record gains its reset text when the reset bit rises, keeps that text after the bit drops, and the next rising edge of the set variable starts a fresh record without it. No latch variable is needed for this.
The mechanism is the same one behind the record count. In a non-historic table the text belongs to the one live row, so it follows the current state of the reset bit and looks like it vanishes. In a historic table every transition is a stored record, so the text stays with the record it was written into. Test: raise set, raise reset, drop reset, raise set again. Pass: the first record keeps its reset text, and the second record appears without it.
Why does the alarm class background color have no effect?
The visualization style controls rendering: font settings from the alarm class apply to messages as configured, but the class background draws only after the style changes. Change the style in the Visualization Manager, then rebuild and download.
Do it in this order:
- Set the background color in the alarm class configuration.
- Open the Visualization Manager and change the style setting.
- Rebuild, download, and open the alarm table screen.
- Raise an alarm of that class.
Gate: the row background shows the class color. If only the font changes, the old style is still on the target; repeat the style change and confirm the download finished before you touch the class colors again.
Why does the string value print TRUE in the historic table?
The stored record substitutes a BOOL value for the %s placeholder on this version, so every change of the string variable appends a record that reads TRUE; the non-historic table shows the string because its live row still substitutes correctly.
The configuration under discussion is an alarm message containing <currentvalue %s>, observation type Change, and the string variable in the details field. One record per change proves the trigger side works, so only the substituted value is wrong. The TRUE is the value of a BOOL, and the BOOL that drives the table is the trigger: the stored record substitutes the trigger where the live row substitutes the string. Run two checks in order.
- The details field holds the string variable itself, not a BOOL flag and not a comparison expression.
- The variable type matches the visualization text mode: STRING with a non-Unicode visualization, WSTRING with a Unicode visualization. The Unicode setting sits in the Visualization Manager. A mismatch gives blank or garbled text, which is a different failure from a clean TRUE.
If TRUE survives both checks, stop tuning the placeholder and log the string by a second path: keep a historic alarm on a BOOL pulse for the event count, and carry the string either on a non-historic table showing the live value or in application-side logging into an array or file you control. For the wording stored in the event message itself, operator text in HMI alarms covers the text configuration. If the string is mainly for people to read at a glance on the floor, factory status display or operator HMI covers where that value belongs, and a persistent HMI layout for changing screens keeps the second table stable when screens change.
Could the simulation be hiding a working substitution?
Run the string check on the downloaded controller, not only in simulation: a substitution that fails on both STRING and WSTRING, with Unicode on and off in the Visualization Manager, has exhausted the configuration, and one download settles where the fault lives.
Those four combinations cover every setting the substitution depends on, so a failure across all four points at the runtime, and simulation is a runtime of its own. Gate: download the project unchanged and repeat the string check. If the text appears on the target, the configuration was right all along and you keep it. If TRUE still appears on the target, it is the version behavior and you use the second path from the previous section.
How does a worked example on a filler line verify everything?
Two rising edges and one string change must produce three records: 2 + 1 = 3. The same run also checks the frozen reset text, the class color, and whether each record carries its own batch code or the word TRUE.
Variables: set (BOOL, cycle start), reset (BOOL, quality hold), batch_code (STRING, observation type Change, named in the details field).
- 06:10,
setFALSE to TRUE. Record 1 appears with the code in force, B-1140. - 06:12,
resetTRUE for 2 s, then FALSE. Record 1 gains the reset text and keeps it. No new record comes from the reset bit. - 06:15,
batch_codechanges from B-1140 to B-1141. Record 2 appears. - 06:20,
setrises again. Record 3 appears.
Arithmetic: 2 edges + 1 string change = 3 records. The same sequence on a non-historic table shows 1 row, which is the pass signal for the mode fix and the failure you started from. Gates for the run:
- 3 records counted, and 3 = 2 + 1.
- Only record 1 carries the reset text.
- Record 1 reads B-1140 and records 2 and 3 read B-1141. Any record that reads TRUE fails the placeholder: apply the two checks, confirm on the controller, then the second path.
- An alarm of the configured class raised during the run shows the class background on its row.
Recommendation: Enable Historic on the alarm table object and change the style in the Visualization Manager; those two settings fix the record count, the frozen reset text and the class colors on any project. For the string value on V3.5 SP8 Patch2, run the two checks on the details field and the string type, confirm on the downloaded controller, and if the record still reads TRUE, keep the BOOL pulse alarm for the event history and log the string from the application.
Questions
How many records should a test sequence produce?
Add the transitions you want logged: every rising edge of the set variable and every observed change of the string variable each append one record. A run with 4 edges and 3 string changes yields 7 records. Fewer rows after the download means the target is still running the non-historic table.
Can one alarm configuration feed a live table and a history table?
Yes. The Historic option belongs to each alarm table object, so add a second table for the same configuration, leave that one non-historic, and place it where the current state matters. That split is also the practical home for the live string value while the historic table keeps the event count.
Is the TRUE-instead-of-string behavior fixed in a later version?
That is unknown from the material here. Treat it as the behavior of V3.5 SP8 Patch2: apply the placeholder checks as written, confirm on the downloaded controller, and if the record still reads TRUE, keep the BOOL event history and log the string from the application.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.