Record the error, affected page, device or Tag, first failure, and last known good time. Keep System Status and relevant logs.
Manual
Mingcedar Troubleshooting
Record symptoms, time, and state; check each layer and fix one cause at a time.
Record the symptom, then locate the failing layer
Note the time and visible state before separating service, connection, collection, routing, data quality, and action results.
Start with the five services, PostgreSQL, Redis, and licensing in System Status. Then inspect configuration application, device connection, collection, and Tag quality. A healthy earlier layer does not prove later layers are healthy.
For alarm, trend, script, or write failures, compare events and command records with later collected values and service state. Do not repeat a device command while its result is uncertain.
Services do not start after install or reboot
Check the installation role and five runtime services, then inspect PostgreSQL, Redis, logs, and autostart.
Check whether the selected mode includes host services. A Windows full install includes host and data services; host uses data services prepared on the same machine. A database or client-only install does not provide a full runtime entry point.
On Windows, check HQControl, HQControlIO, HQControlAlarm, HQControlTrend, and HQControlScript in Services. On Linux, run sudo hqcontrolctl status and sudo hqcontrolctl health. Read the log for any service that is not ready.
Confirm PostgreSQL and Redis are ready before opening the configured Portal and Screen HTTPS addresses. After services recover, check platform status, licensing, and Tag collection separately.
Control panel state is wrong, autostart does not apply, or reboot does not launch services
Use the actual service state and System Status to confirm that autostart was saved and works after reboot.
Cross-check the control panel with OS Services or hqcontrolctl, System Status, and service logs. The icon alone does not prove readiness.
After saving autostart settings, inspect the service startup configuration for the deployment. Reboot during a maintenance window, then check all five services, PostgreSQL, and Redis. A started process is not proof that every service is ready.
If only some services recover, inspect PostgreSQL, Redis, certificates, and the startup logs of services that remain unavailable. Fix one cause and recheck before restarting the whole runtime unit again.
The admin console cannot open or stays not ready
Check the Portal address, HTTPS certificate, and Web/App service before investigating PostgreSQL and Redis dependencies.
Open the configured Portal HTTPS address for the admin console; Screen uses a separate origin. Check hostname, port, DNS, reverse proxy, and firewall. Database and Redis ports are not browser entry points.
For a certificate or TLS error, check the certificate name, validity, and client trust. If the page is unavailable or not ready, inspect Web/App status and logs, then confirm PostgreSQL and Redis are reachable.
Sign in to the admin console, then open a runtime screen to verify the Screen origin. Check device connection, Tag quality, alarms, and trends separately; a recovered web page does not prove collection has recovered.
PostgreSQL, TimescaleDB, or Redis is abnormal
Use System Status and logs to distinguish PostgreSQL/TimescaleDB faults from Redis faults before recovery.
Check PostgreSQL and Redis in System Status, or OS services and logs if the console is unavailable. Verify addresses and ports to distinguish stopped services, connection failures, and slow responses. Web failure alone does not prove database corruption.
Inspect free disk space, persistent directories, credentials, certificates, and program/database versions. For missing history, check TimescaleDB and Trend service health; do not fill gaps with zero values.
Before database recovery or migration, retain a consistent backup and use matching program and database versions. After dependencies recover, check the five services, screens, Tag quality, alarms, and trends. Do not copy a live database directory as a backup.
Manual connection succeeds, but the device list still shows offline
A connection test checks reachability; applied configuration, collection ownership, Tag quality, and update time need separate checks.
In device details, inspect configuration application, PLC connection, and collection state separately. A connection test does not prove that the device definition was applied or that a Tag has valid data.
Check that the device has enabled physical Tags and an eligible IO Owner. Standby, not collected, connection uncertain, and connection failed are different states and need different responses.
Check host, port, addressing mode, certificates, or driver fields required by the selected protocol. For S7Plus, confirm the driver is installed on the collecting host. Then inspect full Tag name, type, quality, and update time in Tag diagnostics.
After correcting configuration, wait for application and the first valid sample, then compare the Tag value with field conditions. Good quality means the data is usable; it does not alone prove device online state or write completion.
Two sites collect the same PLC, or a remote site shows no devices
Confirm that the installer supports the deployment mode, then inspect remote capability scope and the active IO Owner. Ordinary site federation does not provide cross-PC standby.
Federation shares selected capabilities between independent sites. The current dedicated-node installation provides IO only and requires same-machine data services on loopback addresses; remote databases are unsupported. Cross-PC standby requires a verified plan matching the delivered version.
Remote alarms viewed through ordinary LAN connections are read-only; disabled actions do not necessarily indicate an account permission problem. Sign in directly to the source site with the required permissions to acknowledge, shelve, or unshelve.
At the local site, inspect the target site, connection direction, selected IO capability, and device scope. Then check remote trust and permissions. Configure the opposite direction separately only when the remote site also needs local capabilities.
In device details, inspect the active IO Owner, runtime unit, and PLC definition. Ownership is coordinated within one runtime unit; independent sites configured for the same physical PLC do not automatically exclude each other. Choose the intended source, disable unnecessary duplicate collection, and consume its data through IO sharing.
Check the actual IO Owner, applied configuration, driver, credentials, and network. After recovery, wait for valid new samples and inspect Tag quality, alarms, and trends. For a verified same-domain takeover plan, also check leases and candidate eligibility. Reconcile uncertain writes from records before retrying.
PLC connectivity, symbolic addressing, IO Owner, or federation is wrong
Check PLC connection and Tag collection first, then federation scope and IO Owner before diagnosing interactions between them.
Follow the PLC connection section on this page to inspect applied configuration, protocol fields, collection ownership, Tag quality, and update time. A successful connection test is not a substitute.
Follow the Federation and IO Owner section to inspect site relationship, capability direction, device scope, and active owner. Opening a remote screen does not prove this site has selected remote IO data.
Online or offline activation fails
Use /license to inspect license status and perform online or offline activation. The current unactivated trial lasts two hours per process.
A valid permanent certificate takes precedence over trial operation. Trial state is memory-only and is not a persistent license. On expiry, protected business functions stop and require operator action through the licensing workflow. Automatic restart must not be used to renew a trial.
In connected environments, submit activation details through the license page and verify the result. Offline, export a request for the current host, obtain the signed response, import it, and verify product, host, and status. The license page is accessible without login but does not display a used activation code.
Invalid, revoked, modified, or host-mismatched certificates do not fall back to trial operation. Re-license the new host after migration and retain issuance and maintenance records instead of reusing the old host’s authorization.