Motionwell Automation provides PLC programming services in Singapore on machines we build and on machines we did not, as part of the control system modernisation that is our largest line of work this year. The platforms are the ones our customers already run: Allen-Bradley CompactLogix and ControlLogix in Studio 5000 with FactoryTalk where named accounts are required, Siemens S7-1500 with TIA Portal and WinCC, Omron, Mitsubishi iQ-R with GX Works and GOT2000 panels, Beckhoff and Inovance. Delivered work shows the range: a palletizing cell sequenced on a Mitsubishi iQ-R architecture over EtherNet/IP with the ABB IRC5 controller running robot motion independently of the cell PLC, an automated storage and retrieval crane sequenced by a Siemens S7-1500 over Profinet, and a QA laboratory programme re-ordered in four consecutive years in which every sample moves through a formal six-state machine inside an Allen-Bradley PLC with each transition stamped at millisecond resolution. Machines are designed, assembled and tested at our Woodlands Link facility with an in-house design team of eight, and the company has delivered more than 150 special purpose machines since 2014 under ISO 9001:2015 and bizSAFE Level 3.
Where we stand, said plainly. We do not manufacture controllers, drives or HMIs and we are not a distributor for any of them, and we are not a notified body. This page is also about programming on 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 and not repeated here.
This page covers what separates code that survives from code that works on the day, who really decides the platform, state design, alarm design, where a setting belongs, version control on a regulated line, what to insist on seeing before you sign, and what has to be in your hands at handover. If you have a machine, a controller type and a sequence you need changed, skip ahead and talk to an engineer.
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 rather than a run of rungs that grew. Names describe the device rather than the address it landed on. 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, not the one written before commissioning changed it.
The last of those quietly decides the rest. A sequence description that no longer matches the running program is worse than none: it gets trusted once and never again, after which every change starts with reading the whole program to find out what it really does.
| What good looks like | What it prevents | Where it is decided |
|---|---|---|
| One tested block per station, instantiated rather than copied | 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 rather than a coding one |
| 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 Rather Than Us?
Because we do not have to live with it and you do. 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 rather than what we prefer.
Spares are the visible cost. Two others are not. Every platform is its own engineering environment with its own licence, so a machine on a seventh platform is one your engineers cannot open without buying and learning something. And the dearest of the three is fluency: a technician who reads one platform daily diagnoses a fault in minutes, while the same technician on an unfamiliar one reads a manual first.
Two situations override the plant standard, both technical rather than commercial. A device or a robot controller may need a protocol the standard platform does not carry, though this is rarer than it is claimed: 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 runs an Omron operator panel over Delta motion control: a sound machine, and also two engineering tools and two support routes for whoever owns it.
Why Is a Machine You Can Recover Worth More Than a Machine That Is Fast?
Because a machine only runs at its cycle time when nothing goes wrong, and something goes wrong several times a shift. 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 rather than attempted.
| 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 Allen-Bradley 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 rather than discarded. What is worth copying is that the audit trail survives an error recovery instead of breaking at it, which is exactly where a record built from cycle counts falls apart. The build is in the QA laboratory automation case study.
Two decisions in that design are the ones people get wrong. Recovery is a designed path rather than an exception: a failed sample has its own state with a defined route back, so an operator intervention is part of the model instead of a hole in it. And retries are bounded and recorded, three attempts on a positioning check before escalation, because a retry that leaves no trace is worse than a stoppage.
The honest limit. On a two-cylinder station running one part, a formal state model is more code to write and more to test than the machine deserves, and we say so rather than bill for it. The threshold is consequence rather than size: it earns its cost when a mid-cycle stop is expensive, when a record has to survive a fault, or when more than one thing is in the machine at once.
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 most of it fails, because it reports a bit rather than a situation.
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 rather than read.
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 instead of being 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 rather than the brochure. 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 rather than screens, behind FactoryTalk security on Allen-Bradley or WinCC user administration on Siemens. 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 most 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 from delivered work | Fill volume across the 5 to 500 mL range, capping torque within the 0.5 to 5.0 Nm band, screwdriving torque per fastener from 0.1 to 2.0 Nm, label artwork and code content | Axis home offsets, per-nozzle 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 rather than typed as a bare number in a rung |
The two ways of getting it wrong fail in opposite directions. A recipe value stranded as a machine parameter turns a variant change into an engineering visit. That is what a recipe structure buys back: the SCARA sensor panel line we built runs more than 15 variants and changes between them in under 3 minutes, because the entire difference between variants lives in the recipe rather than in the mechanics. On the same line, screwdriving torque is set per fastener from the recipe and measured by a rotary torque transducer in the spindle, with final torque and rotation angle recorded against the panel serial number.
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.
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.
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.
A change record that carries 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.
A comparison you 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 the 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 rather than a separate exercise. 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?
Not the happy path. Any 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, or needs clearing by hand | “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, not our engineer | 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 rather than a fix | 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. The item most 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.
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 rather than by anything withheld at the end.
What that requires:
- The program in editable form, not a compiled or locked download, with 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 rather than by request.
- The sequence of operation as built, covering every mode including setup, jog, cleaning and manual recovery, with the I/O list naming the real device at the end of each point and an interlock list saying what each one prevents.
- 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 of controller, drives, HMI and smart devices, 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 rather than a courtesy. 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.
When Is PLC Programming the Wrong Thing to Buy?
We do this work, so read this as the argument against our own quotation.
The mechanism is the actual complaint. New code cannot hold an accuracy that worn guides, a slack drive or a tired fixture has lost. It shows you the problem in better detail and produces the same parts.
The controller is what has run out. If the platform is out of support, the spares are on the used market or the processor cannot hold what you need, you have a migration rather than a programming job, and its four strategies are on the PLC migration page linked above.
The machine builder still supports its own software. On a standard machine, price the original builder’s upgrade first: they hold the sequence knowledge you would otherwise pay to reconstruct, and where that is the better buy we say so at concept review.
What you actually need is a software product. Scheduling across a site, warehouse management, a reporting layer or an MES is not a PLC scope. We build the machine end and the interface to it, which is why a PLC-native design was right for 70 sample positions across 7 racks in that laboratory and would not be for a site-wide system. We do not sell software products, so what we write ships with the machine rather than as a licence.
Nobody will own the machine afterwards. A custom program assumes a maintenance team that reads schematics and keeps a pack current. Where a site has neither, a supported catalogue machine is the more honest purchase whatever the fit.
Two exclusions while we are being direct. We do not take on production welding cells. And where the honest answer is that your existing program is sound and something else on the machine is the problem, that is the answer you will get.
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 rather than as a feature: 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 — 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 rather than by processor performance, which is why the survey comes before the number.
Which standard editions apply right now?
The editions below are the ones we design and document against on current projects. We check them on the date shown rather than assuming last year's edition still holds.
| 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 | The 2023 edition is the version referenced by ISO 10218-1:2025 for robot control system safety functions. Designs still documented against the 2015 edition will need their PL calculations restated when the machine is re-assessed. |
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 rather than during design.
Can you work to our own PLC programming standard?
Yes, and we ask for it at enquiry stage rather than at design review. 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, not a description of it. Where a plant standard and a machine requirement genuinely conflict, we raise it in writing before the code is written and the plant decides, because a deviation agreed in advance is a note and one found at acceptance is an argument.
Do you write in ladder, structured text or function blocks?
All three, chosen per task rather than per project, 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 rather than a copy of a copy.