Reputation: 11
I'm just trying to understand typical PLC execution cycle. I have programmed a few PLCs and the PLC scan time is what we set for the sequential execution of a program. Recently I'm exploring Embedded controllers such as PIC18, 32 and developing programs in it. This seems to be a totally different world than PLCs; especially when it comes to program execution.
PIC or ARM microcontrollers can offer sequential as well as multithreaded programs to run on it. Just wondering if this is something possible on a PLC platform
I explored a little bit on internet however I'm looking for more clear answers
Upvotes: 1
Views: 775
Reputation: 415
PLCs
are a large area, i would not concentrate if plcs
are capable of running multithreading applications or not, i would concetrate on PLCs
vendors.
For example i have worked with two vendors of PLCs
:
1. Siemens
Siemens does not allow multi threading applications per se, it is very difficult to manage or to isolate cores or to define specific tasks, nevertheless you can implement multithreading "like" applications creating hardware interrupts or also it is possible to separate scanning time from motion tasks and logic tasks (something very similar to multithreading).
2. Beckhoff (Twincat
)
Twincat
allow the user to have control over how to define tasks, this tasks are no other than threats but with a priority manager, the task with the highest priority will have preference executing the code assigned to it without being interrupted, the task can also run in an isolated core to ensure the maximal power from the core to be delivered, this allows to run multiple logics in different threads and also it is possible to create interfaces to communicate between tasks (threads
).
The tasks allow you to modify the executing time of your code assigned to that task.
More over the topic can be found here:
https://infosys.beckhoff.com/english.php?content=../content/1033/twincat_bsd/5735307787.html&id=
https://www.youtube.com/watch?v=P9uUgT8EhUM
Upvotes: 0
Reputation: 3156
As I like to say, one person's realtime control system is another person's batch system.
PLCs were developed long before fast processors. Also, PLC's are basically controlling real-world I/O, not some large multi-user database.
Hence, its logic execution architecture is "PLC Logic Scan" based. Here's an article Understanding PLC Scan
So from a software control perspective, PLC scan is the "detent" that applications care about because your I/O driver can't be changed any faster than that (let alone the speed of the physical devices they are hooked to). So 1ms is considered "fast enough" for 95% of the PLC applications out there.
If you are wanting to do "high speed" stuff (1 MHz pulses, for example), some vendors offer HSIO (High Speed I/O) modules that do that on a co-processor. But basically, a logic I/O scan that takes a few milliseconds is "good enough" from a "control" standpoint (maybe not microprocessor standpoint, but that is just a means to an end).
Also, because of this, the program model is quite different than what you are used to. For example, FOR/NEXT loops are usually BAD (if they are blocking, your scan time can jump up greatly for that one scan looping through 1000 strings trying to find a match, but there are work-arounds for things like that). You must "unlearn" what you think you would do in C or C++, and think in terms of the I/O logic scan.
There are tutorials out there that help you "think like a PLC programmer". PLCs actually take care of a lot if care-abouts from an I/O standpoint (and believe it or not, from a software standpoint also, like maintaining discrete input state intra-logic scan so if you look at the same DI multiple times in your logic, its state will be the same throughout THAT scan)
Upvotes: 3