Fwd: ENGR: Ladder Logic, Automation replacing people

C

Thread Starter

Curt Wuollet

I thought I'd forward this as something to think about. Does anyone know just how they do this on commercial PLC's. It sounds like someone who is concerned about being obsoleted but the point is valid. I've been thinking about how to make several front ends work. For now that can be separate but some sort of intermediate language would make it much easier to implement on line editing. My first thought is to have a simple list of equations to be solved. If the list were in core we could, with proper synchronization, edit it between cycles. How best to codify those equations would be good fodder for our computer
scientists.

Thoughts?
Too soon to think about this?


Regards

cww

---------- Forwarded message ----------
From: Dale Malony <[email protected]>
To: [email protected]
Subject: Re: ENGR: Ladder Logic, Automation replacing people

I'll preface this by informing you that I am one of those "jumped up techs"
mentioned earlier.

If someone has made these points already I apologize for repeating, but it
seems to me that this thread has overlooked some of the most important and
valuable reasons for using PLC/ladder logic versus a PC & PERL, PYTHON, C,
C++, VB, Delphi, JAVA, Pascal, Fortran or any other PC programming
languages. No need to address reliability of the OS most often used on PC's.

I'm talking about real time, real world scenarios. I can't even begin to
count the number of times I have found and fixed a program bug or
countermeasured a new problem WHILE THE EQUIPMENT IS RUNNING. It's almost
never necessary to stop a ladder application to edit it. You NEVER have to
experience the oft' repeated procedure of programmer of other languages -
stop the application, replace the old files with the new one (or more) you
just compiled on a separate development box, and restart it.

VB (as much as I hate M$) certainly has a good (the best?) development
environment for running and monitoring a program during the debugging
process. But it isn't remotely comparable to the "online Edit" experience
with a PLC.

If your company's production line controlled by software written in C or VB
is right now, right in front of your Maintenance Engineer's eyes,
experiencing a simple but crippling bug, what will he do? Is he going to
view the source code as it is running NOW and pinpoint the bug within a
minute? Will he have a fix for it up and running the next minute? No
way!! Even if he's the highest performing, most intelligent Maintenance
Engineer on the planet and actually knows C & VB and how to compile a
kernel - even if he wrote the program - he will be lucky to have fetched
his laptop in the time that he could have fixed the problem and sat down
for a cup of coffee. Really, how often is a PC with development software
other than ladder found permanently attached to production equipment or
very near to it?

I attempted to write a comparison of how software bugs other than ladder
logic are often handled, but responses range so widely (from fair to
completely unacceptable - see M$) that it would be like Motor Trend writing
a HEAD-TO-HEAD performance review of a Viper -vs- my John Deere
mower. When I program systems integrating both (and require me to debug
both) the PLC problems can be fixed shortly after they appear and I end up
adapting the PLC to the PC whenever possible for the sake of development
efficiency. Especially after put in use but still buggy, PC app changes
are patches developed during production and installed at breaks or
weekends. What would take minutes or hours with online editing in ladder,
instead takes days or weeks depending on equipment access.

SOME Advantages of ladder:
1. Real-time monitoring of the entire source code
2. Real-time editing off RUNNING programs.
3. Fast troubleshooting
4. No need to recompile/ reboot, or re-anything short unless you hardware
needs changed.
5. Simplicity/reduced learning curve enables larger selection of people to
learn it.
6. One of many technologies that enables a tech to do today what yesterday
required an engineer.
7. The more people who can understand technologies, the more technologies
can be selected, implemented and supported. The more they're used, the
less they cost, and used even more. Within limits, the vast selection of
easily understood (though amazingly complex) technologies (should, if
applied with justification and well applied) improves quality, reduces cost
to produce, and on.
7. Frees experts from day-to-day problems and be utilized more effectively.
8. Larger number of programmers/troubleshooters and debuggers means more
ideas and more problems solved. (OK, depending on mgmt, it can mean more
problems created too.)
9. Mgmnt perception of simple equipment adaptability enables more
agressive approach to market. New products are being brought to market
faster and at less cost than ever. One factor in that is
10. Did I mention ONLINE EDITING !?!?!?

*****************************************************************
Before posting, please read http://www.control.com/control_com/alist/faq_html.
Got code? Add it to the PLCArchive at
http://www.control.com/control_com/PLCArchive/The Automation List is managed by Control.com Inc.


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M

Michael R. Batchelor

On Sun, 29 Jul 2001, Curt Wuollet wrote:

> I've been
> thinking about how to make several front ends work. For now that can
> be separate but some sort of intermediate language would make it much
> easier to implement on line editing.

An intermediate language sounds like p-code to me. A lot of people hated it, but it worked.


> My first thought is to have a
> simple list of equations to be solved. If the list were in core we
> could, with proper synchronization, edit it between cycles. How best
> to codify those equations would be good fodder for our computer
> scientists.

I'm not sure how to do online edits, but the concept of backing-store for
graphics comes to mind. You'd need a scratch pad to work in, and then
substitute before the next scan. Clearly the idea of having a p-code layer saves you from the trap of having to recompile and relink an object module.

MB


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C

Curt Wuollet

"Michael R. Batchelor" wrote:
>
> On Sun, 29 Jul 2001, Curt Wuollet wrote:
>
> > I've been
> > thinking about how to make several front ends work. For now that can
> > be separate but some sort of intermediate language would make it much
> > easier to implement on line editing.
>
> An intermediate language sounds like p-code to me. A lot of people hated
> it, but it worked.

Exactly, but now we have sufficient resources to hide it from view. What I was thinking of was a sort of one shot flash interpreter that gets
called once per cycle. I wasn't too fond of UCSD Pascal but, it did work. Turbo Pascal was a vast improvement. How to do this efficiently is where the magic comes in. It technically would be an interpreter but we should use a different term for PR purposes. If we keep it to logic and let the solver maintain state, etc. it could be fairly small, limited and fast. Those p code engines from when efficiency was crucial might be a good place to start.

> > My first thought is to have a
> > simple list of equations to be solved. If the list were in core we
> > could, with proper synchronization, edit it between cycles. How best
> > to codify those equations would be good fodder for our computer
> > scientists.
>
> I'm not sure how to do online edits, but the concept of backing-store for
> graphics comes to mind. You'd need a scratch pad to work in, and then
> substitute before the next scan. Clearly the idea of having a p-code
> layer saves you from the trap of having to recompile and relink an object
> module.
>
> MB

Regards,

cww



_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S

Scott Cornwall

Curt and others,
There is a lot of reality in what this guy is saying. This is the nature of the industry.
Of his 10 point advantages of ladder, read them all as requirements for a PLC - they are not solely attributable to Ladder language.
Points 5-9 apply to any good technology.
Points 1,2,3,10 are very important. Any automation programming system that can not do this will not get acceptance.
Point 4 - I'd modify that one - it is OK to recompile the program source, as long as it can be swapped into the running controller without interruption of the process. It is also necessary that data in the controller does not get lost - i.e. not re-initialized.

How is it done in a real PLC - traditionally an intermediate language has been used, but it is also possible to achieve the same result when compiling to native code. It is the design of the execution and logic engine that is critical.
Early PLCs used bit slice processors and logic solving circuits to effectively execute the intermediate language. Advances in processing power now make it possible to execute the IL entirely within the main microprocessor, although many PLCs still have a VLSI chip for assiting with
logic execution.

These comments are based on my own experience of developing state based PLCs, I have done one generation of product that works on an intermediate language and another generation that works with compiled native code. The big name PLC brands work the same, I have looked inside products using both methods.

You are on the right track Curt. The scanning of the execution/logic engine would be a sequence something like Output scan, Input scan, Housekeeping, Program scan. Within the housekeeping slice (among other things) it is
necessary to make all program changes in one contiguous hit. Various mechanisms can be derived for making those changes but it is important that
the actual change to the running program all takes place within a single scan.

If you are taking the intermediate language approach then you will probably want something like a binary version of the IL statements already defined in PERL and an execution engine that operates on these statements (efficient
interpreter of some kind, probably not byte code). An online editor needs to understand the structure of the stored binary code and be able to (at least) modify references, constants, etc. Being able to swap one chunk of binary code for another is required for more significant program changes - again several mechanisms are possible, a chunk could be a rung of ladder, or a state, or a function block, etc.

There is another factor in having an intermediate language in the PLC. Inevitably after a PLC has been running trouble free in a factory for
several years the original program source code gets lost. With an IL it is possible to reconstruct the program by uploading out of the PLC. A PLC that does not allow upload of a program causes very emotional responses in the
technicians trying to fix a system. If a compiled code execution method is used then there needs to be some other enforced method of storing source
code in the PLC (which achieves a better result in the end anyway if full program source is always available).

It is not too soon to think about this, it is core to the architecture of the system.

Regards,
Scott Cornwall
_________________
www.sentech.co.nz

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M

Michael R. Batchelor

On Sun, 29 Jul 2001, Curt Wuollet wrote:
> "Michael R. Batchelor" wrote:
> > An intermediate language sounds like p-code to me.
> Exactly, but now we have sufficient resources to hide it from view.
> What I was thinking of was a sort of one shot flash interpreter that
> gets called once per cycle.

My guess is that the overhead for retokenizing the whole thing every scan would be horrendous. If we think in terms of ladders, then it really is a straight sequentially run collection of totally independent instructions. In other words, if I want to edit rung 14 then there isn't any change at all to rung 13 or rung 15, just rung 14. So, if the rungs were to be compiled at runtime into individual little chunks which run sequentially, then you could edit a rung(s) in the scratch pad and compile it when ready to test.

It's not like the rungs pass arguments around to each other and examine result codes. The action of a rung modifies the values in the state table,
and if the next rung happens to examine that value in one of its conditions it gets it from the state table, not from some "output" of the
previous rung.

How well this model translates to allowing online edits in things besides ladder logic I haven't tried to think through yet. I'm sure there is some
situation where it won't work worth a hoot.

MB

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
B
> "Michael R. Batchelor" wrote:
> >
> > On Sun, 29 Jul 2001, Curt Wuollet wrote:
> >

> > An intermediate language sounds like p-code to me. A lot of people hated
> > it, but it worked.
> Exactly, but now we have sufficient resources to hide it from view. What
> I was thinking of was a sort of one shot flash interpreter that gets
> called
> once per cycle. I wasn't too fond of UCSD Pascal but, it did work. Turbo
> Pascal was a vast improvement. How to do this efficiently is where the
> magic comes in. It technically would be an interpreter but we should use
> a different term for PR purposes. If we keep it to logic and let the
> solver
> maintain state, etc. it could be fairly small, limited and fast. Those
> p code engines from when efficiency was crucial might be a good place to
> start.

These days, "p-code" is quite common and even acceptable. As long as it's not called "p-code" :)

Witness Java ("bytecode" executed on the JVM), Python (same idea, different implementation), Perl .... You get the idea. As long as one uses the term "virtual machine" instead of "p-code" interpreter, all is right with the (computing) world.

So the PLCVM ought to be a natural. Ladder logic, GRAFCET, and other language "front-ends" all compiling to the same bytecodes and running
on the PLCVM. Crazy? Nah: http://www.softplc.com/history.htm

BTW, if you haven't done so, check out all the "alternate" languages that run on the JVM. Everything from Ada95 to Z-code, so it's not some
wild, way-out concept. http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html

That, of course, brings up another question: why invent Yet Another Virtual Machine?

--
Bill Meahan WA8TZG - Westland, MI EN82hh
Tube Audio, QRP, Boatanchors & Woodworking
UNIX Weenie and Netizen for over 15 years
Microsoft mail products: Just say, 'No'

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Scott:
> An online editor needs to understand the structure of the stored binary
> code and be able to (at least) modify references, constants, etc.

I'm not sure if that's really worth it.

It might be better to get a really good version of:

> Being able to swap one chunk of binary code for another is required for
> more significant program changes - again several mechanisms are possible,
> a chunk could be a rung of ladder, or a state, or a function block, etc.

These days, a compile only takes a few seconds[1], so once there's a good interface for changing chunks of the program, there wouldn't seem to be much point making a separate interface for changing little pieces. Just use the chunk interface.

If a constant needs to be changed more quickly than that, it shouldn't be a constant (because it's not constant - it changes). It should be put into the global map and changed through that.

Jiri

[1] comparable with uploading the program to a conventional PLC
--
Jiri Baum <[email protected]>
http://www.csse.monash.edu.au/~jiribvisit the MAT LinuxPLC project at http://mat.sf.net

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Top