The rule of the PLC module: every action on a controller is confirmed and logged, whoever starts it, a person or an agent. Every change to project files shows the files and asks first. This page collects how that works. None of it has yet run against a real controller or vendor tool (see the overview).
What is confirmed
| Action | Confirmation names | Button |
|---|---|---|
| Edit project files (add, rename, move, remove objects; library references; tasks; I/O links; diagram and table edits through agents) | The files written and deleted; for library edits the exact lines removed and added | Change Files |
| Write a TwinCAT value | Target (host, AMS Net ID, port), symbol, type, current and new value | Write Value |
| Write a CODESYS value | Device, address, gateway, application, variable, value read just now, new value; that it is a write, not a force | Write Value |
| Activate, Login and Download, Start, Stop, Logout, Generate Boot Project (TwinCAT) | Target, controller state read over ADS just now, project with file count and fingerprint, PLC project and AMS port, what changes; for activation, a retarget when the project names another controller | The action's own button |
| CODESYS online actions | Device, address, gateway, application, online state the Editor knows, project file and modification stamp, what changes | The action's own button |
| Download to S7-1500 or PLCSIM Advanced | CPU, connection, what is sent, project file; then, in a second dialog, each consequence TIA Portal asks for | The action's own button, then the second dialog |
| PLCSIM Advanced instance commands | Instance, CPU type, state read just now, that the Runtime Manager is unauthenticated | The command's own button |
| CODESYS library and task changes, TIA Portal tag changes | Project, manager, application or PLC, the exact change, whether the file is saved | Change and Save, or Check without Saving |
| Save PLC Project as Library | Project and fingerprint, PLC project, file, format, file replaced, install | Save as Library, Save and Install, Replace, Replace and Install |
Read every line before you confirm, and cancel if the target or the project is not the one you mean.
What a confirmation binds
A confirmation is not a general permission. After you accept a controller action:
- The Editor checks again, just before sending, that the target, the project's files and the controller state are what the dialog showed. If any changed, or more than two minutes passed, it refuses and sends nothing.
- It sends exactly one request with a confirmation bound to that action, that controller and that project, used once. A confirmation for one proposal cannot run another.
- The engineering host applies the same rule on its side and refuses a request without a valid confirmation: missing, stale, reused, for another action, another controller, another PLC project, another engine session.
- A value write happens only if the value has not changed since it was shown.
- A TIA Portal download never accepts a consequence the confirmation does not name, never gives a password and never starts the CPU.
The PLC log
The Output panel, channel PLC, records:
- every controller action attempt: the action, the target (host, AMS Net ID, port; or device, address and gateway; or CPU and connection), the project and PLC project, who confirmed (the operating system's user name, or "not recorded" when it could not be read), when it was confirmed and finished, the controller state shown, and the outcome;
- every value write with both values and the times;
- every target connection, disconnection, failure and symbol upload, and the symbol version and its changes;
- every library save with who, when, the project, the file and the outcome;
- every S7-1500 target added or removed, certificate pinned or forgotten, login and read, never the password or the token;
- the engineering host's own line for each confirmation it sent.
The PLC log is the Editor window's output channel. The module does not keep a separate signed record of these actions, and it does not apply the organisation's governance policy to them: the domain-action rules of Neural Inverse Govern are designed for module actions such as flashing and bitstream loading, and the PLC module does not consult them. Keep the PLC output with your own change records, and follow your site's management of change for any download. See Neural Inverse Govern for what the organisation's policy does cover.
Outcomes
Every controller action ends with one of four outcomes, named in the notification and the PLC log:
| Outcome | Meaning |
|---|---|
| Succeeded | A read of the controller, or the vendor engine's own report, showed the change |
| Sent, its effect not observed | The request went through but nothing shows its effect; never reported as confirmed |
| Did not run | Only when the failure says nothing was sent |
| Not known whether the controller changed | Every failure from the first call that can change the controller on, a timeout, a crash, a cancellation after sending. Check the controller before trying again |
A late answer after a timeout or cancellation is shown when it comes. The vendor pages say which reads decide each outcome: TwinCAT, CODESYS, TIA Portal and PLCSIM Advanced.
Agents
Agents are held to the same rule: every state-changing tool is asked every time, and no tool accepts the consequences of a TIA Portal download. See Agent tools.