C
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
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