cliu/ci-server-engineer
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
ci-server-engineer/knowledge/manuals/IM36K10L40-01EN.md
cliu f24e617a70 Add phase 5 equipment and ITEM Service summaries 
- Summaries of IM 36K10L40 (EQUIPMENT utilities), L41 (EQUIPMENT
  configuration: lines, stations, conversion types, Modbus master/slave,
  driver table), L35 (ITH) and L36 (ITM), checked against the installed
  start scripts, setup files and datasets
- tuning-checks: read-only itmdbg / eqpdbg via piped answers
- New ISS-021 (STATION_STAT empty), ISS-022 (itmval -f crashes),
  ISS-023 (install differs from ITEM manuals, closed); ISS-006 updated

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-30 17:15:14 +10:00

4.8 KiB
Raw Blame History

manual title edition version status
IM 36K10L40-01EN EQUIPMENT Service Engineering - Utilities 3rd Edition, Sep. 2023 R1.03 from docs; installed programs, setup file and start scripts checked, eqpdbg "Get main info" run read-only on the test system (2026-09-30)

EQUIPMENT Service Engineering - Utilities (R1.03)

Three utilities of the EQUIPMENT Service (the equipment managers eqp<type> that talk to stations). Section numbers refer to the manual.

1. Forced scan: eqpfrcscn (§1)

Temporarily scans a group of points faster when a trigger item changes, e.g. a tuning tag normally read hourly.

  1. Create %TLS_ROOT_PATH%\tls\com\eqpfrcscn_start.cmd that starts %TLS_ROOT_PATH%\tls\exe\eqpfrcscn -n EQPFRCSCN, and eqpfrcscn_stop.cmd that stops it with durstp.exe -msk -t 10 -p EQPFRCSCN. (The manual's example start line uses -n eqpfrcsrn, a typo.) On the test system equipment_start.cmd calls every eqp*start.cmd in tls\com, so the start file makes it start with CI Server.
  2. Define the trigger item; any value change starts a forced scan.
  3. Give the points to be forced a scan type (e.g. 60000 ms) and link them to items.
  4. In eqpfrcscn.sup (Setup File Editor; description "Force scanning equipment"):
    • Tab General, keyword FORCE = <trigger item>, <EQP node>, <EQP process name>, <slave number>, <I/O type number>, <scan rate number>, <scan period s>, <scan duration s> (repeatable), plus queue_size (KB, default 20).
    • Tab Special events, keyword FCX_EVENT = <trigger item>, <node>, <process>, <slave>, <period>, <duration> for STARDOM, DNP3 and IEC101 events.
    • EQP process name = Equipment process name of the line; slave number = Internal station id (or eqpdbg "Get slave info").
    • I/O type numbers include 100/101/103/104/106 Modbus (Modicon) reads, 293 Siemens 3964R, 580 BK8100, 644 STARDOM FCX (-1 slow, -2 fast, -3 medium), 772/774 ProSafe-COM, 836 FA-M3, 996 AB PLC5, 1028 DNP3, 1092 Siemens S7, 1156 DAQSTATION, 1188 AB CIP, 1220 Fisher ROC, 1316 HexRepeater, 1636 IEC 61850.
    • Scan rate number: the points' scan interval in ms, or the driver's internal rate number.
  5. Restart CI Server (or the EQPFRCSCN process). Example: a change of the trigger item makes 60 s points scan every 10 s for 600 s. Long scan intervals can let an RTU close its TCP socket; keep at least one faster item or lengthen the RTU's socket timeout.

2. Hourly I/O statistics: eqpiostat (§2)

Stores the I/O statistics per station line every hour (no record when nothing was sent). No setup file, no parameters. On the test system equipment_start.cmd starts it automatically on the host node, and it was running. The manual calls the target a history group; it is the dataset STATION_STAT (fields: time stamp, station, line, time span, sends, good answers, bad return code, timeouts, frame errors, bad CRC, retries, line bad). An export returned no records on the test system (ISS-021).

3. Debugger: eqpdbg (§3)

eqpdbg [<node> <process>] then an action number; node 0 = this node, process default EQP (use the line's equipment process name, e.g. EQPMDC for Modbus). Answers can be piped in, e.g. read-only main info:

printf '1\n-1\n' | eqpdbg 0 EQPMDC
No. Action Changes anything?
1 Get main info: lines attached, scan interval (tick), scan status, slave count, scans done, line load % no
3 Get slave info: type, name, wanted path, scan status, recover count, scan preset, output method, address gap / max size, per-line status items and message statistics no
8, 9, 10, 11, 13, 17, 18, 23 I/O type, scan rate, item pointer, timing statistics, item, item by id, slave-specific, item ids no
4, 5 Update slave scan status / address gap and max size yes, makes EQP differ from the database
6, 12 Delete slave / item signal (EQP only; repair with dsschk) yes
7 Reset statistics (optionally enable I/O timing) yes (counters)
14 Save all info on disk (optionally stop the EQP process) yes
15, 16, 20, 21 Total scan, force item update, force re-init, general request triggers I/O
19 Logging file size (MB, 0 = off): <process>.xml / _old.xml in the list folder yes
-2 Dump memory (a wrong address crashes EQP) risky
-1 Exit —

Test system: eqpdbg 0 EQPMDC main info showed line type 107, both lines attached, 100 ms scan interval, 2 slaves, 2 % line load.

Installed on the test system

Many drivers tls\exe\eqp<type>.exe (e.g. eqpmdc Modbus, eqpfcx STARDOM, eqpfam3 FA-M3, eqp850 IEC 61850, eqpdnp DNP3); setup files eqp*.sup (e.g. eqpmdc.sup, eqpmqtt.sup, eqpfrcscn.sup); start scripts eqpmdc_start.cmd, eqpmqtt_start.cmd. Running managers: eqpmdc, eqpmqtt, eqpiostat.