HQControl Manual | Turn screens, device data, and alarm history into one deliverable site system
HQControl is the runtime side of the system. It brings exported screens, prepared tags, device polling, alarms, trends, access control, licensing, and third-party interfaces into one deployable HMI / SCADA runtime.
Turn screens, device data, and alarm history into one deliverable site system
HQControl loads exported screen packages, connects PLCs and live tags, and manages alarms, trends, user permissions, licensing, and operations for a deliverable site runtime.
A practical HQControl manual for field engineers and first-time users. It starts with what HQControl can do, then covers installation, devices, screens, alarms, trends, licensing, migration, backup, federation, redundancy, and diagnosis.
Manual Snapshot
C/S architecture
Windows / Linux
Cloud Server
IO / Alarm / Trend / Script
Key Facts
Collects from: Siemens S7 / OPC UA / Modbus
Runs on: Windows / Linux
Serves out: Live API · alarms & trends · multi-device access
Choose by Goal
Choose the current goal to find the matching page and handling steps.
I want to confirm the whole system is healthy first
Monitoring
Recommended feature
Runtime Monitoring · System Status
Why
Host, modules, services, and live data are collected on the System Status page, making it the diagnosis starting point.
How
Open System Status, check that module status is normal, then confirm key tags have live values.
I want to connect my PLCs and tags to the system
Master Data
Recommended feature
Master Data · Devices and Tags
Why
Screens, alarms, trends, and APIs all depend on the same device and tag data.
How
Create the device with its protocol and address mode, create or import tags, then confirm values in Tag Diagnostics.
I want a value to alarm when it crosses a limit, and to review its history
Monitoring
Recommended feature
Runtime Monitoring · Alarm & Trend Config
Why
Alarms and trends are configured on tags that already have stable live values.
How
After the tag has values, enable participation, then set thresholds, sampling, and archiving and save.
I want active alarms to play sound from a specific speaker
Alarm Sound
Recommended feature
Alarms & Trends · Alarm Sound Configuration
Why
The same alarm system can play different audio by area, PLC, operator station, group, or tag scope.
How
Create a speaker output, then configure sound rules, audio file, volume, repeat interval, and alarm scope on the target browser.
I want users to reach the right screen from the menu
Screens
Recommended feature
Screens · Screen Files, Menus & Popups
Why
Screen files define what exists, menus define where users enter, popups define device detail.
How
Publish the screen files, attach entries in menu configuration, and configure popup templates for device detail.
I want to feed live data to another system, or have the system run jobs on its own
Integration
Recommended feature
Integration · IO State API & Integration Script
Why
Third parties read live values through the API; scheduled jobs and cross-system links use scripts.
How
Give each third party its own scoped key; use Integration Script for scheduled or HTTP/MQTT automation.
I want to move the system to another server without losing data
Maintenance
Recommended feature
Maintenance · Migration, Backup & Restore
Why
Copying only the install folder or screen files loses data. The database and configuration must move together.
How
Back up the database, config, and screen assets, reinstall and restore on the new machine, then re-activate on the license page.
Before You Start
HQControl is the runtime side of the system. It brings exported screens, prepared tags, device polling, alarms, trends, access control, licensing, and third-party interfaces into one deployable HMI / SCADA runtime.
What problem it solves
The design tool creates screens, and the scan tool prepares data. HQControl runs the actual site system: screens open, tags have live values, alarms are recorded, trends can be reviewed, users have clear permissions, and licensing can be delivered.
First things to check
Start with System Status, then verify device and tag values, then open the screen menu. If these three are healthy, alarms, trends, permissions, scripts, and APIs have a solid base.
Delivery is more than installation
Before handover, confirm service health, device connectivity, key tag values, alarm and trend behavior, screen entry points, normal-user permissions, licensing, scripts, APIs, and event records.
Recommended Operation Order
Think of HQControl in six steps: install it, check health, connect devices, configure alarms and trends, publish screens, then finalize permissions, APIs, scripts, settings, and licensing.
Install HQControl
Use the Windows installer on Windows. On Linux, choose the package by uname -m: x86_64 or aarch64. Linux cloud servers use the same package.
Open System Status
Log in as administrator and open System Status first. It is the health page for host state, services, modules, memory, uptime, runtime topology, and active collection devices.
Create devices and tags
Create devices first, choose the correct address mode, then create or import tags. S7 absolute addressing uses port 102 and Rack/Slot; S7 symbolic addressing uses OPC UA, usually port 4840. Confirm live values in Tag Diagnostics before configuring alarms or trends.
Configure alarms, trends, and retention
Only enable alarms and trends for stable tags. Set retention rules before production data grows.
Publish screens and menus
Upload or confirm screen assets, publish them, then configure menus and popup templates.
Finalize settings, access control, APIs, scripts, and licensing
Check /settings, /license, IO State API, Integration Script, roles, and delivery records.
