Fix stale itemId in CIENG_Tank (ISS-052); record HTML trend attempts (ISS-041)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
parent
304745cff2
commit
5849f4e30f
4 changed files with 10 additions and 6 deletions
|
|
@ -38,9 +38,12 @@ grep -n "<html>\|<width>\|<height>\|itemName\|itemId\|<source" <DisplayName>.xml
|
|||
- `<html>true</html>` = HTML mode; `<width>`/`<height>` must be set for the HTML display.
|
||||
- Item connections: `<itemName>` + `<itemId>` (node.group.number…); trend pens:
|
||||
`<source type="sourceID" uri="ci:/item/<item>"/>` (`uri=""` = empty pen).
|
||||
- The name is what counts: after the item was deleted and loaded again (new id) the display
|
||||
still validated and a new session showed live values; already-open sessions kept showing the
|
||||
old value until reopened.
|
||||
- After the item is deleted and loaded again it gets a **new id**; the display still validates,
|
||||
but on 2026-10-01 the HTML display showed **0** and the popup `ITM-E-NO_MAIN, No main item
|
||||
found` for a number field whose stored `<itemId>` was stale, also in a fresh session. Deleting
|
||||
the `<itemId>` line (keeping `<itemName>`) and redeploying fixed it: the field binds by name.
|
||||
Sample displays therefore carry no `<itemId>`; for displays made in the Edit Module, reconnect
|
||||
or remove the ids after reloading items (ISS-052).
|
||||
|
||||
## Verified (CIENG_Tank, 2026-10-01)
|
||||
|
||||
|
|
|
|||
|
|
@ -53,5 +53,6 @@ session** and needs a new login. Check live values by writing a test value (`itm
|
|||
## Verified (2026-10-01)
|
||||
|
||||
Remove → deploy recreated both files; `-e HTML` output identical to the Edit Module's HTML;
|
||||
validation of `CIENG_Tank` *No problems found* (also after a sample reload with new item ids);
|
||||
validation of `CIENG_Tank` *No problems found* (also after a sample reload with new item ids —
|
||||
but a stale `<itemId>` then shows 0 at run time, ISS-052);
|
||||
search worked; browser showed live values. HTML trend without line: ISS-041.
|
||||
|
|
|
|||
|
|
@ -95,7 +95,6 @@
|
|||
</filter>
|
||||
<connection type="connection">
|
||||
<itemName>CI-Eng-Sample.TANK1.LEVEL</itemName>
|
||||
<itemId>1.1.268.0.0.1.1.7</itemId>
|
||||
<itemAttribute>ItemValue</itemAttribute>
|
||||
</connection>
|
||||
</action>
|
||||
|
|
|
|||
|
|
@ -60,7 +60,7 @@ development system (see "Test system" in `progress.md`); they do not exist on ot
|
|||
| ISS-038 | 2026-10-01 | HISTORY (`ithloahis` + rollover) | An `ithloahis` sample that was dropped (dated 11:50, before the active unit) still became the **initial value** of the next unit: after a forced rollover at 12:05:26 `ITEM_HISTORY` shows `CI-Eng-Sample.TANK1.INFLOW` = 95 (`INITIAL_VALUE` 1) although the item's value was 112. History after loading old samples can therefore show a wrong value at the next rollover. | open | Retested 2026-10-01 after a CI Server restart (first unit 18:05:46). (a) Sample dated one day earlier (95), live value 112, forced rollover: initial value 112 — correct. (b) Sample dated 18:00 (96, a few minutes before the first unit), live value 113, forced rollover: initial value **96** — wrong again; the live item value stayed 113. So a dropped sample dated shortly before the first unit (same day) becomes the next unit's initial value; a much older one did not. Also found: a forced rollover within 2 minutes of the previous one is refused (`DSI-E-ROLLDONE`). Documented as a caution; behaviour confirmed, ready to close. | `.claude/skills/system-management/tasks/load-history.md`; `knowledge/manuals/IM36K10C40-01EN.md` §3 |
|
||||
| ISS-039 | 2026-10-01 | HISTORY (setup) | Installed vs manuals: `hisdbg` menu runs to option 22 (manual text: `-1 - 10`, list to 22) and lists history types 4 (`STATION_STAT`) and 36 (`SYS_LOG`) not in IM 36K10L20 §3.1; `ithsag.sup` keyword `run_interval` (manual: *Heartbeat*) and `queue_size` 500 KB (manual default 200); the option-type table in IM 36K10L20 §3.1 is garbled in the PDF (observed: Scan/Time `1 1`, Event/Item `2 2`, Aggregation `4 4`). | closed | Installed software is the reference (standing user decision). Close when the user confirms. Closed 2026-10-01 (confirmed by user). | `knowledge/manuals/IM36K10L20-01EN.md` §3; `knowledge/manuals/IM36K10C40-01EN.md` §2 |
|
||||
| ISS-040 | 2026-10-01 | HISTORY (aggregation) | Aggregation group `CIENG_AGG` (30 min + hour, `TANK1.LEVEL` max/min/avg) ran (`ithsag.log`: *Aggregation Completed*) but stored no values: retrieval gave `0x09 = ITM error` per period. `TANK1.LEVEL` was in `CIENG_EVENT` and `CIENG_SCAN10S`, both priority 0. Also `INTERPOLATION = "30 minutes"` is refused by `dssqld`; the installed name is `30Minutes`. | closed | Closed 2026-10-01 (confirmed by user). 2026-10-01 14:02: after `CIENG_SCAN10S` got `PRIORITY` 10, the 13:30–14:00 period stored max 77, min 33, avg 52.7, quality 1000 (`ithdbg` 20 and `dssqld` with `INTERPOLATION = "30Minutes"`). Cause: equal source priorities (C40 §2.1 says the highest-priority group is the source, but not that a tie gives nothing). Sample fixed (priority 10). The hourly value for 13:00–14:00 was not stored (first half had no source); not rechecked. Proposed close. | `.claude/skills/history-management/tasks/storage-groups.md` §4 (done); `knowledge/manuals/IM36K10C40-01EN.md` §3 (done); `examples/CI-Eng-Sample/03_his_group_df.qli`, `README.md` (done) |
|
||||
| ISS-041 | 2026-10-01 | GRAPHICS (HTML trend) | In the HTML display (`localhost:8080/mobileoperator/?d=CIENG_Tank`) the trend shows the pen legend `CI-Eng-Sample.TANK1.LEVEL [CIENG_SCAN10S]` and time axis but draws no line, although `ITEM_HISTORY` has 420 samples in the shown hour. Browser console: `Mismatch between number of labels (Time,CI-Eng-Sample.TANK1.LEVEL [CIENG_SCAN10S]) and number of columns in array (51)`. The trend has 4 further empty pens. 2026-10-01 later: the trend also had the property `chart.attribute[00]` connected to `TANK1.LEVEL` (added by mistake with the pen); the Operator Interface (desktop) showed *Short attribute name ( 61.0) is invalid*. After removing it the desktop trend draws the line, but the HTML trend still logs the mismatch error. | open | HTML only: try a trend with one pen (remove the empty ones) or a Micro Trend; check the HTML-supported trend properties (IM 36K10R30 §4.8.7); check whether the browser still uses a cached copy (`MO_CACHE_DISPLAYS` in `jwuiisg.sup`). | `.claude/skills/graphics/tasks/create-display.md`; `knowledge/manuals/IM36K10R30-01EN.md` §4 |
|
||||
| ISS-041 | 2026-10-01 | GRAPHICS (HTML trend) | In the HTML display (`localhost:8080/mobileoperator/?d=CIENG_Tank`) the trend shows the pen legend `CI-Eng-Sample.TANK1.LEVEL [CIENG_SCAN10S]` and time axis but draws no line, although `ITEM_HISTORY` has 420 samples in the shown hour. Browser console: `Mismatch between number of labels (Time,CI-Eng-Sample.TANK1.LEVEL [CIENG_SCAN10S]) and number of columns in array (51)`. The trend has 4 further empty pens. 2026-10-01 later: the trend also had the property `chart.attribute[00]` connected to `TANK1.LEVEL` (added by mistake with the pen); the Operator Interface (desktop) showed *Short attribute name ( 61.0) is invalid*. After removing it the desktop trend draws the line, but the HTML trend still logs the mismatch error. | open | Tried 2026-10-01 (fresh session after a restart, 283 history samples in the hour): removing the 4 empty pens, and `updating` true / `updateInterval` 10 like the factory `AOG_TrendOpen` — the mismatch error and the empty trend stayed in both cases (changes reverted). Still to try: a Micro Trend, the HTML-supported trend properties (IM 36K10R30 §4.8.7), clearing the browser/`MO_CACHE_DISPLAYS` cache (the console shows `CIENG_Tank.xml` *loaded (from cache)*), and adding the pen to the factory *Open Trend* display in the HTML client. | `.claude/skills/graphics/tasks/create-display.md`; `knowledge/manuals/IM36K10R30-01EN.md` §4 |
|
||||
| ISS-042 | 2026-10-01 | GRAPHICS (layouts) | Installed vs `Layouts.readme`: the factory layouts use status line item types `displayName`, `playbackIndicator` and `dateTime` and the commands `reload <frame>` / `reload all`, none of which the readme lists (readme: `statusText`, `userName`, `progresBar`, `graphicsQueueLevel`, `connectionState`); the readme also writes `zooom` for the zoom command (factory files use `zoom`). | closed | Installed software is the reference (standing user decision). Close when the user confirms. Closed 2026-10-01 (confirmed by user). | `.claude/skills/graphics/tasks/layouts.md` §2 |
|
||||
| ISS-043 | 2026-10-01 | REPORT (system reports) | IM 36K10C30 App. 1.3 names two system reports `ALM_ATTS_CUR` and `ALM_ATRS_HIS`; the installed reports are `ALM_ATTRS_CUR` and `ALM_ATTRS_HIS`. The other 26 names match. | closed | Installed software is the reference (standing user decision). Close when the user confirms. Closed 2026-10-01 (confirmed by user). | `knowledge/manuals/IM36K10C30-01EN.md` §8 (done) |
|
||||
| ISS-044 | 2026-10-01 | REPORT (scheduling) | Behaviour not in the manuals, found by quick load: a generation interval below 10 minutes is refused (`HIS-E-ROLLTOFAST`, the interval is the rollover of the report's storage group); a scheduled report cannot be deleted (`RPT-E-ACTIVE`) until `ACTIVATION_TIME` and `GENERATION_INTERVAL` are cleared; `CORRECT_DAYLIGHT` 0 counts intervals in UTC (06:00 set for January ran at 05:00 in October); a past activation time moves to the next slot - once (modify, past time within the lifetime) a single report labelled with the old time was generated, at insert with an older time none. | closed | Documented as verified behaviour; the one-off generation for a past activation time is not fully understood. Close when the user confirms. Closed 2026-10-01 (confirmed by user). | `.claude/skills/reporting/tasks/define-reports.md` §1, §5, §6; `knowledge/manuals/IM36K10C30-01EN.md` §2; `examples/CI-Eng-Sample/83a_stop_report_df.qli`, `18_report_df.qli` |
|
||||
|
|
@ -71,3 +71,4 @@ development system (see "Test system" in `progress.md`); they do not exist on ot
|
|||
| ISS-049 | 2026-10-01 | AUDIT (item option *Audit trailing wanted*) | IM 36K10G10 ch. 9 and the classifier list (IM 36K10L25 App. 1, `ITEM.VALUE.MODIFY.<source>`, `ITEM.HIGH-LIMIT…`) suggest item changes are audited per item when `AUDIT_INFO` = 1. On R1.03.00 none of the tested tools produced an `ITEM.*` event: `itmval -p` writes are not audited at all (with `AUDIT_INFO` 0 or 1); value writes through DSS (`dssqld -m ITEM_VAL`) and Engineering Module *Update value* are audited as dataset events (`ITEM_VAL`, `ITEM_VALUE` / `ITEM_VALUE_STR` / `STATUS`) for every item regardless of `AUDIT_INFO`. Operator-display writes and PROCESS writes (`opc.sup` `AUDIT = YES`, `COMPUTE` classifiers off by default) were not tested (no input field in the sample displays). | open | Test an operator value input on an item with `AUDIT_INFO` 1 (needs a display with an input field) and, if wanted, PROCESS with `AUDIT = YES`. | `.claude/skills/audit-trail/tasks/configure-audit.md` §1; `.claude/skills/audit-trail/tasks/read-audit-trail.md` §2; `knowledge/manuals/IM36K10L25-01EN.md` §3 |
|
||||
| ISS-050 | 2026-10-01 | AUDIT (classifier `STORAGE`) | Setting `AUDIT_EVENT_CLAS_DF.STORAGE` = 0 for `DATASET.NULL-ATTR.MODIFY.ENT-ENG-MOD` at 17:01:12 did not stop the next `dssqld -m ITEM_VAL` change from being stored (17:01:12.573). IM 36K10L25 §3.2 explains a per-process cache refreshed every `ECL_REFRESH` s (default 1800); the notifier here is `DSSSDA`, so the change should apply within 30 minutes. | closed | Re-tested: at 17:32:18 (after the 30-minute refresh) the same change was **not** stored, so the flag works with a delay. Set back to 1 at 17:32; the next change was still not stored (the cache works in both directions). Documented: allow up to `ECL_REFRESH` (1800 s) or restart CI Server. Close when the user confirms. Closed 2026-10-01 (confirmed by user). | `.claude/skills/audit-trail/tasks/configure-audit.md` §1; `knowledge/manuals/IM36K10L25-01EN.md` §3 |
|
||||
| ISS-051 | 2026-10-01 | AUDIT (manual vs installed) | Differences between IM 36K10L25 and R1.03.00: (1) App. 1 lists subject `F/T-SYSTEM`, the installed classifiers use `CI-SERVER` (logins) and also `EAL OPERATION` (subject and action) and source `VIA-OPC-UAS`, not in the manual; 463 classifiers installed. (2) App. 1 explanations of `SHELVE` and `UN-SHELVE` are swapped. (3) `QUESIZE`: manual default and maximum 200 kB, `adtsys.sup` help default 10 kB, minimum 10 (file sets 200). (4) `TIMEFMT` default: manual `DD/MM/YY hh:mm:ss.ppp`, `adtsys.sup` help without `.ppp`; `ADTLOG` output shows milliseconds (manual right). (5) `dssqld` changes are recorded with source `ENT-ENG-MOD`, not `QUICKLOAD`. (6) The selection expression language is not described in the manual; the compiler listing gives the words and operators (no `LIKE`). (7) `ADT` group lifetime 52 weeks on the test system vs 2 days default when `ADTSTO` creates it (§2.1.1). | closed | Documented in the L25 summary and the `audit-trail` skill. Close when the user confirms. Closed 2026-10-01 (confirmed by user). | `knowledge/manuals/IM36K10L25-01EN.md`; `.claude/skills/audit-trail/tasks/*.md` |
|
||||
| ISS-052 | 2026-10-01 | GRAPHICS (stale item id) | The HTML display `CIENG_Tank` showed **0** in its number field on `CI-Eng-Sample.TANK1.LEVEL` (live value 50) and the popup `ITM-E-NO_MAIN, No main item found`, in a fresh session after a CI Server restart. The display XML stores `<itemName>` **and** `<itemId>1.1.268.0.0.1.1.7</itemId>` from when it was built; after today's sample reloads the item has `ID_NUMBER` 357. Phase 10 had seen live values after a reload, so the id is not always used, but here it broke the field. | open | Fixed in the sample: removed the `<itemId>` line from `displays/CIENG_Tank.xml`, redeployed; the field shows 50 and the popup is gone (binding by name). Documented in `create-display.md`. Close when the user confirms. | `examples/CI-Eng-Sample/displays/CIENG_Tank.xml`; `.claude/skills/graphics/tasks/create-display.md`; `.claude/skills/graphics/tasks/deploy-displays.md` |
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue