It's an age-old problem. PLC programmers can't develop and test their code without the physical hardware. Or can they? One bright morning, while working on a baggage handling project, we decided to build our own simulator. It would mimic the conveyor hardware, connect to the PLCs, display output conditions, and log our data. It would also simulate random situations such as jams and removing a bag midstream.
Sound like a big task? The answer is yes. But it sure beats setting up hundreds of physical conveyors.
A conveyor operates in its own micro-world. It knows about the conveyor immediately before it and after it. It knows about the photo-eyes it has. And it knows about the control stations that can command it. Conveyors only have a few properties: the belt length, belt speed, what type of photo-eyes it has. That's it.
The challenge was that at any given time multiple conveyors are running with 1 or more bags on them. We really needed a way to have each conveyor run in its own thread of code. So we had to come up with a generic rule set, a way to manage the bags on the conveyor, and a way to pass bags off to the next conveyor.
Developing code that involves potentially hundreds of running threads is not for the faint-hearted. Trying to debug that code can be trying at best. To read the full story on how we used Akka.Net to tackle this challenge, visit the Petabridge blog by clicking the link below.