Troubleshooting

Common Issues

Control program won’t start

Symptom: acctl control start or acctl push control --start fails.

Check:

1. Is the server running? sudo systemctl status autocore_server
2. Is there a build error? Check the output of acctl push control for Rust compiler errors.
3. Is the project loaded? acctl status should show your project as active.

Tick signal lost

Symptom: Control program starts but does not cycle. Logs show “Tick wait failed”.

Fix: The server should auto-reset timers. If not, restart the server:

sudo systemctl restart autocore_server

Variables not updating in the HMI

Check:

1. Is the control program running? acctl control status
2. Is the variable being written in process_tick? Add a log statement to verify.
3. Is the WebSocket connected? Check the browser console for connection errors.

Hardware not responding (EtherCAT/Modbus)

Check:

1. Is the module enabled in project.json? Check "enabled": true.
2. Is the module executable configured in config.ini?
3. Is the module running? acctl cmd system.get_domains lists all connected modules.
4. Check module logs: acctl logs --follow will show output from all modules.
5. For EtherCAT: Is the network cable connected? Is the correct interface configured?
6. For Modbus: Can you ping the device? Is the IP address and port correct?

Module running but its status reports an empty config

The module is launching but has no NI/EtherCAT/Modbus configuration loaded (e.g., ni.status shows "channels": [], ni.start returns “No NI configuration loaded”). This means the module was launched without --config. Almost always: the supervisor refused to start it from project.json because validation failed, and something fell back to launching it ad-hoc. Recent server builds refuse that fallback for project-declared modules — older builds did not.

Check, in order:

1. Run acctl validate. If it reports any ams.placeholder errors, you have an unguarded ${ams.*} reference somewhere. The most common case: a placeholder with no | default … clause when the asset isn’t registered. Fix the placeholder (${... | default <value>} or register the asset) and push the project again.
2. Check the server log at /srv/autocore/logs/autocore-server.log for an UnresolvedAmsPlaceholders line. That’s the supervisor refusing to start the module — the validator above should have caught it, but the log gives the exact placeholder path.
3. Confirm the module’s actual launch command with ps -ef | grep <module-name>. If the row has only --ipc-address and --module-name — no --config — then the supervisor never spawned it; only the ad-hoc path did. On current builds that path refuses project-declared modules; on older builds it silently substitutes. Update the server.
4. After fixing the project, run acctl push project --restart to apply.

Build errors after changing project.json

Fix: Regenerate the global memory struct:

acctl push project
acctl codegen
acctl push control --start

“Permission denied” when starting the server

Fix: The server may need network capabilities to bind to port 80:

# If using systemd (default installation)
sudo systemctl start autocore_server

# If running manually
sudo setcap cap_net_bind_service=+ep /opt/autocore/bin/autocore_server

Diagnostic Commands