Labels, Camera, Action…!

By Control F1 Lead Architect Phil Kendall.

Control F1 were asked earlier this year to work with a global pharma company to write the control software for a complex piece of physical hardware. Integrating all the moving pieces had proved a challenge, so our client needed a company with extensive experience in developing complex pieces of Windows software. From the specification supplied by our client, we quickly identified that there were going to be two main challenges in this project:

• Integrating with the hardware in the project: four barcode-reading cameras from Cognex, and a Siemens S7 PLC, for which the control software (and physical machine) was supplied by HERMA.
• Being able to develop and test the software. There was only one instance of the HERMA machine, and that was already installed on the client’s site (and it’s too big for our office anyway!); similarly we weren’t going to have enough cameras to let everybody working on the project have a full set of cameras.

Integrating with the hardware

Interfacing with the Cognex cameras themselves is relatively easy, as Cognex supply a full .NET SDK and set of device drivers to perform the “grunt work” of communicating with the cameras. However, the SDK is still relatively low-level: it lets you perform just about anything with the cameras, but obviously doesn’t have any business domain specific functions. On a technical note, the SDK is also a little bit “old school” and doesn’t make use of the latest and greatest .NET features – a decision which is completely understandable from a Cognex point of view who need their SDK to be useable by as many consumers as possible, but does mean that the SDK doesn’t quite fit neatly into a modern .NET application.

To work around both these issues, we developed a wrapper around the Cognex SDK that both encapsulates the low-level functionality in the Cognex SDK into the higher level business functionality that we needed for the project, and also presents a more modern .NET style interface, for example using lambda functions rather than delegates. The library has very much been designed to be a generic wrapper for the Cognex SDK so that we can re-use it in any future projects which use the Cognex cameras.

For the Siemens S7, we did a small amount of research and found the S7.Net Plus library. Once again, this enables low-level communications with the S7 PLC so we wrapped it in a higher level interface which implemented the business logic that HERMA had built on top of the S7 PLC.

Both libraries were tested when we had access to the hardware, the Cognex library by actually having a camera here at Control F1 HQ, and the HERMA library with assistance from HERMA who were able to set up a copy of their software at their site and give us remote access.

Developing and testing

As noted above, our big challenge here was how to develop and test the software without everybody having access to cameras and the HERMA machine. The trick here was simply to remove the requirement for everybody to have hardware: by developing a facade around the Cognex and HERMA libraries, we were able to make it so that we could use either the real interfaces to the hardware, or a emulator of each device which we developed. The emulators were configurable so that we could adjust their behaviour for various cases – for example, simulating a misread from one of the Cognex cameras, or a fault from the HERMA system.

The emulators were invaluable to us while developing the project: they allowed us to at one stage have three developers and a tester working on the project, and also to be able to have a demo VM which we could give to the client to let them test how the user interface was evolving, all without needing any hardware or for people to travel to anywhere – with the obvious savings of time and money all that brings.

So, did it all work?

Now, it’s all well and good developing against emulators, but emulators are no good if they don’t have the same behaviour as the real system. The moment of truth came when we sent our COO, Nick Payne, and Lead Architect/Developer, Phil Kendall, to the client’s site in order to put everything together on the real hardware… and the answer is that things worked pretty well. We’d be lying if we said everything worked perfectly first time, but the vast majority of the hardware was up and running within a day. The rest of the week was a pattern familiar to anyone who’s done integration testing before: mostly fairly quiet while we ran through the client’s thorough test plan (thanks Nick for his sterling work keeping everything running smoothly) interspersed with occasional moments of panic as the test plan revealed an issue (thanks Phil for some frantic and occasionally late-night hacking to fix the issues). By the end of the week, the client had signed the machine off to move into production, and Nick and Phil just about managed to get home at a reasonable time on Friday evening.

What did we learn?

From a Control F1 point of view, the most important knowledge we gleaned from this project was the work with did with the Cognex cameras and SDK – they’re some very nice pieces of kit, the SDK is a solid piece of code and we’ve now got the emulator framework we can use to accelerate development of any future projects using the Cognex cameras. Similarly, we’ve now got a way to interface with Siemens S7 PLCs which we can reuse for any future projects.

Other than that, the project reinforced a couple of good software engineering practices which we knew about:

• Do the less understood bits of the project first to reduce risk. By focusing our initial development efforts on the hardware integration side, we were able to reduce the uncertainty in our planning – this in turn meant that we were able to confidently commit to the client’s timescales relatively early on the project.
• Log everything. When you’re working with real hardware on a machine on a remote site, being able to get an accurate record of what happened when a problem occurred is invaluable. However, don’t log too much – if the camera is giving you a 30 line output, you don’t need to log the output as it passes through every level in the system as all you end up with then is a log file which is very hard to read.

Sound interesting?

If you’ve got a project which it sounds like we might be able to help you with, please drop us a line.