Back to projects
HardwareFirmwareReversingCANbusFieldbusEmbeddedMotor Control

Parts Repair and R&D

April 2026

A company I worked for repairs industrial appliances, ranging from PLCs and HMIs to PCs. I worked as a repair tech and also helped developments within the R&D department, developing tools to aid in repairs. Below are some projects I did.

Test equipment repair

Sometimes a device can be brought in having a short on either the input or output. The company developed a small handheld device that outputs a sinewave and measures the current being drawn. The voltage and current are then displayed as X and Y. By doing so, the type of load or a short can be visually determined by looking at the waveform. A straight line is a pure resistive load, a oval or circle represent an inductive or capacitive load. Devices featuring an inductor at the input can be detected since an alternating sine is used. A pure DC voltage would show a short all the time. Diodes can also be tested this way. These devices sometimes stop charging or probes stop connecting. I was tasked finding out why and calibrating a few of these.

Developing a test procedure

Once a device is sold the company likes to verify it works before handing it over. This helps prevent warranty claims. Some devices don't have a documented way of testing, so an in-house method is developed. In this case a bus slave was being sold. To test it I hooked up a master device compatible with the protocol. The bus uses 2 wires to supply power while superponating the communication on top. After verifying the master and slave can talk to each other, a VM with the right software is installed. After connecting the master to the PC, the IO can be read. Using a resistor between the supply and an IO also shows the state changing on the PC. The resistor is needed to set the current, since the IO is current controlled.

Reversing a touch protocol

Sometimes, a special type of touchscreen is brought in. In areas where gloves are used or areas with wet hands standard capacitive touchscreens don't work well. Next to resistive touch displays are infrared displays. An array of IR LEDs shines into a receiver array. Pressing means interrupting the beam in both X and Y. These types of display usually have a built-in controller, which does the multiplexing to find out the pressed location and wether a press or release was detected. To verify that the display works, this controller needs to be read. I looked at the UART traffic and exported a few sample movements to Excel. After going trough the data I found which bytes represent press and release and how the data and checksum is calculated. Now, a repair tech can test a system and rule out the display being faulty immediately instead of guessing wether the fault is inside the motherboard or the display.

Creating a touch calibration

Resistive touchscreens consist of 2 layers of resistive film being seperated by a layer of air. When pressed, the films touch at a certain location. By putting a voltage on across terminals of the first film and reading the second voltage on the second film, a voltage will be present related to where is being touched. By flipping the read and the voltage application, both axis can be read. Because of the way these touchscreens are developed the resistance is not always the same across different panels. A way of calibrating is needed. This is done by asking the user to touch somewhere and recording the location. Then the user is asked to touch where the device is recording the touch. A simple scale and translate can be derived from 2 touches, but a skew can be calculated with 3 touches. I developed a program along with a small PCB that can read the location of where is being touched and emulate a modified location back to the controller. The PCB reads the display as described before, but uses digital potentiometers and optocouplers to sync to the device wanting to read the display while also being isolated. This last point is important, since it is never know what voltages a controller will use to read a touchscreen. By using optocouplers and digital potmeters the syncing happens in hardware. A microcontroller only sets the right resistance. For example, if the microcontroller registers a touch at 1V out of the supplied 5V, the potmeter can be set to 256 out of 1024 when using an 8-bit one. Analog switches are used to disconnect the wiper when no touch is detected or to support 5-wire touchscreens.

Development of a CANOPen reader

While CANBus is used in cars, a variant called CANOpen is commonly used within the industry. This assigns a set of registers a name and a function. Multiple profiles exist, like for IO controllers or motor drives. I developed a tool that, depending on the profile, can read the most important registers. For a motor control, a user can go trough the different states and request to start turning the motor. For IO controllers, it is possible to read the amount of IO lines and toggle bits one by one. This toggling can then verify each output works. The same applies to the input.

Development of a SRAM reader

While ROM stores data permanently, RAM loses its data when power is taken away. Some devices save their data or program onto a SRAM chip. When such device comes in, care must be taken to not lose the data, since shorting a pin or taking out the wrong part can cause loss of data. I developed a tool that can safely extract data from a SRAM given its pinout. It uses a user-built database with pinouts and properties for logic levels. Once all data is extracted, a test can be run to verify the SRAM does not corrupt data. This tool can also be used to modify data, like reset hour counters for devices that stop working when a certain hour limit imposed by the manufacturer is hit.

Reversing a RS485 communication

A device came in from a large machine that detects the width and length of wooden boards passing trough. It consists of 48 fingers, each pressing a button. The client brought the part in stating it sometimes falsely detects the width. Since the part was no longer in the machine, the communication could not be sniffed. To be able to detect the fault, some kind of communication must be established. To do this, the EEPROM containing the program was dumped. By disassembling this using IDA, the ASM instructions can be read. This allowed me, with the help of Claude, to reverse the program and how the communication with the machine works. Then I created a Python program that prints all button states when a change was detected. Pressing all buttons revealed some buttons liked to stick sometimes.