Last week, my colleague Tania asked me if I could help her to create a single question to quickly understand if a developer has ever dealt with a PLC. I have to admit that it has not been so easy to find distinctive characteristics between "regular" developers and PLC programmers. Probably this is due to the fact that I've only a limited experience on PLC-like devices (three years or some) and I've always used a single environment (namely, ISaGRAF). Below there are some ideas about the topic.
Watchdog
Another co-worker came up with this suggestion. In fact, when creating PC programs, you never have to deal with the WD. But it is not an exclusive of PLC programming. Usually, a WD is implemented in every device that is meant to run without human supervision and must provide a minimum level or reliability.
By the way, have you read my post about reliability in embedded systems?
Cycles Are The Key
After some thinking, I came to the conclusion that the real difference with PLC is that you are forced to split every function to smaller chunks, each of them is executed together with other chunks, derived from other functions.
The concept of thread does not exist. There is no scheduler that stops your function to let the others go on and, when you have to implement timers or delays, you cannot use sleep(). You have to ensure that loops don't run indefinitely and your program cannot block waiting for an event. If you are lucky, interrupts are provided by the system or the language, otherwise you must implement your own event dispatcher.
In the image, you can see that complex functions that need several long lasting operations to be executed must be split in different cycles to let the system run correctly. You should also notice that there is no automatic synchronization among functions.
OK, this is the concept, but, is there a way to simplify it in order to reduce it to a single question?
Maybe State Machines?
Well, FSMs represent an elegant way to execute a complex procedure across several cycles, but not the only one. For example, coroutines (when provided by the language) can do the same job with a more linear programming style.
To be honest, I have to admit that in my first months as PLC developer, I didn't use state machines nor coroutines. It has been not so easy but absolutely possible.
Conclusions
In the end, I've not been able to provide Tania an unique question which answer lets her understand the PLC programming experience of the intervisted. If you have suggestions or even the killer question, the comment area is here for you.
By the way, if you are wondering why this question is needed, Tania is organizing trainings on PLC programming and she needs to understand not only if a trainee is a developer but also if he already has some experience with PLCs.