RTOS in a PLC program?

R

Thread Starter

Rohan Sarker

Can anybody please help me in telling me if a RTOS is implemented in a typical PLC program?
If yes,what are the different components of such a PLC program?
 
J

James Ingraham

I'm not sure your question makes any sense. Most PLCs have some RTOS running, which is what is interpretting your ladder logic. It is not possible, however, to write a new OS (real-time or not) in ladder or the rest of IEC 61131-3 languages.

Most ladder programs execute in "real-time." So if your question is not, "How do I write an RTOS in a PLC?" but "How do I make sure my PLC program executes in real-time?", then the answer is simply "It's already real-time.

-James Ingraham
Sage Automation, Inc.
 
Not really, most PLC code is read from top to bottom just like most other programs and therefore is not "real time". That is why there is a scan time (RLL), this is the time for the program to "scan" the code...............in the case of an AB PLC, the IO is not updated until the end of scan (I know there are ways to make this happen earlier) but basically you scan all code and then change the IO accordingly at the end..........

This can be 10-150 ms usually in a PLC 5, much quicker in a Controlling but not "Real time" all the same...........this is why you need high speed counter cards for instance, because the program is off in the middle of a scan and then a count comes in and the PLC would miss it, the high speed counter card has an on board "brain" to keep them and then pass the counts over in a program scan.....

Dave Ferguson
DAVCO Automation
"The Developing Application Value Company"
 
E
What's real time anyway? At the lowest level of code it generally runs in a top down manner anyway. Even RTOS's have latency issues and context switch times that might be in the order of milliseconds. The issue becomes a matter of determinisim. Does the program respond to suit your needs? If it does, its real time.
 
S

Steve Myres, PE

>The issue becomes a matter of determinisim. Does the program respond to suit your needs? If it does, its real time. <

You took the words out of my mouth. I think most peoples' concept of "real time" actually means deterministic handling of process events without the possibility of the OS taking a break to defrag the hard disk while you're executing a high speed high precision motion.

Disclaimer: I'm not throwing any rocks at PC control, nor saying real time control cannot be done on a PC (when set up by an automation professional), just giving the definition of "real time".
 
C

Curt Wuollet

Well, I stand corrected :^) If you are running something with events that last long enough, and a required response time about like the post office, you could do an RTOS on a PLC in it's native language(s) Some do have a calendar feature you could exploit for guaranteed response times. And yes it would meet the requirements of the rather vague term real time and could be made deterministic in context. After all, you can drive screws with a hammer. I however, would rather spend the time with something like RTLinux or RTAI or QNX which are surely adequate used in PLC time contexts. And today, with a cornucopia of very cheap, if limited, HDD replacements for plain embedded Linux, I might even look at the luxury of coding in Bonehead C (tm.) without exhaustive attention to timing and determining if that would do the job. Competing with PLC's is not a very stringent timing environment with entry level processors > 100 mips. The problem with PC control is mostly the selection of software. Once you get over the "everything must be part of a GUI" deviation, you realize that there's no particular reason a 1.0 Ghz processor shouldn't be able to keep up with PLC speeds.Perhaps not deterministic in the strictest sense, but fast enough where you won't notice in most applications. It's a case of everyone using a Windows yardstick to measure PC control. That's just silly. If something's too slow on today's processors, you don't have a hardware problem.

Regards

cww
 
Ah, yes but if for instance in an Allen-Bradley, I have 25 subroutines and they are conditional............I cannot control when say subroutine 22 is going to activate with predictability...............IE it may happen every time the Operator presses a button and may miss a count in my example above (high speed counter)......so therefore it is not "real time" because it is not "deterministic"..........wow I know all the jargon also.........

The theory behind RTOS are systems that can be interrupted and can give "attention" to an "interrupt" and still keep doing what they were doing, IE true "multi-tasking" (wow, more big industry jargon) but in reality most PLC do not follow this .......(preemptive multitasking vs asynchronous multitasking or some other industry jargon...substitute here)

I was trying to avoid getting into jargon but you dragged me in........

No Most PLC's are NOT REAL TIME OPERATING SYSTEMS.............

If you would like to prove me wrong, I will write a program that will quickly shut down your plant..................

Dave Ferguson
DAVCO Automation
 
J

James Ingraham

Dave Ferguson:
> No Most PLC's are NOT REAL TIME OPERATING
>SYSTEMS.............
> If you would like to prove me wrong, I will
>write a program that will quickly shut down your
>plant..................

That poorly written programs can crash a system is hardly limited to PLCs, or to Windows for that matter. That doesn't really have an impact on whether the system is real-time or not.

And while you seem not to think much of jargon and buzzwords, I have to concur that when you're trying to decide if a system is real-time, you'll have to define it for the process you are dealing with. Can PLC keep up with a high-speed encoder; no. Can it control a 100 ft/min conveyor line; yes.

The original question still doesn't make a lot of sense to me. But I doubt that we've given the guy who asked it much help.

-James Ingraham
Sage Automation, Inc.
 
R

Ranjan Acharya

I think that was Erich's point. You just addressed it in a different way.

If it responds fast enough - all the time - then it is real time for your needs. If your fastest plant event occurs every 100 ms then a scan time absolute maximum of say 40 - 45 ms (assuming a traditional linear scan) will make your system real time. For PLCs that allow code to be broken up into time-dependent blocks (e.g., organisational blocks with an S7), then overall scan time is less of a concern. Depending on the flavour of PLC you use then you easily can process short blocks of code down to a few milliseconds. Any PLC that does a good job with IEC 61131.3 will allow "full execution control" of programme execution units.

It takes time for nerve signals to reach your optical processing centre in your brain after they leave your eye. Your eye is fooled by a 24 frame per second film into thinking that it is real time. Your ears cannot process much above 20 kHz (or so) so a 40 kHz sampling rate (or so) is OK for real time audio.

I think the original thread has been a little bit lost. Writing an "OS" in a PLC programme is not really something that one would normally do. The PLC already has an RTOS for you. You just use it and make sure that your code responds fast enough so that you don't lose anything.

RA
 
Erich Mertz:
> > What's real time anyway?
...
> > The issue becomes a matter of determinisim. Does the program respond
> > to suit your needs? If it does, its real time.

Dave Ferguson:
> Ah, yes but if for instance in an Allen-Bradley, I have 25 subroutines
> and they are conditional............I cannot control when say
> subroutine 22 is going to activate with
> predictability...............IE it may happen every time the Operator
> presses a button and may miss a count in my example above (high speed
> counter)......so therefore it is not "real time" because it is not
> "deterministic"..........wow I know all the jargon also.........

Well, "real time" simply means that you can take into account timing requirements. In your hypothetical example, you would end up calculating the maximum scan time for the program (taking the longer path on each condition), and checking that it's fast enough. If it isn't, you'd have to modify the program somehow, for instance ensuring that they can't all 25 activate in the one scan, or get a faster PLC.

It is reasonably easy to write programs that can be guaranteed to run in no more than x time.

In contrast, a general-purpose operating system does not allow that: any instruction can take potentially significant time. For instance, the OS can swap a subroutine out to the swapfile and then spin the disk down to save battery power. A call might then take several seconds while the disk spins up rather than the 3 clock cycles specified in the manual.

> The theory behind RTOS are systems that can be interrupted and can
> give "attention" to an "interrupt" and still keep doing what they were
> doing, IE true "multi-tasking" (wow, more big industry jargon) but in
> reality most PLC do not follow this
Indeed, but that's because they are not multi-tasking, and says nothing about whether or not they are real-time. Not being multi-tasking simplifies this problem immensely (and a lot of other problems, too).

> No Most PLC's are NOT REAL TIME OPERATING SYSTEMS.............

Hmm, I suspect that most provide at least some rudimentary support for real time, in the form of tables in the manual that can be used to add up the cycle time. Perhaps not the most user-friendly way of doing RT, and somewhat tedious to use, but workable.

> If you would like to prove me wrong, I will write a program that will
> quickly shut down your plant..................
At that, you don't have to resort to timing subtleties - and on the other hand no amount of RT in the OS will save you from yourself. Indeed, on the contrary, it gives you that many new ways to err.

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
 
A

Armin Steinhoff

Hi Rohan,

>Can anybody please help me in telling me if a
>RTOS is implemented in a typical PLC program?
>If yes,what are the different components of
>such a PLC program?

I'm convienced it isn't possible to write a Real-Time-Operation-System with a typical PLC based language.

First of all: you need access to _all_ hardware resources of the PLC in order to schedule the use of these resources ... but these resources are already managed by the 'operating system' of the PLC.

PLC languages also dont have constructs in order to handle such hardware or software resources.

The opposit aproach is possible: use on top of a piece of computing hardware a RTOS as a base of a PLC.

Best Regards

Armin Steinhoff
 
A

Armin Steinhoff

At 17:09 30.12.02 -0500, Erich Mertz wrote:

>What's real time anyway?

It's processing of data or events which results are only valid if they are provided in a timely manner.

That means a correct computed result is invalid if it is not available at the rigth time (deadline).

>At the lowest level of code it generally runs in
>a top down manner anyway. Even RTOS's have latency issues and context
>switch times that might be in the order of milliseconds.

It's with modern PC processors in the range of NANO seconds :)

> The issue
>becomes a matter of determinisim. Does the program respond to suit your
>needs? If it does, its real time.

Nothing would be landed on the MARS if this would be a sufficient definition of REAL-TIME :)

Best Regards

Armin Steinhoff
 
J
On the contrary, that _is_ the definition of real-time. If you define real-time as zero latency, then RTOS is impossible. On the other hand, the generally accepted definition (AFAIK) of real time is simply a system that responds faster than you will ever need it too. If the response time, or latency, is smaller than the window in which you need it to be, then it is real time, and Mars landings, or whatever else, are fully possible. Note that this definition does not give a hard value to the minimum response time. For some applications, the response time needs to be in the nano-second range, in other operations it is much longer. For example: I have a system that requires a rack of parts to be loaded into a machine every 2 minutes. For this application, an operator can provide "real-time" response, since he or she is capable of responding to the "insert cartridge" light within the time frame available before the machine runs dry. Therefore, my RTOS is some guy (or gal) sitting on a stool waiting for the light to turn on.

Your mileage may vary, which is pretty much the point....

--Joe Jansen
 
V

Vladimir E. Zyubin

Hello List,

As well as I see, the new round around "real time" has been begun...

So, I dare to repost my two cent to the topic:

"Real time" is a good example of bad terminology, the word ought to be eliminated from the professional lexicon... ASAP.

Happy new year!

--
Vladimir E. Zyubin mailto:[email protected]
 
J

James Ingraham

Me:
"It is not possible, however, to write a new OS (real-time or not) in ladder or the rest of IEC 61131-3 languages."

Jiri:
"Sure it is. It'd just be very very painful, and not all that useful. Which is why nobody does it."

Armin:
"I'm convienced it isn't possible to write a Real-Time-Operation-System with a typical PLC based language."

Jiri's point is noted; there is nothing that prevents the IEC 61131-3 langauges from accomplishing any programming task. However, Jiri is being pedantic rather than helpful. Armin's point is more accurate than my own: the IMPLEMENTATION of the languages frequently place restrictions that woule make the job difficult or impossible.

Of course, even in the situation of a severely limited implementation, it is possible to create an OS, though it must be running on top of the existing OS. This is not a trivial matter, and will be severely limited. For example, if the underlying OS has no file system, you might be unable to write one. Still, Jiri's point stands; writing an OS is doable.

Frankly, though, the difficulty level is so high and the limitations will be so severe that "not possible" is closer to the truth than "possible." You will not be able to come up with a competitor to VxWorks or QNX using RSLogix 500 or STEP 7.

If your kid asks you "Can I go to the moon?" you should probably say, "No." Yes, it's technically possible that your kid could end up on the moon some day. But he's not asking if he works hard, gets a strong technical degree, joins the military, becomes a pilot, gets accepted into astronaut training, NASA plans another mission to the moon at just that time, he gets selected for the mission, and nothing goes wrong in the meantime, THEN can he go to the moon? He wants to know if his tricycle will get him there with 15 minutes of pedaling. The answer is NO!

-James Ingraham
Sage Automation, Inc.
 
A

Armin Steinhoff

>Hello List,
>
>As well as I see, the new round around "real time" has been begun...
>
>So, I dare to repost my two cent to the topic:
>
>"Real time" is a good example of bad terminology, the word ought to be
>eliminated from the professional lexicon...

ASAP.
Not the term 'Real-Time' should be removed ... but the unprofessional use of it.

>Happy new year!

Ditto :)

Best Regards

Armin Steinhoff
 
V

Vladimir E. Zyubin

Hello List,

Just a remark.

You are right when point out the IMPLEMENTATIONS. But the original question can be formulated as: can OS functionality be expressed by the linguistic means.

AFAIK, the IL in original version is an Assembler of a processor. The ST is an avatar of something like PASCAL.

In the second case, to write an OS in PASCAL, some object codes are demanded (to work with interupt vectors, and so like... BTW, as well as for C-language case... because second generation languages are platform independant)

In the first case I see no principial difficulty.

(Though I see no reasons to write OS in the languages)

--
Best regards.
Vladimir E. Zyubin mailto:[email protected]
Wednesday, January 08, 2003, 1:28:27 PM
 
Top