Device Connectivity

Adapnex tools, including the Adapnex CLI and the VS Code extension, interact seamlessly with physical industrial controllers across local plant floors, corporate networks, and remote field installations. A unified communication layer handles device discovery, transport encryption, and permission management automatically.

Architecture Overview

Each Adapnex-enabled industrial controller runs a background system service called the Adapnex Daemon (adapnexd). The daemon manages process lifecycles, collects diagnostic metrics, and provides a secure, hardened endpoint for Adapnex tools.

All communication between your workstation and the controller is encrypted end-to-end and authenticated end-to-end. Unlike traditional virtual private networks (VPNs) that grant network-level access by exposing entire subnets and all open ports on a machine, the Adapnex architecture exposes only a single secured service endpoint. This minimal surface area prevents unauthorized lateral movement across plant networks.

Connection Hierarchy

Industrial control environments feature diverse network topologies ranging from direct Ethernet patch cables to multi-tiered corporate firewalls and remote cellular gateways. Adapnex tools use a three-tier connection hierarchy to establish communication automatically:

Local Subnet Discovery

When your workstation and target controller share the same local Ethernet segment or Wi-Fi subnet, Adapnex tools use a local discovery protocol.

You do not need to look up or manually track dynamic IP addresses assigned by local DHCP servers. Simply address the controller by its assigned name:

adapnex app run line_1_plc conveyor_app

In the VS Code extension, the Devices view under the Adapnex sidebar displays all controllers associated with your user account.

Local discovery requires the controller and the developer workstation to reside on the same network subnet.

Static Network Addressing

In factory automation facilities, physical controllers often sit on isolated machine VLANs, behind managed industrial switches, or across corporate routing boundaries that block discovery broadcasts.

To connect across routed network boundaries, register one or more explicit IPv4 addresses for the device using adapnex device address add:

adapnex device address add line_1_plc 192.168.1.50

Much like adding an entry to a local DNS table, registering an address binds that reachability path to the controller name. Once added, you continue to refer to the device simply as line_1_plc across all commands and tools without having to remember its network address.

You can inspect all registered addresses for a controller using adapnex device address list:

adapnex device address list line_1_plc

If an IP address changes when relocating a machine to another production line, remove the obsolete entry with adapnex device address remove:

adapnex device address remove line_1_plc 192.168.1.50

Adapnex Cloud Relay

Remote machines deployed in the field often connect through cellular modems or factory firewalls that block all incoming network connections.

The Adapnex Daemon maintains an outbound connection to the Adapnex Cloud infrastructure in order to allow you to connect remotely. This outbound-only architecture ensures that no listening ports or firewalls are exposed to the public internet.

You can use all Adapnex tools in the exact same way across both local and remote setups, simply specifying the name of the controller. The tools automatically choose the optimal connection path, whether establishing a direct link over the local network or routing transparently through the cloud. In all cases, connections remain fully encrypted end-to-end and authenticated end-to-end between your workstation and the remote device.

Authentication and Access Control

Access to physical controllers is tied to verified developer identities rather than shared root passwords or static private keys.

Workstation Authentication

Before managing devices, log in to your Adapnex account using adapnex login:

adapnex login

This command opens an OAuth2 browser confirmation flow that links your local developer session to your user account. In the VS Code extension, clicking Sign In directly in the Adapnex sidebar provides the identical authentication flow when not logged in.

Granular Device Permissions

Fleet administrators can grant and revoke controller access on a per-user basis. To view all engineers authorized to interact with a specific controller, use adapnex device permission list:

adapnex device permission list line_1_plc

To grant access to a team member, use adapnex device permission grant:

adapnex device permission grant line_1_plc [email protected]

To revoke access when an engineer transitions off a project, use adapnex device permission revoke:

adapnex device permission revoke line_1_plc [email protected]

Revocations take effect immediately without needing to update the physical controller. In the VS Code extension, authorized users are listed under the Users node of each device, with inline buttons to add users or revoke access.

File Transfers and Remote Operations

Copying Files

Adapnex allows bidirectional file transfer between your local workstation and remote controllers, as well as between two controllers. Use the adapnex device copy command:

# Copy a local configuration file to the controller
adapnex device copy ./config.json line_1_plc:/etc/my-app/

# Copy a remote log directory back to your workstation
adapnex device copy -r line_1_plc:/var/log/my-app/ ./debug-logs/

In the VS Code extension, expanding a controller reveals a Files entry with an inline Mount Filesystem button. Clicking it mounts the remote filesystem directly into your VS Code workspace, allowing you to browse, edit, and transfer files within the native file explorer.

Interactive Remote Shell

To inspect system state or configure network interfaces directly on the operating system, open an interactive terminal session with adapnex device shell:

adapnex device shell line_1_plc

You can also run one-off remote commands directly without launching an interactive shell:

adapnex device shell line_1_plc -- ip addr show

Network Configuration and Diagnostics

Workstation Firewall Settings

On Linux developer workstations, local firewall rules (such as ufw or firewalld) may block incoming discovery replies from controllers.

To permit zero-configuration local discovery on Linux systems using UFW, allow inbound UDP traffic originating from source port 16708:

sudo ufw allow proto udp from any port 16708 to any

Connection Latency Testing

To verify network quality and assess transport latency before deploying time-critical software updates, run a connection diagnostic with adapnex diagnostic speedtest:

adapnex diagnostic speedtest line_1_plc

The diagnostic tool measures round-trip ping time and sustained transfer throughput across the active connection path.