
Conveyor Sorting
OpenPLC и Ignition: ladder-логика, Structured Text state machine, обратная связь датчиков и проверяемые циклы.
Этот кейс не про отдельный экран. Я собрал путь данных одного насоса: команды и feedback в OPC UA, модель процесса в Gateway, снимки в SQLite и состояние, которое оператор видит в Perspective.
Сначала задал теги и поведение насоса. Затем вынес сохранение в Named Queries и проверил, что SQL показывает тот же процесс с понятной разницей во времени. Только после этого собрал экран, где live-состояние и последняя запись базы видны рядом.
Цель была практической: запустить насос, увидеть изменение значений, сохранить его в историю и пройти controlled fault с восстановлением. Это учебный прототип, не промышленная и не safety-certified система.

Начал с программируемого OPC UA-устройства. Сначала проверил endpoint, namespace и доступные nodes через browsing. Затем разделил команды, статусы, процессные значения и счётчики. Gateway Timer раз в секунду читает запросы, рассчитывает отклик насоса и пишет только фактическую обратную связь.
Сначала подключился к OPC UA endpoint и проверил namespace. Это задаёт, откуда Ignition читает данные и какие node paths использует проект.
Через browsing проверил структуру Pump_01 и закрепил nodes для команд, статусов, процесса и счётчиков. StartRequest остаётся запросом, а не фактическим состоянием насоса.
Подписки обновляют Running, FaultActive, скорость, давление, температуру и расход. Их рассчитывает Gateway-модель, а затем те же значения читают HMI и SQL-логгер.
После модели добавил второй Gateway Timer. Он каждые пять секунд сохраняет снимок в SQLite. Named Queries возвращают последнюю строку для SQL-панели и последние десять минут истории для таблицы.
Каждая строка хранит время, Pump_01, состояние, скорость, давление, температуру и расход. Так база фиксирует не экран, а факт процесса.
GetLatestPumpSnapshot отдаёт самый свежий сохранённый снимок для отдельной панели. Это не копия live-тегов, а результат записи в SQLite.
GetPumpHistoryWindow возвращает последние записи с новой строкой сверху. Во время разгона небольшая разница с live-значением ожидаема: SQL пишется раз в пять секунд.
CREATE TABLE IF NOT EXISTS process_snapshot (
id INTEGER PRIMARY KEY AUTOINCREMENT,
captured_at TEXT NOT NULL DEFAULT CURRENT_TIMESTAMP,
equipment_id TEXT NOT NULL,
running INTEGER NOT NULL,
fault_active INTEGER NOT NULL,
speed_actual REAL NOT NULL,
pressure_bar REAL NOT NULL,
temperature_c REAL NOT NULL,
flow_m3h REAL NOT NULL
);
INSERT INTO process_snapshot (
equipment_id,
running,
fault_active,
speed_actual,
pressure_bar,
temperature_c,
flow_m3h
) VALUES (
:equipment_id,
:running,
:fault_active,
:speed_actual,
:pressure_bar,
:temperature_c,
:flow_m3h
);
SELECT
id, captured_at, equipment_id, running, fault_active,
speed_actual, pressure_bar, temperature_c, flow_m3h
FROM process_snapshot
WHERE equipment_id = :equipment_id
ORDER BY id DESC
LIMIT 1;
SELECT
captured_at, running, fault_active, speed_actual,
pressure_bar, temperature_c, flow_m3h
FROM process_snapshot
WHERE equipment_id = :equipment_id
AND captured_at >= datetime(
'now',
'-' || :lookback_minutes || ' minutes'
)
ORDER BY captured_at DESC;
-- equipment_id: String (Pump_01)
-- lookback_minutes: Int4 (10)
Когда обмен и сохранение стали стабильными, собрал операторский экран. Здесь рядом находятся команды, live OPC UA-состояние, последняя SQL-запись и история. Так можно проверить не отдельный тег или запрос, а весь путь от команды до сохранённого результата.
После STOP экран показывает STOPPED: скорость, давление и расход обнуляются, температура снижается к ambient, а SQL сохраняет весь след охлаждения.
После уставки и START насос переходит в RUNNING и разгоняется к target. В SQL видно изменение скорости, давления, температуры и расхода.
При trip-condition модель останавливает насос и сохраняет переход к аварийному охлаждению. После охлаждения RESET разрешает новый запуск.
Что показал этот проект:

OpenPLC и Ignition: ladder-логика, Structured Text state machine, обратная связь датчиков и проверяемые циклы.

Кросс-платформенный продукт для мониторинга оборудования, настройки, читаемых данных и tablet-флоу.

Enterprise-мониторинг для АЭС: состояния системы, инженерные ограничения и 3D-логика хранилищ.