Deploying PLCnext Engineer Projects Without the IDE

Overview

PLCnext Engineer is only one delivery path to a PLCnext Control target. The runtime does not require the engineering tool to be attached at start-up: it loads whatever project directory the current symbolic link resolves to under /opt/plcnext/projects. That makes it possible to build once on an engineering PC, ship the resulting binary artifacts as ordinary files, and start execution on the controller with two shell commands.

This procedure covers three related engineering problems:

• Deploying a complete compiled project to a controller from a build server, CI pipeline, or USB stick with no IDE installed.
• Starting project execution on the target without a PLCnext Engineer download/connect session.
• Placing a new project on a controller without destroying compiled artifacts (TIC files, GDS port configuration) that already exist in another project directory on that same controller.

How the Runtime Locates a Project

The relevant paths and their roles:

Because the selection is a symlink, several project directories can coexist side by side. Switching applications is then a link update plus a restart, not a file overwrite.

Prerequisites

1. PLCnext Engineer installed on a Windows PC, with the project opened and compiled at least once. Compilation, not download, is what populates the @binary tree. If the tree is missing or stale, recompile and confirm the timestamps.
2. The firmware version on the target matches the firmware/version the project was compiled against. A project built for a different major firmware line may load but fault, or be rejected at start-up.
3. SSH or serial console access to the controller with an account permitted to use sudo.
4. A file transfer path to the target — SCP/SFTP, WinSCP, or a mounted SD card/USB medium.
5. A written record of the existing current link target, so you can roll back. Capture it before touching anything:

   ls -l /opt/plcnext/projects

Procedure A - Replace the Default PCWE Project

Use this when the controller carries a single application and you simply want to overwrite it.

1. Compile in PLCnext Engineer. Resolve every compiler error; a partially generated binary tree will not load.
2. Open the binary path on the Windows PC:

   C:\Users\Public\Documents\PLCnext Engineer\Binaries\PROJECT_xxx@binary\RES_xxx\Configuration\Projects\PCWE

   If more than one PROJECT_xxx@binary folder exists, sort by modified date and match the project name fragment. Multiple RES_xxx folders mean multiple resources — pick the resource that maps to the controller you are deploying to.
3. Copy the entire PCWE folder (the directory itself, not just its contents) to the target and replace /opt/plcnext/projects/PCWE. Preserve the internal directory structure exactly; the runtime resolves relative paths inside this tree.
4. Restart the runtime on the target:

   sudo /etc/init.d/plcnext restart

   This is a cold start: the application restarts from initial values.

Procedure B - Deploy Without Disturbing Existing TIC/GDS Artifacts

Overwriting /opt/plcnext/projects/PCWE replaces everything inside it — including the compiled IEC 61131 code artifacts (TIC) and the GDS port/data configuration belonging to the previous application. If you must keep the previous project intact and switchable, deploy side by side instead:

1. Rename the copied binary folder to a unique, meaningful name before or after transfer, for example IOconf, and place it at /opt/plcnext/projects/IOconf. Do not overwrite the existing PCWE directory.
2. Repoint the runtime selection link to the new directory:

   cd /opt/plcnext/projects
   ln -sfn IOconf current

   The -s creates a symbolic link, -f forces replacement of the existing link, and -n treats the existing current link as a file rather than following it into the directory. Omitting -n is the classic mistake: you end up with /opt/plcnext/projects/current/IOconf instead of a replaced link.
3. Restart to load the newly selected project:

   reboot

   or, for a faster cycle without a full OS restart:

   sudo /etc/init.d/plcnext restart

Rollback is symmetric and takes seconds — repoint the link at the previous directory and restart:

cd /opt/plcnext/projects
ln -sfn PCWE current
sudo /etc/init.d/plcnext restart

Keep each released application in its own dated or version-tagged directory (PCWE_v1_4, PCWE_v1_5) and treat current as the only mutable object. This gives you an on-target A/B deployment scheme with no IDE involved.

Verification

1. Confirm the link resolves where you expect:

   ls -l /opt/plcnext/projects
   readlink -f /opt/plcnext/projects/current

   A broken link (red in most shells, or No such file or directory from readlink -f) means the runtime will start with no application.
2. Check ownership and permissions of the transferred tree. Files copied as root from a USB medium can end up unreadable by the runtime process. Compare against the untouched original project directory with ls -lR and align owner/group/mode.
3. Watch the runtime come up. After the restart command, verify the process is running and the controller status indicators reach the RUN state expected for your hardware. If the application does not start, inspect the PLCnext log output on the target for load-time errors before recompiling anything.
4. Prove the application is the one you shipped. Write a build-ID constant or version string into a global variable in the project and read it back — via HMI, OPC UA, or a diagnostic variable — after start-up. Directory names alone do not prove which binary the runtime loaded.
5. Re-verify I/O. A cold start re-initialises outputs. Confirm the physical I/O configuration in the deployed project matches the installed modules and their positions before releasing the machine.

Engineering Notes and Pitfalls

For automated delivery, the whole flow reduces to: build on the engineering PC, archive the PCWE directory as a versioned artifact, scp it into a new directory on the target, update the symlink, restart. No engineering tool is required on the machine that performs the deployment.

FAQ