Embedded Systems & Product Development Consultancy · London, UK

Industrial interfaces and networking

Devices on a factory bus or a plant network have to talk to equipment older than they are, without dropping a frame. We build the Modbus, RS-485, CAN, 4–20 mA and Ethernet interfaces, and tune the TCP/IP stack behind them.

Talk to an engineer Industrial & energy

Noisy lines, old protocols and silent failures

Industrial links fail in ways a lab never shows: long cables, ground loops, electrical noise and masters that expect a reply within a few milliseconds.

Modbus timing that works with one PLC and fails with another.
RS-485 buses that need a reset after a spike, or show errors only when a motor starts.
4–20 mA readings that drift because of grounding, filtering or calibration.
TCP/IP stacks that slow down or run out of buffers under real network traffic.
No diagnostics, so a field engineer can’t tell whether the fault is in the cable, the device or the master.
Protocol handling mixed into application code, so adding a register means touching everything.

We design the interface hardware and firmware together, and test them against real masters and real noise.

Interfaces we design and program

Modbus RTU and TCP. Master and slave implementations with clean register maps, correct timing and exception handling, tested against PLCs and SCADA software.
RS-485 and RS-232. Isolated transceivers, termination and biasing, and firmware that recovers by itself after line faults. →
CAN and CANopen. CAN networks for machines and vehicles, with message design, bus-off recovery and diagnostics.
Analogue industrial signals. 4–20 mA and 0–10 V inputs and outputs with filtering, calibration and loop diagnostics. →
Ethernet and TCP/IP. lwIP tuned for throughput and memory on microcontrollers, with static or DHCP addressing and web or socket interfaces.
Gateways to the cloud. Field data collected over Modbus or CAN and sent over MQTT, Wi-Fi or cellular to a cloud service. →

Commissioning an interface without surprises

Collect the real requirements. Bus type, cable lengths, baud rates, register maps, isolation and the equipment on the other end.
Design the physical layer. Transceivers, isolation, protection and termination chosen with the PCB, not patched on afterwards.
Write the protocol layer separately. A protocol module with a clear interface, so the application only sees data points.
Test against real equipment. PLCs, SCADA software, protocol analysers and noise injected on long cables.
Leave tools behind. Configuration and diagnostic tools on a PC, so installers can set up and check devices themselves.

Buses, stacks and test equipment

Fieldbuses and links: Modbus RTU and TCP, RS-485, RS-232, CAN, CANopen, 4–20 mA, 0–10 V

Networking: Ethernet, lwIP, TCP and UDP sockets, DHCP, MQTT, embedded web servers

Microcontrollers: NXP i.MX RT, STM32, Microchip PIC and SAM, ESP32 for Wi-Fi bridging

Tools: protocol analysers, Modbus test masters, Wireshark, oscilloscopes, C# and Python configuration tools

Interfaces running around the clock

Client names stay private. The engineering doesn’t.

Air-quality monitoring for power stations, with RS-485 sensors and a tuned TCP/IP stack

View case studies

A 24/7 ATM security device with more than 40,000 units in the field

View case studies

More industrial work

A wireless data transceiver carrying digital, analogue and 4–20 mA sensor data over 868 MHz and 2.4 GHz to PLCs via Modbus, and desktop tools that configure devices over TCP/IP.

Ask about this work

Frequently asked industrial interface questions

Can you add Modbus to our existing device?

Usually, yes. If there is a spare UART and room for an RS-485 transceiver, we add the hardware, a protocol module and a register map, and leave the rest of the firmware largely untouched.

Do you test against real PLCs?

Yes. We test with PLCs, SCADA software and Modbus test tools, and agree the register map with your integrators before the firmware is finished.

How do you deal with electrical noise?

Mostly in hardware: isolation, transient protection, correct termination, grounding and cable shielding. The firmware then detects errors, recovers without a reset and logs what happened.

Can our device talk to the cloud as well as the plant?

Yes. A gateway function can read local equipment over Modbus or CAN and publish the data over MQTT, while still answering the plant’s own master.

Do you work on hazardous-area products?

We have experience with intrinsically safe hardware design to IEC 60079-11 and the limits it puts on interfaces and power.

Can you provide configuration software?

Yes. We write PC tools in C# or Python for configuration, calibration, firmware updates and diagnostics over serial or TCP/IP.

Connecting a device to plant equipment?

Tell us the bus, the equipment on the other end and what has to be exchanged.

An engineer will read it and reply within one business day.

Talk to an engineer