PLCs and network comms: conceptual foundations

Question

According to this question, it is possible to send a TCP/IP message from a PLC to a PC using ladder logic. What? I'm sure this makes sense to people from the PLC world, but I'm struggling to make sense of it coming from a C/C++ embedded systems world.

Can someone explain, or point to an explanation, of exactly where relative to the PLC such comms takes place? Is it from within the PLC scan cycle, in which case... how are waits, delays, timeouts, retries, etc handled without extending the scan cycle? Equally, is there any way in which such functionality is consistent with the electronic "power rails and switches" metaphor of ladder logic, or does that metaphor stretch to the point of breaking down?

It strikes me that there are tasks (not necessarily comms tasks) that would be hard to turn around inside the few milliseconds of a PLC scan cycle. Extending that cycle for the sake of such tasks seems untenable. So are there ways and means in the PLC world to get these tasks done outside the PLC scan cycle that somehow integrates their input/output/control into the PLC scan cycle? I suspect this is the case, but have not found anything that clearly states it.

Answer 1

how are waits, delays, timeouts, retries, etc

You just don't do that stuff in one cycle. Instead of suspending the thread, you check whether it's time to move on, and if not, you proceed to do the rest of the cycle immediately, skipping whatever you wanna do once you're done waiting.

Any non-immediate (blocking) task is done in multiple cycles, be it high-level data I/O or some actual "real world" process. Communication calls, e.g. read(), write(), send(), receive() etc., are non-blocking, sometimes even asynchronous. In LD and other (IEC 61131-3) languages it's all handled using flags, triggers, etc.

Here is some real code that sends request and reads measurement data from a digital sensor over an RS-485 serial port. Notice there are no blocking calls and it doesn't matter how short scan cycle is.

Answer 2

The issue is that PLC's were designed for controlling their tasks and send real time data via ProfiBus, Ethercat, ProfiNet etc.. TCP/IP communication is indeed quite cumbersome when looking from computer programming way.

What helped me through is to read the very thick manuals of communication from and to PLCs. Especially things like the amount of data that can be send or read in one cycle(!). And use the wizzards as much as possible. Check the support sites.

The positive thing of PLCs manufactures is that they have a support that is more willing to help than the software world. Just try, and ask them if the can help you further.

Answer 3

Using libraries provided by the manufacturer of your control system of choice, most of that gets handled at a lower layer asynchronously and you don't have to deal with it in your PLC code (which is generally 'real-time', synchronous, and blocking by design).