brands · South Africa
CODESYS Soft-PLC vs Hardware: Runtime and I/O Guide
Compare CODESYS soft-PLC and hardware targets: simulation limits, runtime selection, I/O mapping, dependencies, timing evidence and study migration checks.
A CODESYS soft-PLC is a runtime running on a supported computing platform. A dedicated controller also combines hardware, firmware or runtime software, drivers and an application. The useful comparison is the complete execution environment: timing requirements, I/O support, dependencies, licensing, recovery and maintenance. “Software versus hardware” alone hides most of those decisions.
This guide distinguishes development-system simulation, an installed soft-PLC runtime and a vendor controller target. It includes a fictional timing trace that shows why an acceptable average can hide a missed interval limit. The examples support course selection and technical study; they are not performance measurements of named products or a design approval for an industrial installation.
Separate three environments before comparing them
The development system is where you configure and write the application. Its simulation mode provides an environment for checking supported programme behaviour without the intended controller. An installed runtime executes an application on a supported target platform and has its own capabilities and restrictions.
A vendor controller target adds a specific combination of device description, runtime or firmware, I/O and manufacturer support. The presence of CODESYS-related technology does not mean every vendor toolchain or controller accepts an unchanged project from the generic development system. Identify the supported engineering route for the exact device.
The CODESYS platform guide provides the wider context. For a course enquiry, state which of these environments learners will use. “PLC simulation included” is incomplete if your objective is to configure communications to a real runtime or investigate a device's actual I/O.
Simulation mode is not a fieldbus test
CODESYS documents restrictions in its Simulation command: fieldbus stacks are not evaluated, I/O channels are not updated and bus telegrams are not sent. A simulated logic result therefore cannot establish that the intended fieldbus devices communicate correctly.
Use simulation for the questions it can answer, and write down the remaining integration checks. A training exercise can validate a Boolean rule in simulation, then use an appropriate isolated runtime and I/O arrangement to investigate mapping and communication. Keep those results separate so the learner understands what each stage demonstrates.
What current runtime descriptions tell you
The CODESYS Control SL overview lists runtime products for different platforms and use cases. Select the specific product from its supported operating system, architecture and required capabilities. Do not treat the entire family as one interchangeable licence or performance category.
The current Control Win SL product page describes soft real-time properties and applications without hard real-time requirements. It also states that the product is not released for use in containers or virtual machines. Check the current product restrictions against the intended host before using it as a course or project target.
The Raspberry Pi SL product information places responsibility for meeting necessary industrial specifications on the system manufacturer when used industrially. That is different from declaring every Raspberry Pi installation either universally suitable or universally unsuitable. The complete system and its requirements need evaluation.
These product details were checked on 12 September 2026. Availability, licensing and supported environments can change. Use the current product documentation and a specific quotation for a purchase; this guide does not invent a single runtime price range or a fixed exchange-rate estimate.
Compare the complete system against its task
Start with what the application must do and the evidence needed to show that it does it. A classroom Boolean exercise, a data-collection demonstration and a time-sensitive control application impose different requirements. A platform suitable for one should not inherit approval for the others.
Record the host model, processor architecture, operating system, runtime version, device description and important drivers. Include the development-system and compiler versions used for the exercise. This makes the environment reproducible and prevents a vague comparison between “a PC” and “a PLC”.
For I/O, identify the actual interface and supported driver or protocol. A programme variable changing in a watch window does not establish that a physical channel has changed. The industrial networking training guide helps separate network concepts from the device-specific configuration that still needs practice.
For maintainability, ask who supplies updates, how the application and configuration are backed up, and how a replacement target would be prepared. Include the available support skills in the decision. A familiar form factor can still be difficult to maintain if the required environment and recovery process are undocumented.
Compare course costs from the required setup
A development-system download, an evaluation runtime, a licensed deployment and a complete teaching workstation are different cost items. Ask which are included in the course and which remain the learner's responsibility. A free editor does not imply unlimited use of every runtime or add-on.
Use the PLC course cost guide to compare tuition, equipment access, software, assessment and continued practice. For a training centre, include the number of simultaneous learners and the rules for using the chosen runtime on shared or individually assigned hosts.
Portability starts with separating application logic from dependencies
A small calculation written in a supported IEC language may be portable in principle, but an application includes more than that calculation. Device configuration, libraries, I/O mapping, communication settings and task arrangements can depend on the target. Review each category rather than assuming a successful text copy completes the move.
The CODESYS library structure guide explains why effective dependency versions matter. When changing targets, record which placeholders resolve differently and which packages are required by the new environment. An unchanged top-level library name can conceal a changed dependency.
Keep a narrow interface between the educational process model and target-specific I/O. For example, the core logic can consume a documented Boolean input while a separate adapter supplies it from either a study sequence or a configured channel. The adapter needs its own checks; separating it simply makes the responsibility visible.
Use the CODESYS language-choice guide to choose a representation that reviewers can understand. Portability is not created by selecting ST, LD or FBD alone. The same language can contain either a clear interface or tightly coupled target assumptions.
Treat I/O mapping as an integration requirement
CODESYS documents device configuration and I/O mapping separately from writing application logic. In a training brief, identify which variable corresponds to which channel, the data type and the intended meaning. For analogue signals, include units and conversion rules.
A mapping exercise should include an independent observation that distinguishes the intended channel from a neighbouring one. If both channels happen to hold the same value, a single matching result is weak evidence. Use a controlled study pattern with clearly different values and document the authorised test arrangement.
Check direction as well as identity. A command variable, an output channel and observed device feedback describe different stages. The PLC communication troubleshooting guide supports a structured investigation when those stages disagree.
When moving a training application to another target, recreate the mapping from the requirement and supported device configuration. Do not rely on an old address remaining meaningful simply because the programme still builds. Preserve the previous mapping as a baseline for review rather than overwriting the only record.
Timing has several different meanings
A configured task interval, actual spacing between task executions, programme execution duration and end-to-end response are different quantities. State which one a test measures. A fast calculation can coexist with late scheduling or delayed I/O, and an acceptable average interval can coexist with an occasional large gap.
CODESYS defines periodic jitter as the difference between the task period and desired interval. Its documentation distinguishes this from latency and release jitter. Use the terms consistently so a result can be compared with the requirement it is meant to address.
For a course exercise, retain the timestamp source, units and sampling method. If the data comes from a synthetic worksheet, label it synthetic. If it comes from a runtime monitor, record the relevant environment and what the displayed field represents in that version.
Do not convert an observed maximum from a short run into a guaranteed worst case. It is the largest value in that observation set. A complete engineering assessment needs an appropriate workload, duration and method for the actual application; the small study below only demonstrates how to interpret a supplied trace.
Worked exercise: an average that hides a long interval
The fictional TimingStudy has a desired start-to-start interval of 10 milliseconds. Its classroom acceptance rule requires every observed interval to be no greater than 12 milliseconds. This is an invented study threshold, not a recommended industrial task setting or a specification for a CODESYS product.
The trainer supplies the intervals 10, 10, 15, 5 and 10 milliseconds. Their sum is 50 milliseconds over five intervals, so the mean is 10 milliseconds. A report containing only the mean looks perfect against the desired interval, but one interval exceeds the stated 12-millisecond limit.
| Observation | Interval in ms | Difference from desired 10 ms | Meets the study interval limit? |
|---|---|---|---|
| 1 | 10 | 0 | Yes |
| 2 | 10 | 0 | Yes |
| 3 | 15 | +5 | No |
| 4 | 5 | -5 | Yes |
| 5 | 10 | 0 | Yes |
The minimum interval is 5 milliseconds and the maximum is 15. The positive and negative deviations cancel in the mean. That cancellation does not undo the long third interval. The correct conclusion is that this supplied trace fails the declared per-interval rule despite matching the desired average.
These numbers describe spacing between starts, not how long the application code executes inside each interval. The worksheet contains no execution-duration measurement. It also contains no I/O timing, so it cannot establish the delay from a physical input event to an output response.
Reconstruct the timestamps
Starting from a timestamp of zero, the successive starts occur at 0, 10, 20, 35, 40 and 50 milliseconds. Subtract adjacent timestamps to recover the five intervals. This is a useful consistency check and clarifies why six start timestamps produce five intervals.
Now imagine that the timestamp at 35 is missing from the record. The remaining timestamps include a 20-to-40 gap of 20 milliseconds. Without additional evidence, you cannot say whether the task actually had one 20-millisecond interval or whether a record was lost. Mark the observation limitation rather than inventing an exact internal history.
Similarly, a duplicated timestamp can create an apparent zero interval. Investigate the recording process before calling that a measured scheduling event. Data quality and runtime behaviour need separate consideration, just as simulation and actual I/O do.
Test a second fictional trace
The trainer supplies a second set: 9, 11, 10, 12 and 8 milliseconds. The mean is again 10, the maximum is 12 and all five intervals meet the inclusive limit. This trace passes the stated classroom screen.
Passing this screen does not make the second platform universally better. No real platform was measured, and the dataset says nothing about longer runs, different loads or other requirements. The lesson is to compare a defined measurement against a defined limit and state the scope of the result.
Build a migration exercise with several independent checks
First preserve the original study environment and expected behaviour. Record the project, dependencies, target configuration and selected test cases. A migration is easier to review when the baseline is identifiable and the learner can explain what must remain equivalent.
Next, separate environment setup from application changes. Establish that the target is supported and that required packages resolve. Then review the application interfaces and mappings. Changing several assumptions at once makes it harder to identify why an observation differs.
Run the same logic-level cases against the migrated educational application, then add the target-specific integration checks. A correct calculation should retain its expected result, while I/O mapping and communication need evidence in the new environment. Keep a list of cases that could not be executed rather than counting them as passes.
Finally, inspect the start and recovery behaviour required by the exercise. Describe which state is expected to begin fresh and which state, if any, is expected to survive the specified event. Confirm the actual runtime mechanism before making claims about persistence. A generic variable name such as SavedCount does not establish retention.
The scan-cycle guide helps learners connect application execution to observations. Use it to explain why a paper sequence, a simulated task and a physical target each need a clear model before their results can be compared.
Keep startup and recovery distinct from normal running
A programme that behaves correctly after manual preparation may still have an incomplete startup requirement. In a course, ask what initial inputs and state are supplied and how the first valid observation is recognised. Do not hide preparation steps in the instructor's demonstration.
If the exercise includes a restart, specify the type of restart and the expected state afterwards. A development-system action, runtime restart and loss of host power are not automatically equivalent events. Test the one the lesson actually requires in the authorised training environment.
For a team evaluating a target, include the practical recovery materials: application, device configuration, dependencies and applicable licence arrangements. Ask whether another authorised person can restore the study setup from those records. A backup that cannot be associated with the correct environment is incomplete evidence of recoverability.
Avoid broad claims that a particular form factor guarantees uptime. Reliability depends on the complete system, its conditions and support process. A useful course teaches learners to identify those dependencies without pretending that a short demonstration measures long-term availability.
What to ask a South African course provider
Ask whether the practical uses IDE simulation, Control Win or another named runtime, or a specific vendor controller. Request the version and supported host arrangement. If the objective includes fieldbus work, ask which real communication path learners configure and observe.
Request an example assessment that distinguishes logic correctness from integration and timing. The fictional trace in this guide can be used as a preparation question: can the learner explain why the mean passes while the interval limit fails? The native practical should then teach how relevant observations are obtained in the actual environment.
For shared laboratories, confirm individual access and how environments are restored between learners. If one learner changes a dependency or mapping, the next learner needs a known starting point. A documented reset of the study setup is part of reproducible teaching.
For remote classes, ask about connection interruptions, supported computers and recovery of missed practical work. For institutional evaluation, use the training-centre guide to define the required activities before selecting software or equipment. The most expensive setup is not automatically the best match for an introductory lesson.
Where educational browser simulation fits
This site is commercially connected to PLC Simulation Software. Its PLC programme testing resources can support practice with requirements, selected inputs and expected results. Check the current educational feature set before choosing a specific exercise.
Its Structured Text learning resources can help prepare learners for logic study. They do not establish native CODESYS runtime execution, physical I/O compatibility or measured scheduling performance. The synthetic timing examples on this page are independent teaching data.
Use browser practice to arrive at a vendor course with clear questions and a small portfolio of explained exercises. Then obtain supervised experience in the intended runtime and hardware environment. Label the origin of each result so a reviewer can see which skills were practised and which remain to be assessed directly.
Questions about CODESYS soft-PLCs and hardware targets
Is a soft-PLC the same as CODESYS simulation mode?
No. Simulation mode has documented restrictions, including no fieldbus telegram exchange. An installed runtime is a separate execution environment with product-specific capabilities and requirements. Name the environment when describing a practical result.
Can I move the same project to any CODESYS-related controller?
Do not assume that. Review the supported engineering environment, device description, dependencies, mappings and task configuration. Logic may be reusable while integration work changes. Test the migrated application against its stated requirements.
Does a 10-millisecond average prove every interval is acceptable?
No. The fictional first trace averages 10 milliseconds but contains a 15-millisecond interval that exceeds its declared limit. Retain the distribution and relevant extrema, and state what the observations actually measure.
Is Control Win SL suitable for hard real-time requirements?
The current product page describes soft real-time properties and excludes applications with hard real-time requirements. Select a runtime and host from the actual requirement and supported configuration, then obtain appropriate target-specific evidence.
Is Raspberry Pi always unsuitable for industrial use?
The current product information places responsibility on the system manufacturer to meet the necessary specifications for industrial use. Evaluate the complete installation and support requirements. A board name alone is insufficient to decide suitability.
What should I demonstrate after a target-migration lesson?
Show the baseline, changed environment, resolved dependencies, logic tests, mapping checks and remaining limitations. Include timing or recovery evidence only where the exercise actually measured it. A successful build is one check within that record, not the whole result.