cliu
c619ca9e5f
Summarize the CI Server Tutorial and practice its command-line equivalents on CI-Eng-Sample: sub-items, blocking, a trigger group, a compiled class and an object. Log ISS-010/011. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
91 lines
4.6 KiB
Markdown
91 lines
4.6 KiB
Markdown
# CI-Eng-Sample
|
||
|
||
A small, invented sample project that anyone with this repo can load into a CI Server
|
||
**R1.03** test system. Skills use its names in their examples, and every skill task is
|
||
re-tested against it so that no other project is needed.
|
||
|
||
Built and tested on CI Server R1.03.00 (unlicensed test system), 2026-09-30.
|
||
|
||
## Load and remove
|
||
|
||
Test systems only: loading writes to the CI Server database. CI Server must be running.
|
||
From an elevated prompt, call the scripts by full path (a bare `load.cmd` may not be found
|
||
from the current folder):
|
||
|
||
```
|
||
cmd /c "<repo>\examples\CI-Eng-Sample\load.cmd"
|
||
cmd /c "<repo>\examples\CI-Eng-Sample\remove.cmd"
|
||
```
|
||
|
||
- Each step prints a summary and writes a `.qlo` listing; check that `Errors` is 0.
|
||
- **Restart CI Server after loading** (stop, then start the CI Service): a new storage group
|
||
stores no history until CI Server restarts.
|
||
- `load.cmd` on a system that already has the project reports `Exists` and changes nothing.
|
||
- `remove.cmd` takes about 1½ minutes: a storage group can only be deleted after its stop time
|
||
has passed, so the script sets a stop time one minute ahead and waits. Removing the group
|
||
also deletes its history.
|
||
|
||
## Current contents
|
||
|
||
| Name | Kind | Details |
|
||
|---|---|---|
|
||
| `CI-Eng-Sample` | Section | Top level |
|
||
| `CI-Eng-Sample.TANK1`, `.PUMP1`, `.SYSTEM` | Sections | Tank, pump, system monitoring |
|
||
| `CI-Eng-Sample.TANK1.LEVEL` | Item, Real | %, format `999.9`, limits LL 10 / L 20 / H 80 / HH 90, scale 0–100 (alarming off), stored in `CIENG_EVENT` |
|
||
| `CI-Eng-Sample.TANK1.INFLOW` | Item, Real | m3/h, format `9999.9`, scale 0–500, stored in `CIENG_EVENT` |
|
||
| `CI-Eng-Sample.PUMP1.RUNNING` | Item, Boolean | |
|
||
| `CI-Eng-Sample.PUMP1.MODE` | Item, Integer | 0 manual, 1 auto |
|
||
| `CI-Eng-Sample.SYSTEM.CPU_LOAD` | Item, Real | Target for `intcpumon` |
|
||
| `CI-Eng-Sample.SYSTEM.DISK_C` | Item, Real | Target for `intdskmon` (reports **used** %) |
|
||
| `CI-Eng-Sample.SYSTEM.PING_LOCALHOST` | Item, Integer | Target for `inttcpmon` (1 = reachable) |
|
||
| `CI-Eng-Sample.SYSTEM.PROC_ALM` | Item, Integer | Target for `intmon` (1 = `alm` process running) |
|
||
| `CI-Eng-Sample.PUMP1.RUNNING.RUN_SECONDS` | Sub-item, Integrator | Running time in seconds (adds value × seconds) |
|
||
| `CI-Eng-Sample.TANK1.LEVEL.MAX` | Sub-item, Min-Max | Highest level seen |
|
||
| `CI-Eng-Sample.DEMO` | Section | Tutorial examples |
|
||
| `CI-Eng-Sample.DEMO.COUNTER` | Item, Integer | Counts 1…100, one step per second, written by `DEMO.INCR1` |
|
||
| `CIENG_1S` | Trigger group | Every second |
|
||
| `CIENG_INCR` | Class (traditional) | Increments `DEMO.COUNTER`, wraps at 100; compiled on load |
|
||
| `CI-Eng-Sample.DEMO.INCR1` | Object | Instance of `CIENG_INCR` |
|
||
| `CIENG_EVENT` | Item storage group | Event/Item, lifetime 1 week, rollover 1 day |
|
||
|
||
All items are internal (no station), so the project works without any PLC or simulator.
|
||
New items start with status 13 (`NOT INIT`) until a value is written.
|
||
|
||
## Files
|
||
|
||
| File | Purpose |
|
||
|---|---|
|
||
| `01_section_df.qli` | Sections (`SECTION_DF`); parents before children |
|
||
| `02_item_df.qli` | Items (`ITEM_DF`) |
|
||
| `02b_sub_item_df.qli` | Sub-items (`SUB_ITEM_DF`) |
|
||
| `03_his_group_df.qli` | Item storage group (`HIS_GROUP_DF`) |
|
||
| `04_item_his_df.qli` | Items in the storage group (`ITEM_HIS_DF`, name `<group>:<item>`) |
|
||
| `05_trigger_df.qli`, `06_class_df.qli`, `07_object_df.qli` | Trigger group, class (source in the `METHOD` memo, `@"` … `"@`, `COMPILE` 1), object |
|
||
| `86_`…`92_remove_*.qli` | Names to delete, in reverse order |
|
||
| `load.cmd`, `remove.cmd` | Run the steps in the right order |
|
||
| `monitoring/*.sup.txt` | Setup-file lines for the monitoring processes (not applied by `load.cmd`) |
|
||
|
||
## Monitoring processes (optional)
|
||
|
||
`monitoring/` holds the lines to add to the setup files in `%TLS_ROOT_PATH%\tls\sup\` so that
|
||
`intcpumon`, `intdskmon`, `inttcpmon`, `intmon` and `intspawn` write into the `SYSTEM` items.
|
||
These change the system's own setup files: back the files up first and restore them after
|
||
testing. See the `system-management` skill, task `monitoring-processes.md`.
|
||
|
||
## Planned additions
|
||
|
||
| Phase | Adds |
|
||
|---|---|
|
||
| 6 | Template items, a class with attributes/prompts, objects that create items |
|
||
| 8 | Alarm settings on sample items |
|
||
| 9 | More storage groups (scan/time, aggregation) |
|
||
| 10 | A display and symbol |
|
||
| 11 | A report |
|
||
|
||
## Rules
|
||
|
||
- Test systems only; invented names only, no real plant or customer data.
|
||
- Keep the load order: sections → template items → classes (compiled) → objects → other
|
||
items → storage groups → items in storage groups (IM 36K10J10 §5.6). Keep `remove.cmd` in
|
||
reverse order.
|
||
- Every file notes the CI Server version it was built and tested on.
|