Hi there 👋

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....

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....

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....

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....