Re: [foxboro] Ladder Logic

  • From: "Campbell, John C" <john.campbell@xxxxxxxxxxxxxxxxx>
  • To: <foxboro@xxxxxxxxxxxxx>
  • Date: Thu, 3 May 2012 16:44:57 -0400

I brought this issue up many, many years ago at one of the user
conferences open session.  I came aware with two impressions:  a) I was
respectfully listened to, and b) nothing would happen as this would be a
costly change.

Within our company DCS's are a dying breed for a number of reasons:

a) yes they are more powerful than your standard PLC's, but is this
power really needed?
b) Brands "R" and "S" are considered hybrids.  Able to do anything a PLC
or DCS can do.
c) These PLC mfg's can do Function Block, Ladder and sequential logic on
the same controller.  Limit is only based on memory and the power of the
processor.  You can get a lot of programming in these processors.  Plus
these programs are easy to troubleshoot and understand.  Inter-mixing of
programs is logical and easy.
d) PLC vendors have integrated their safety functions on their back
planes.  Most safety functions dealing with machine guarding (ISO-13849)
are predominately ladder logic type.  This means you can work with one
system, one brand.
e) Technicans/Technologists from our community colleges have been
trained on brand R and S systems because these companies have "donated"
their systems and services to these colleges.  These graduates
understand ladder, they understand how to read, diagnose PLC's.
f) Foxboro's competitors are agressively targeting the process
industries.  Brand R regularly holds Process User conferences and I'm
seeing more and more petro-chemical involvement.  
g) instrument tech's prefer function block, electricans prefer ladder.
With companies optimizing their maintenance staff, we are quickly moving
to "control" tech's who must do both.

Foxboro has a great product, but if they don't make themselves more
flexible (PLB doesn't cut it). Then I won't be allowed to have them bid
on our future projects.  A few years ago I had one project that was
worth $5 Million to the vendor.  Foxboro was asked to bid (the divergent
phase of the investigation) and was quickly eliminated at their request
because 60% of the job was to replace a system using ladder logic.  The
process unit had two objectives:  a) do an in-kind replacement (no
improvements at this time) and b) they only wished to deal with one
brand. (this replaced 2 plc's and 1 DCS).

When I/A first came out (yes there are a few of us left), Foxboro was
able to quickly capture market share because the system was designed to
be flexible (hardened, no grounding issues and powerful).

The future are hybrid systems.  Vendor's who keep to one or two
languages will end up in niche markets.

Sorry for the rant but Foxboro has always been my choice, but this one
item is forcing me to abandon them.

John Campbell
my 2 cents

-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of Corey R Clingo
Sent: Thursday, May 03, 2012 4:01 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Ladder Logic

>> "We have found over the years that electricians have a much better
time
>> troubleshooting ladder logic.  Block logic becomes a problem when 
multiple
>> calc blocks are tied together all with many connections and 50 steps.

At
>> 3:00 in the morning no one ever has the correct documentation
either."

True. I like CALC* blocks, don't get me wrong. Maybe that's because I'm
a 
long-time HP calculator user. But I like to think it's because CALC
blocks 
are an interesting hybrid approach to logic -- basic combinatoric & 
sequential boolean logic AND some higher-level programming facilities, 
that run with bounded cpu/memory in one block scan. (I never bothered
with 
PLB; we always had PLCs available for fast processing needs, and CALC
code 
could do most everything else I needed.)


However, documenting CALC code is difficult compared to ladder and 
IEC61131-ish function block, and if you don't come from a good
programming 
background, they are not particularly easy to implement cleanly. As with

most general-purpose programming languages, deciphering someone else's 
code takes perseverance at times. The fact that the entire comment line 
that is stored in the workfile is not available to the detail displays 
doesn't help, either. All these cause lots of 3 am problems.


I'm not sure ladder is the answer, as I believe it was a transition 
language to make old-school electricians comfortable with those
newfangled 
PLC-thingys. But most contemporary PLCs (and increasingly DCS as well)
use 
some variant of IEC61131 function block. It seems in my experience to be

more easily understood by I/E personnel of all stripes, and is generally

straightforward enough for non-I/E personnel to grok. Like ladder, it's 
mostly inherently self-documenting; you don't need the Integrated
Control 
Block Descriptions Vol.1 handy to decipher the instructions and remember

how they manipulate the stack. And speaking of stack, there are no 
"hidden" variables or values, either.


Hey, I like Forth and HP calculators as much as the next geek. But maybe

it's time to think about moving forward. Using an industry standard to 
boot is a nice bonus.


Corey Clingo
My Own Opinion :) 

 
 
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
 
foxboro mailing list:             //www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
 
 
 
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
 
foxboro mailing list:             //www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
 

Other related posts: