Service
PLC and DCS programming
Most of the control code we are asked to work on was written by somebody else, under time pressure, and never documented. We write ours on the assumption that the same will happen to it.
We programme across Allen Bradley, Siemens, Schneider, Mitsubishi and Omron controllers — five platforms, which is more than any comparable firm in this market names. In practice that matters less as a boast and more because a plant rarely runs one brand: the utilities are Siemens, a packaging line is Omron, and the chiller skid arrived with whatever its OEM used.
Code is written to IEC 61131-3 in whichever of its languages actually suits the problem — ladder where an electrician has to fault-find it, structured text where the logic is arithmetic, sequential function charts where the process is a sequence. Not whichever language the last engineer happened to prefer.
What that covers
- Controller, I/O and network selection, including third-party device interfaces
- Sequence, interlock and permissive logic, with the interlock matrix documented rather than implied
- Batch and recipe handling where the process needs it
- Motion control and axis configuration on servo and drive-based machines
- Safety-related control where a safety controller or safety I/O is in scope, executed to the relevant standard
- Analogue loop configuration, scaling and tuning, including cascade and split-range loops
- Alarm rationalisation — fewer, better alarms rather than one per bit
- Data interfaces to SCADA, historians and MES over OPC UA or native drivers
Networks and protocols
- Ethernet
- EtherNet/IP · PROFINET · Modbus TCP · EtherCAT
- Serial and fieldbus
- PROFIBUS DP · Modbus RTU · CANbus · ControlNet · DeviceNet · CC-Link
- Data
- OPC UA · OPC DA · native SCADA drivers
On source code and licences
You get the source. If a job requires a licence we hold and you do not, we say so at quotation and tell you what it costs to hold it yourself. A control system you cannot open is a control system you do not own, and it is the most common trap we find in inherited plant.
How we work a programming job
- Step 01
Functional design specification
Written first and agreed with the people who will operate the plant, not only the people buying the project. Disagreements are far cheaper in a document than on a live line.
- Step 02
Development and simulation
Written and proved against simulated I/O or an emulator before it goes anywhere near real machinery.
- Step 03
Test against the panel
Run against the actual panel during FAT, with I/O forced point by point.
- Step 04
Site commissioning
Loop checks, dry runs, wet runs, then production, with an engineer on site until it holds.
Questions we get asked
Next step
Have a plc & dcs programming enquiry?
Send the plant detail — platform, I/O count, what has gone wrong, and the window you can give us. An engineer picks it up.
An engineer responds within one business day.