Fix HMI batch report logging duplicates and tag order

What each symptom points to

Each fault leaves a different trace in the file. Match your report against these:

• The batch prints twice, zeros first, final weights second. Two capture events fired for one batch. In the example below, the 22:36:21 and 22:37:49 records of batch #9 sit 88 seconds apart, and the second is the good one. Find which event started the first capture.
• One record mixes filled and zero values. The capture ran while the tags were still updating. Move the capture to after the last tag settles.
• Fields read correctly for the first two entries and reversed after that. The substitution order in the message text is wrong. Trace the fields one at a time; the storage card is not involved.
• Messages with a one-year shelf life never delete. The shelf-life rule and the exported file live in different stores. Verify what the setting names before expecting deletions.

Trigger once, after the batch is complete

A message object writes a snapshot of its tags at the moment its event fires. If that event can fire during weighing and again at completion, the file receives both states, which is exactly what the two batch #9 records show. The repair is one firing per batch, at a point where every tag holds its final value.

First find the event each object uses. Panel software documents the routes you have to choose from: a log action can be bound to the tag itself under the tag's event properties, so the write fires on the tag's transition, or an event manager can watch conditions continuously and run an action when a condition is met. A batch-complete condition belongs in the second kind; check which one your project uses before touching anything.

Then make the firing one-shot. A condition that stays true is evaluated again on every scan, so a level trigger re-fires until the condition drops; an edge trigger fires once on the transition. Use the transition and confirm afterwards that the trigger returned inactive. The example report gives one more clue: every line in each record carries the same write time, so all the objects fired together from one shared event. There is one trigger to correct, not seven.

Trace the tag order field by field

The report's first two fields came out right and the rest arrived reversed. Treat that as a mapping problem in the message text until every field is traced. These message objects, often set up as look-up text objects with one message and two tags each, print each tag into a slot in the message string; a slot and a tag drift apart when messages are copied and edited.

Take one message whose output is wrong. Write down the intended order: label, desired amount, actual amount. Open the message text, compare each substitution slot with the tag assigned to it, and each tag with its position on the line. Compare against a message that prints correctly and note where the reversal starts, at a consistent field or at the boundary between objects. Correct that one message only.

Reconcile the object count with the printed layout before any bulk edit: seven objects produced seven lines, a header, a formula line and five item lines. Count yours the same way.

Verify with a pattern that cannot hide a swap: put a different value in every tag, 1.00, 2.00, 3.00, 4.00 and 5.00 in the five desired tags and 6.00, 7.00, 8.00, 9.00 and 10.00 in the five actual tags, print once, and read each value back to its slot. A pair that lands in the wrong order now shows as a value in the wrong position. The readable text file is the point of this method; logging ASCII text on an HMI panel covers the storage side when your values are strings.

Example: two snapshots of batch #9, 88 seconds apart

The inputs come from the report file itself:

• Write times: 22:36:21 and 22:37:49 on 24/03/2009, both records labeled Formula #6, TST ALL COLORS, Batch #9.
• Desired values, items 1 to 5: 1.00, 1.34, 2.00, 3.00, 3.04, identical in both records.
• Actual values in the first record: 0.00 on all five items.
• Actual values in the second record: 0.99, 1.35, 2.00, 2.97 and 3.00.

The rule: each line is a snapshot of the tags at its write time. Two records of one batch are two events, and the gap between write times plus the movement in actual values says what each event caught.

The arithmetic: 22:37:49 − 22:36:21 = 88 seconds. From 22:36:21 to 22:37:00 is 39 seconds; from 22:37:00 to 22:37:49 is another 49; 39 + 49 = 88.

The result: batch #9 was logged twice in 88 seconds. The 22:36:21 write caught the batch before weighing finished, all five actuals still 0.00 while the desired values already stood at 1.00 to 3.04. The 22:37:49 write caught the completed batch, actuals 0.99 to 3.00.

The decision: a duplicate pair whose first record holds zeros in tags that carry final weights 88 seconds later is a timing fault. Remove the mid-batch event and keep the batch-complete capture; the second record is the good one. If both records carry final weights, two completion events fired and you hunt the shared trigger. If the later record still holds zeros while the live tags read final values, the capture reads the wrong tag or fires before the weigher writes its result; correct the tag reference.

Shelf life and the exported file are different stores

The one-year expectation is a retention rule, and it did not delete the records. Before changing anything, identify what the setting governs: message history, an alarm or event log, or files on the storage card (CF1 in this report). Each store keeps its own retention rule, so a shelf life set on one store stops there. Retention settings are scoped narrowly even within one panel: a small terminal's alarm history, for example, is documented as holding up to 100 entries with an initial default of 50 and a clear-or-retain choice at restart, and none of that governs a text file you exported.

Check three things in your configuration: which log the shelf-life setting names, what its units are, and the ages and locations of the files on CF1. If no retention rule covers the exported text files, run an explicit archive routine approved for the application: keep the current report, move closed batch files to a dated folder, and delete on a schedule the customer signs off. How much history a panel can hold in which store is its own question; what an HMI panel can store for later retrieval sets out the options, and why an alarm history downloads only if logging was on shows what happens when logging was never switched on.

Copy the current report to a PC before changing retention or deleting anything. The file is the only copy of the batches it holds.

Prove the fix on one test batch

1. Back up the HMI project and copy the current report file to a PC.
2. Run a test batch and watch the desired and actual tags. Note when each tag reaches its final value and when the batch is complete.
3. Move the capture to a single batch-complete event, triggered on the transition, and confirm the trigger returns inactive so it cannot fire a second time for the same batch.
4. Correct one reversed message at a time and print with the distinct-value pattern from the tag order section.
5. Capture one batch and read the new record line by line: every label in place, every desired and actual value matching the live tags at capture time.
6. Run a second batch. The first clean record proves the event; the second proves it repeats.
7. Verify retention separately, with a test file on a maintenance day, keeping the production report untouched until the customer accepts the new output.

Recommendation: keep the message-object report and repair it in this order: first the trigger, one edge event on batch complete after the last tag settles; second the tag order, message by message, verified with a different value in every tag; third retention, treated as a message-history setting with your own dated archive routine for the files. Change one of the three per test batch, because a batch that passes with all three changed at once cannot show which fix worked. For a report the customer reads as text, this configuration is the whole repair: no new hardware, no rebuild.

Questions