Re: [foxboro] Ladder Logic

  • From: Richard Peck <lovetomix@xxxxxxxxx>
  • To: foxboro@xxxxxxxxxxxxx
  • Date: Fri, 4 May 2012 06:25:08 +1000

Hi,

I'm fairly new to the IA DCS world... my background is based in PLC
logic (but I avoid ladder like the pox)...  FBD is the winner for me
every time!

We have IEE on site, version 2.0 and upgrading to 3.1 soon (as soon as
we can get a person dedicated to the task).   The IEE editor for Calc
Blocks is quite nice.  It has a graphical view which makes debugging
simple.  You can also see the data live.  As a method of retaining the
same blocks forever this really bridges the gap well.

The graphical view also helps us non-polish people to understand the
RPN a little better... If this was an Australian product we would
simply call it either Tasmanian logic or Kiwi logic... what is worse
about it is that after a while you actually get used to using it...
and then after a while you actually write logic using it instead of
the graphical view...  talk about making a guy feel dirty :)

Something I would like to see in the future (PER already raised)...

When the next CP is release I would like to see some SERIOUS block updates....
eg:
CALCA with 100's of coding lines, with scaling and alarming... really
it becomes a free flow FBD logic block
PIDA with output characterisation...
Ideally a survey would be conducted and we can all put in ideas :)

Just some food for thought :)

Richard

On 4 May 2012 06:00, Corey R Clingo <corey.clingo@xxxxxxxx> wrote:
>>> "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: