Motionwell provides PLC programming services in Singapore for new equipment and existing machines. We develop sequence logic, HMI recipes, alarms, recovery routines and equipment interfaces on the control platform your plant supports. The handover includes readable source code and documentation matched to the commissioned machine.
Our control work includes palletizing cells, automated storage cranes and a QA laboratory programme with explicit sample-state tracking. Design and testing take place at Woodlands Link with our in-house engineering team.
This page is about programming a controller that is staying. Getting off an obsolete platform is a different project with a different shape, set out on our PLC migration and upgrade page.
When a station also needs PC-based vision or data processing, define which runtime owns the sequence and how the two exchange results. The Industrial PC vs PLC architecture guide includes a responsibility table and fault tests for that interface.
What Separates Machine Code That Survives From Code That Works on the Day?
Both pass the acceptance test. The difference shows up in year two, when whoever wrote it has left, a new variant arrives and something fails at three in the morning.
Four properties do most of that work, and none is visible in a cycle time. The program is structured, so one station is one block. Names describe the device. State is explicit and held in one place, so the machine can say what it is doing. And the documentation describes the program that is in the controller after commissioning changed it.
| What good looks like | What it prevents | Where it is decided |
|---|---|---|
| One tested block per station, instantiated once | A bug fixed at station three surviving at stations one, two and four | Program architecture, before any code is written |
| Names that describe the device and the machine | A technician tracing wires to find out what a tag does | Naming convention, agreed at the start and enforced |
| Explicit machine and part state in one place | A machine that cannot be restarted after a stop without clearing it by hand | State design, a specification question |
| Alarm text naming the device, the condition and the next action | An alarm nobody reads and a stop reason of “Other” | Alarm design, done with the people who will read it |
| Settings sorted into recipe, parameter and constant | A variant change that needs an engineer, or an operator able to set a value the machine cannot survive | The functional specification, before the HMI is drawn |
| Version control with one master copy and a change record | Two engineers each holding a different truth about the controller | Project setup, in the first week |
| A sequence description that matches the running program | Every future change starting with an archaeology exercise | The last week of the project, budgeted for |
Each row is expanded below, in the order it gets decided.
Why Does Your Existing Standard Usually Decide the Platform?
Because your plant lives with the choice for a decade and a builder does not. Where two platforms both clear the technical requirement, the one your plant already runs wins on cost of ownership: spares are on the shelf, the maintenance team has been trained, the support route exists. That is why the first question on an enquiry is what you run.
The licence is the cost that stays invisible. Every platform is its own engineering environment, so a machine on a seventh platform is one your engineers cannot open without buying and learning something.
Two situations override the plant standard, both technical. A device or a robot controller may need a protocol the standard platform does not carry, though it should be verified: EtherNet/IP, Profinet and OPC UA cover most of what a machine needs, and a gateway republishing Modbus TCP covers much of the rest. And where the site the machine will run in has a different standard from the parent plant, the site wins.
Mixed-vendor machines are legitimate and they are also a decision. Our delivered 5-axis CNC shot peening machine pairs an operator panel from one vendor with motion control from another: a sound machine, and also two engineering tools, two spares chains and two support routes for whoever owns it in year six. That trade belongs in the platform selection meeting, with both halves on the table.
Compare Siemens and Allen-Bradley platforms on the named controller and engineering environment. For the communication layer, EtherCAT vs PROFINET addresses supported motion and I/O functions, while PROFINET vs Modbus identifies device roles, data definitions and stale-value handling.
Why Is a Machine You Can Recover Worth More Than a Machine That Is Fast?
A machine only runs at its cycle time when nothing goes wrong, and something goes wrong regularly. Real output is decided by how long it takes to become useful again, which is a property of how state was designed.
The failure mode has a shape. State ends up spread across a scatter of booleans, each set in one rung and cleared in three others, so the machine’s condition exists only as a combination of flags. None of them is wrong on its own. What is wrong is that nobody, including whoever wrote it, can answer the question that matters after a stop: given where everything is now, what is the machine allowed to do next? The answer becomes a power cycle, a manual clear of the fixture and a lost part, every time.
An explicit state machine answers it directly. Whatever has state, the machine, a station or the part itself, holds one state variable; transitions are defined in one place with the conditions that allow them; anything that is not a legal transition is refused.
| State carried in scattered flags | Explicit state machine | |
|---|---|---|
| Where the current state lives | Implied by a combination of bits | One variable per entity, readable on the HMI |
| Adding a step | A new flag and edits in several rungs | A new state and its transitions, in one place |
| Recovery after a mid-cycle stop | Reconstructed by whoever is standing there | The state says which transitions are legal, so the machine offers them |
| An impossible sequence | Runs, and produces something odd | Blocked, and logged as an exception |
| Diagnosing “why did it stop” | Reading logic live and inferring | Reading the state history |
The delivered version is on the QA laboratory programme. Every sample moves through six defined states inside the cell PLC: queued, in transit, at station, in test, completed and failed. Each transition is stamped at millisecond resolution and logged with the sample identity, the source and destination state, the station and, where a person intervened, the operator identity. The rules are enforced by the state machine itself, so a sample cannot jump from queued to in test without passing through in transit and at station, and an invalid attempt is blocked and logged as an exception. What is worth copying is that the audit trail survives an error recovery, which is exactly where a record built from cycle counts falls apart. The build is in the QA laboratory automation case study.
Recovery is a designed path: a failed sample has a state of its own, so an operator intervention remains part of the record. Retry limits and escalation rules are set for each operation, with the attempt and its outcome logged before the sequence continues.
A two-cylinder station handling one part can use a compact sequence with clearly defined start, stop and reset conditions. Multi-part handling, expensive mid-cycle interruptions and records that must survive a fault benefit from an explicit state model. We choose the structure during concept review from those recovery and traceability requirements, keeping the program straightforward for the maintenance team.
Production monitoring needs interpreted values and unavailable states at its destination. IO-Link acquisition interfaces tests the master/device and upstream data path separately.
What Makes an Alarm Worth Reading at Three in the Morning?
An alarm exists to get somebody to do the right thing. Judge every line of alarm text against that and much of it fails, because it reports a bit.
The reader is a technician who did not build the machine and is under pressure. In one line they need which device, in what condition, and what to do next. “Station 4 fault” gives none of the three. “Station 4 infeed sensor saw no part after the pusher extended: check for a jam at the infeed guide, then reset at the HMI” gives all three, from the same bit.
| Written as the bit | Written as the situation |
|---|---|
| Zone 2 fault | Zone 2 stopped: guard door 2 opened while the index was moving. Close and latch the door, then reset. The station holds its position |
| Servo error | Y axis exceeded following error during the transfer move: check for an obstruction on the rail before reset. A repeat means the axis needs a mechanical check |
| Vacuum fail | Pick failed at station 1: vacuum did not reach setpoint within the grip window. Check the cup for wear or product film, then clear the part manually before restart |
| Low air | Compressed air below the working pressure: the machine has stopped safely. Restore supply, then reset. Clamps stay closed on air loss |
Four rules do most of the remaining work, each costing nothing while the program is being written.
Separate what stops the machine from what merely wants attention. Alarms stop or prevent; warnings are for something drifting; events are the record. Where all three arrive on one list, the list gets acknowledged.
Record which came first. One physical event produces a cascade, and the cascade tells you nothing. The first alarm in the group is the diagnosis, and capturing it is a few lines of code at design time.
Tag every alarm with a stop reason. The controller already knows which interlock, which alarm word and which starved sensor stopped the machine, so mapping those bits to loss categories while the alarm structure is being built means downtime arrives already sorted, with nothing picked from a dropdown at the end of a shift. The arithmetic those categories feed is in our explainer on what OEE actually measures.
Write the text in the language the reader reads. A machine can ship with a perfectly translated manual and still show alarm text in the language it was written in, which is the language your technician meets at the point of failure. Ask to see the alarm list before purchase. How those alarms are then grouped, ranked and presented on the panel is a screen design question, on our HMI and SCADA integration page.
One boundary. Alarm bypass, calibration and maintenance mode are authority levels, behind the platform’s own named-account security, and not behind a key switch or a password the whole shift knows, because an authority level everybody can reach is a screen. On a line making records, that access model is part of the record system, covered on our electronic batch records page.
Where Does a Setting Belong: Recipe, Parameter or Constant?
Three boxes, and many arguments about an HMI screen are really arguments about which box a number goes in. Three questions sort them: who may change it, how often does it change, and does it belong in the production record.
| Recipe | Machine parameter | Constant in code | |
|---|---|---|---|
| What it describes | The product | This particular machine | A physical fact about the design |
| Changes when | The product or variant changes | The mechanism is adjusted, repaired or recalibrated | Never, without a mechanical change |
| Who may change it | Operator, by selection, at their authority level | Engineering, at a higher level, with a record | Nobody at runtime |
| Examples | Fill volume per dosing head on our tray-fed filling and sealing machine, capping torque, screwdriving torque per fastener, label artwork and code content | Axis home offsets, per-head volume calibration, sensor debounce times, camera exposure for the installed lighting | Station count, axis direction, safe state on air loss, the transition rules of the state machine |
| Where it lives | A named recipe, versioned, stored outside the device | The machine record and the as-built pack | The program, named |
A variant setting stored as a protected machine parameter can turn a routine changeover into an engineering task. On the SCARA panel line, the product recipe coordinates paths, vision settings and fastening targets, with torque results recorded against the panel serial number. The design separates operator-selectable product recipes from calibration and machine-configuration values.
A physical constant exposed as a recipe field is the more dangerous direction, because it gives an operator a legal way to select a value the machine cannot survive. If a number cannot change without something mechanical changing, it does not belong on a recipe screen at any authority level.
Two rules follow. Every recipe field needs a range the machine enforces, because an unvalidated input eventually receives a typing error. And a recipe belongs outside the device that consumes it, exported where it can be restored to a replacement unit, which matters most for a vision job or a drive parameter set and is set out on our smart camera versus PC-based vision page.
What a recipe cannot do is move steel. Which parts of a format change are software and which are a change part set is settled long before the HMI, on our filling line changeover page.
How Is Machine Code Version-Controlled on a Regulated Line?
Start from what a program archive on a USB stick in a drawer is not. It is a copy, and a copy answers none of the three questions that matter: which version is in the controller now, what changed since the last one, and who decided that change was acceptable. Answering them needs four things, none of them exotic.
The first is one master location that is not a person: a named repository, a controlled network location or a document management system, with the rule that the copy in the controller was built from it. The failure it prevents is two engineers each holding a different truth about what is running.
The second is a version identity recorded with the machine. The program version, the archive and its checksum, and the firmware versions of controller, drives, HMI and any smart device, recorded together. An archive without the firmware it was built against restores into something subtly different, which is what you cannot afford during a breakdown.
The third is a change record carrying the reason and the test: what changed, why, who approved it, what was tested afterwards and what the result was. Outside a regulated environment this is a short entry; inside one it is the audit trail.
The fourth is a comparison somebody can actually read. Ladder diffs are not text diffs, and vendor compare tools give a readable answer only when the program is structured and consistently named. That is the practical reason a naming convention pays for itself: an unreadable compare means re-testing the whole machine to verify one change.
On a regulated line, PLC application code is written for one machine and runs nowhere else, which is why it sits in the heaviest GAMP category and carries design review, code review and functional testing traced to the functional specification. Changes are impact-assessed before they are made, and where the records fall under 21 CFR Part 11 the audit trail, access control and record integrity are part of that code review. How far a change reaches into requalification is your quality unit’s decision, taken in the structure on our computer system validation page.
One category of code sits outside all of this. Safety functions are not ordinary program logic and do not become safety functions by being written carefully. Each carries a required performance level under ISO 13849-1:2023, calculated and validated on the devices that implement it, and a design still documented against the 2015 edition needs those calculations restated when the machine is re-assessed. The scope that follows is on our machine safety and CE marking page.
What Should You Insist on Seeing Before You Sign Off Commissioning?
Anything but the happy path. A machine that has reached an acceptance test can run a good part, and watching it do so proves only that it can do it again. What you are buying is behaviour at the edges, so the test has to go there deliberately.
Two things happen before the machine is touched. The sequence, the alarms and the recipe handling are exercised against simulated I/O, so they are debugged before meeting real hardware. And the acceptance list is agreed in writing before the test opens: which cycles run, which products, which faults get demonstrated, and who signs. A test written into the plan is cheap; one invented on the day is an argument.
| Ask to see | What you are actually testing | A weak answer |
|---|---|---|
| A part removed mid-cycle, then restart | Whether the machine knows what state it is in | “Just power cycle and clear the nest” |
| Power pulled mid-cycle, then restored | Restart into a defined safe state without a corrupted record | It comes back, but the count or the record disagrees |
| Every alarm triggered and read aloud from the HMI | Whether the text names a device, a condition and an action | A code and a manual to look it up in |
| A changeover run by your operator | Whether the recipe structure works for the person who will use it | Our engineer does it, quickly |
| An action attempted at the wrong authority level | Access control, before it is a finding | Everyone shares one login |
| The record for the units just run, checked against what happened | That the data means what it claims, including for the parts that failed | An export that only contains the good ones |
On regulated builds these become scripted tests inside operational qualification, with fault conditions created deliberately, access levels challenged, audit trail behaviour checked and backup and restore proved. Factory acceptance testing happens at Woodlands Link with you present, then site acceptance testing on real production material. An item often left out is the first production shift after handover, where format cases, recovery paths and operator habits surface in hours. An engineer on the floor turns those into fixes; one who has gone home turns them into a support ticket.
PLC logic should use the tested installed I/O map. verified wiring and I/O connects physical circuit verification with the subsequent machine sequence.
What Do You Need at Handover So You Are Not Locked to Us?
Apply one test to the whole pack. Could a competent contractor who has never seen this machine open the program, understand the sequence, change a timer and put it back into production? If not, you are dependent whatever the contract says, and that dependency was created months earlier.
What that requires:
- The program in editable form, source and comments together, with the comments in the language your maintenance team reads.
- The tool that opens it, named, with the licence position stated: which software version, which edition, and who holds the seat.
- An administrator account you own on the controller and the HMI, with our access removable by you.
- The sequence of operation as built, covering every mode including setup, jog, cleaning and manual recovery.
- The alarm list, each line mapped to its stop reason, so the mapping survives the person who made it.
- The archive plus the firmware and software versions, which is also what sets your patching horizon.
- A named owner on your side, because a pack with no owner is a folder nobody opens until the machine is down.
Two items on that list cannot be produced at the end. Naming and comment language are agreed before any code is written. And if remote access exists, decide at panel design whose credentials it uses and how you switch it off, since it is a path a retrofitted machine never had before; the zone and conduit reasoning is in our guide to IEC 62443 for industrial control systems.
This pack is the deliverable. The wider list of questions worth putting to any integrator on control architecture and support, including to us, is in our guide to choosing an automation system integrator.
A saved project needs a verified relationship to the running machine. PLC backup before battery maintenance checks recoverable programme, retained values and the documented maintenance sequence.
How Do You Match the Programming Scope to the Machine?
Restore the mechanical datum where accuracy has drifted. Survey the guides, drive and fixture alongside the sequence. Mechanical repair and controls changes can then share one acceptance test against the required part tolerance.
Include controller migration where lifecycle or capacity drives the project. Review support status, spares, memory, communications and cycle requirements before selecting the hardware and programming scope.
Use the original builder’s sequence knowledge where it is available. Compare its supported upgrade with a new implementation, including source access, functionality, commissioning time and future maintenance.
Connect machine logic to site software through a defined interface. The PLC handles the real-time sequence and equipment state; scheduling, warehouse systems, reporting or MES receive the agreed events and return the commands the machine needs. Our PLC-native laboratory design managed 70 sample positions across 7 racks. A site-wide system adds a separate application and data architecture around that machine interface.
Plan ongoing ownership with the software. Agree the maintenance team’s access, training, source archive and support route. These decisions determine the platform and handover package as well as the code.
What Should You Send Before Asking for a Number?
Six items, in the order they change the answer.
- The controller make, model and vintage, with the I/O module list, and whether program source exists and has been confirmed against the machine.
- What the machine has to do that it does not do today, written as behaviour: a new variant, a faster recovery, a record, a line interface.
- How many variants share the machine and how often you change between them, which decides how much of the design is recipe structure.
- Where the safety functions live, meaning hardwired, in the standard PLC, or in a dedicated safety controller, and whether any performance level calculation exists.
- Who maintains it afterwards, what platform they already read, and whether your group publishes a programming standard.
- Whether the machine makes records anybody audits, and which quality unit approves changes to it.
Lead time on a new build runs 16 to 24 weeks from concept approval to factory acceptance testing, and 24 to 32 weeks where cleanroom compatibility or full validation documentation applies. A programming scope on an existing machine is set by point count, sequence complexity and the size of the recovery and test matrix, which is why the survey comes before the number.
How Much Does PLC Programming Cost?
PLC programming cost follows the number of I/O points, sequence complexity, available source code and test scope. A timer change on documented equipment requires a different survey and verification effort from rebuilding an undocumented machine program.
What raises it is work that has to happen before the change can: writing the sequence from the machine itself where source is missing or stale, restating a performance level calculation where the change reaches a safety function, and carrying the review and traced testing described above where the line makes audited records.
What lowers it is structure already in place. Where stations are blocks, where names survive a search, and where your maintenance team already reads that platform daily, the reading that precedes any code gets shorter. That reading is the part no rate card can see.
Where a programming change also affects protective functions, identify the safety logic and its verification scope separately. The safety PLC guide explains that boundary and the configuration records needed for future changes.
Standards Used in Machine Design and Validation
These references inform the design, testing and documentation described on this page. Each row links to its primary source and records the edition checked.
| Standard | Current edition | What it means for your machine |
|---|---|---|
| ISO 13849-1: Safety of machinery, safety-related parts of control systems | ISO 13849-1:2023 | Provides the design method for safety-related control functions, including architecture, component reliability, diagnostic coverage and common-cause failure measures. The machine risk assessment establishes the required Performance Level; design calculations and validation provide the evidence for each function.Checked 1 Sep 2026 against ISO 10218-1:2025 normative references |
Frequently Asked Questions
Will you program a machine another company built?
Yes, and it is a normal part of the work, but the first deliverable is not code. It is a written sequence of operation, an I/O list naming the actual device at the end of each point, and an interlock list saying what each one prevents. Where the existing program is available and readable, that document is written from it and confirmed on the machine. Where it is not, it is written from the machine itself. Anyone quoting a program for a machine they have not surveyed is quoting a guess, and the guess is discovered during commissioning.
Can you work to our own PLC programming standard?
Yes, and we ask for it at enquiry stage. If your group publishes naming conventions, a tag structure, a standard alarm block, a state model or a template project, working inside it costs less than working outside it and hands your engineers something they already know how to read. Send the document itself. Where a plant standard and a machine requirement genuinely conflict, we raise it in writing before the code is written and the plant decides.
Do you write in ladder, structured text or function blocks?
All three, chosen per task, and constrained by what your maintenance team can read at two in the morning. Discrete interlock and station logic goes in ladder, because a technician can watch it live and see which contact is holding the machine. Calculations, recipe handling, data structures and communications handling go in structured text, where the same work in ladder becomes unreadable. Repeated stations become one tested function block instantiated per station, which is why adding a station later is a configuration change.