Hi there 👋

I’m Marcin Lukaszewski, an engineer who’s been working with EPICS for over a decade.

This site is my home base for sharing practical tips, small discoveries, and project updates that might make life a little easier for anyone building control systems with EPICS.

Whether you’re running experiments in a large facility, setting up a lab instrument, or just starting to explore EPICS, I hope you’ll find something useful here.

If you’d like to share ideas, collaborate, or simply swap stories from the control room, I’d love to connect.

Thanks for stopping by, and happy engineering! 😊

Device Integration

Device integration is hard. Every control system engineer knows this. If we’re lucky, the device we’re trying to run via EPICS is a mass-produced, off-the-shelf bit of kit that’s already been integrated. In this case, it’s relatively easy - there’s a high chance that the support exists somewhere in the popular repositories. It’s then “just" a matter of installing, testing, and we can call it a day. However, more often than not, the device we need to integrate comes from a small company that’s a leader in a very niche field of science or engineering. They excel at building specialised equipment, and since their target customers are equally focused on the physical components, they’re very successful. ...

Epics Database Override

Recently, I chatted with one of the engineers I work with about the problem of supporting several beamlines/projects with a slightly different version of the software for a given device. While this might sound like an easy task, it becomes a burden when the number of devices and projects grow. We discussed several strategies for accomplishing this at scale, but I would like to start with the simplest solution first to learn its pros and cons. I wondered if there is a possibility of splitting the record definition between two files. One file could serve as a blueprint for a record and the other as a defining/altering for a specific project. ...

On Socat

Sometimes, a device does not respond as intended. This could be due to a firmware problem, incorrect protocol implementation on the device, wrong IOC configuration, inaccurate metadata, or everything in between. In such cases, it’s quite handy to know what exactly is being sent to the device to determine which side is wrong. The easiest way to check this is by using the IOC asynReport facility and enabling logging to monitor the data being sent. But what if, for some reason, we don’t want to modify the IOC? Or we don’t have the IOC yet and struggle to get the “manual” communication working? ...

Robust Automation with Busy record

Let’s consider a common scenario in control system development: You’ve created an automation feature that orchestrates multiple devices via channel access. The sequence of actions is simple, but you must ensure that each step begins only after the previous one has completed successfully. How can you achieve this reliably? Here are three options: Execute a step and wait some time before executing the next one. Execute a step and poll the device to check if the step has been finished Use the native Channel Access feature - putNotify to do the job. Why Option 1 is problematic The first option is the least reliable. Relying on fixed delays can lead to unpredictable behavior. If time isn’t the decisive factor in determining the success of a step, a simple time-based approach can cause errors. ...