Replacing the unsupported WAGO Webcalendar with a native CODESYS 3.5 implementation removes the dependency on the old CODESYS 2 runtime while preserving calendar-based control. The number that matters is the time at which each output changes state relative to the controller clock. This is time-state compatibility, not current or thermal overload.
Wrong fixes and their failure modes
Several apparent shortcuts leave the original dependency intact or introduce a new platform without resolving schedule behavior.
| Attempt | Why it fails | Better decision |
|---|---|---|
| Keep the old runtime because the calendar still operates | The unsupported component remains the only way to edit or execute the schedule. A future controller, runtime, browser, or project change can turn technical debt into downtime. | Capture the existing schedule semantics and rebuild them in the target environment. |
| Open or copy the CODESYS 2 calendar directly into CODESYS 3.5 | A major runtime-generation change is not a visual-screen conversion. Libraries, visualization objects, persistent data, date handling, and task behavior can differ. | Recreate the functional model and validate each behavior. |
| Upgrade the runtime before inventorying the calendar | The working system is then no longer available as a behavioral reference. Unrecorded exceptions, overrides, and restart behavior may be lost. | Export or manually document every schedule and test case first. |
| Install a Docker-based alternative immediately | Docker was proposed for the PFC200 or PFC300, but no completed installation or compatibility result was established. Container capability alone does not prove calendar integration, resource capacity, licensing, or output ownership. | Treat a containerized application as a separate architecture requiring a bench test. |
| Select Ignition only because it provides scheduling and visualization | It moves scheduling outside the PLC and adds communications, deployment, licensing, and failure-mode decisions. | Choose it only when centralized supervisory scheduling is an intentional requirement. |
Runtime boundary and scheduling mechanism
The existing Webcalendar runs on a CODESYS 2 image, while the desired target is CODESYS 3.5 on a PFC with an old runtime. No maintained drop-in Webcalendar alternative for CODESYS 2.3 was identified. A calendar has, however, been implemented directly in CODESYS 3.5, making a functional rebuild the clearest supported engineering path.
A calendar controller converts wall-clock data into deterministic commands. The application must compare the controller's current date and time with enabled schedule entries, resolve overlaps, apply exceptions, and expose the resulting command to the control logic. The display is only an editor; the schedule engine and stored data determine plant behavior.
Define these rules before writing visualization code: start and stop boundaries, weekday selection, date exceptions, manual override priority, overlapping-event priority, behavior after a restart, and treatment of an event missed while the controller was stopped. If these rules remain implicit, two implementations can show identical calendars yet command different outputs.
Migration quantities and decision points
| Quantity or limit | Why it matters | Where to read or define it |
|---|---|---|
| Installed runtime generation and version | Determines whether the target can run the CODESYS 3.5 application and required libraries. | Controller runtime information and the CODESYS project device configuration. |
| Controller model | Separates the current PFC from proposed PFC200 or PFC300 container targets. | Device identification and project hardware tree. |
| Controller date, time, and time zone | Every transition is calculated from this clock. | Controller clock configuration and online diagnostics. |
| Maximum schedule-entry count | Sets array size, retained-memory demand, and editor bounds. | Count the existing entries, then define an application limit. |
| Schedule evaluation interval | Sets the maximum detection delay for a transition. | Task configuration containing the calendar evaluator. |
| Retained-data capacity | Determines whether entries survive restart or download. | Target memory configuration and online memory diagnostics. |
| Command ownership | Prevents the calendar, manual mode, and other logic from writing conflicting values. | Cross-reference every destination variable in the project. |
Choose a native CODESYS 3.5 calendar when scheduling must continue locally without a supervisory computer. Choose an external scheduler such as Ignition when several controllers need central administration, audit functions, or a common operator interface. A Docker deployment on a PFC200 or PFC300 remains a candidate design until the exact controller, runtime, container support, resource use, and communications path pass a bench test.
Native CODESYS 3.5 rebuild procedure
- Freeze the behavioral baseline. Record every weekly event, date exception, enabled state, controlled point, manual override, and observed restart result from the working calendar. Capture boundary cases around midnight and week changes.
- Record the target. Read the PFC model, installed runtime version, project device version, available retained memory, and controller clock configuration. Resolve any project-to-runtime mismatch before adding calendar logic.
- Define the schedule record. Store the fields needed to reproduce the baseline: enabled state, applicable days or dates, start time, stop time, controlled command, and priority where overlaps are permitted. Set an explicit maximum entry count from the inventory plus planned growth.
- Separate evaluation from presentation. Run the schedule evaluator in a PLC task and use the visualization only to edit validated records. A closed browser or disconnected engineering station must not stop local schedule execution.
- Centralize arbitration. Produce one calendar request per controlled function, then combine it with manual, safety, and process requests in a single arbitration block. Avoid multiple program sections writing the physical output directly.
- Validate edits before storage. Reject invalid dates, reversed intervals unless overnight operation is explicitly supported, duplicate entries that create ambiguity, and indices beyond the configured array.
- Define persistence and recovery. Decide which schedule fields are retained, how defaults are loaded after data loss, and whether a missed transition is applied immediately after restart or deferred until the next event.
- Commission with simulated entries. Use short test windows, observe internal requests and final commands online, then load the documented production schedule only after the decision rules pass.
Verification under timing and restart conditions
Verification must compare commanded state with clock state, not merely confirm that the calendar page renders. Trend or observe the current time, active-entry index, calendar request, override state, arbitration result, and final output command.
- Test a normal start and stop boundary and measure the transition delay against the evaluator task interval.
- Test an event spanning midnight if overnight intervals are allowed.
- Test two overlapping entries and verify the documented priority rule.
- Apply a manual override before, during, and after an event; confirm that release returns control according to the defined policy.
- Restart the runtime during an active interval. Verify retained entries and the selected missed-event behavior.
- Correct the controller clock across a scheduled boundary and check that the application does not issue unintended repeated actions.
- Disconnect the visualization client and confirm that the PLC-resident evaluator continues operating.
For an external or containerized scheduler, repeat the tests with communications interrupted. Define whether the PLC holds the last command, falls back to a local default, or rejects stale schedule data; observe that behavior rather than inferring it from the user interface.
Recurring migration pitfalls
Clock quality is the first recurring fault. A correct schedule evaluated against the wrong local time produces a precise but incorrect transition. Record the configured time zone and test any clock adjustment policy used at the installation.
Retention is the second. A schedule that exists only in visualization memory or nonretained variables can disappear after a restart or application download. Treat the editable schedule as controlled application data with defined initialization and recovery behavior.
Multiple writers create intermittent results. The calendar may set a command correctly while manual logic or another program organization unit overwrites it later in the scan. Cross-reference the command path and assign final output ownership to one arbitration point.
Finally, avoid treating a successful CODESYS 3.5 screen as proof of a complete migration. The acceptance test covers time boundaries, overlaps, exceptions, persistence, restart, clock correction, communications loss, and operator editing.
FAQ
Why does WAGO Webcalendar still work if it is unsupported?
The installed CODESYS 2 application and runtime can continue executing unchanged. Unsupported status becomes operationally significant when a runtime, controller, browser, library, or project change requires a component that is no longer maintained.
Why does the CODESYS 2 calendar need rebuilding in CODESYS 3.5?
The migration crosses a runtime generation and involves schedule data, persistence, visualization, task execution, and clock behavior. Rebuild the functional model in CODESYS 3.5 and verify its outputs against the recorded baseline.
Why does a Docker calendar on a PFC need a bench test?
Docker was proposed for the PFC200 or PFC300, but installation feasibility alone does not validate runtime compatibility, processor and memory load, licensing, communications, persistence, or failure behavior. Test the exact controller and runtime combination before selecting that architecture.
When should I stop the WAGO Webcalendar migration and contact official support?
Stop when the installed PFC runtime cannot be matched to the CODESYS 3.5 project, required runtime or container capability is unclear, or a test causes lost schedules or uncontrolled output ownership. Record the controller model, installed runtime version, project device version, and failing test, then escalate through an official WAGO support channel before changing the production controller.