Re: [foxboro] Determining Forces in PLB + the perils of ladder logic

Thanks Kevin,
        Yes we have installed that, and many other QF's and have now
minimized, but not eliminated that problem.  Foxboro has been
continually tweaking the iom82 file that is the EEPROM image for the
FCM10E, DCM10E, FBI10E, and WFCM10E.  We have changed the iom82 from
1.02, 1.03, 1.04..... all the way to the current 1.16.  Sometimes we
were told to go backward, (from 1.13 to 1.11).  We have tried it all as
Foxboro continues their "Search for the Holy Grail.
        At this point we are moving everything to the MESH using 200
Series I/O with very minimal use of PLB Ladder Logic.  When we started
configuring them in 1988 my Modicon PLC background made ladder logic
understandable and very useable to me.  In addition, the extended
discrete FBM's were cheaper to buy.  I didn't realize we would
continually be plagued by Foxboro's inability to support/manage the
software issues associated with it.  During that time, we have twice
received new software that failed to correctly map the CIN/CO's within
PLB's running in discrete FBM's.  This really screwed us up one time as
we were unable to restart our process after a software upgrade.  The
latest incident that I recall was when we received a new FBM242 that was
EEPromed at 1.05 instead of 1.04 like the one we were replacing and the
I/O mapping to CIN/CO's was messed up in the ladder.  Luckily we were
able to burn it back to 1.04 and all was well.
        The PLB/Ladder Logic still provides a solution for applications
that require single digit ms control response but all associated I/O
must be able to fit in a single FBM in order to accomplish the task.
For ms control of equipment requiring larger discrete I/O counts David
Johnson's suggestion of using PLC's and interfacing them to Fox IA with
FDSI's running a controllogix interface is a possible solution.
        In the end, it has been our experience that PLB ladder logic is
treated like an orphan-step-child from within the Foxboro organization.
Rather than fitting it with a new set of clothes they keep deciding to
put additional patches over the holes.  The phrase "You can't fight City
Hall" comes to mind here and so we are attempting to eliminate the use
of PLB/Ladder Logic.  My feeling is that if Foxboro could wave a magic
wand and make all PLB/Ladder Logic disappear from all of their installed
systems they would do it in a heart beat.  That would mean they wouldn't
even have to put a patch on their orphan-step-child's clothes any more!
Unfortunately, I don't think they have a reasonable and cost effective
way to replace the functionality the PLB Block provides.
Just one mans opinion, and you know what they say about opinions...

Cheers,
Tom VandeWater

-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of Kevin Fitzgerrell
Sent: Wednesday, February 21, 2007 7:20 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Determining Forces in PLB

Tom,

There's a QF (QF1007465) out that fixes the CP60 fieldbus problem with
PLB blocks causing the system monitor alarms.  It's an easy QF because
it's just a new image for the FCM10E, DCM10E, FBI10E, and WFCM10E, so
can be done online (just eeprom update one side at a time).

My biggest recent complaint with PLB blocks is that with QF1005621
(which fixed some important faults) Foxboro decided that having more
than one PLB block per FBM would cause error messages (duplicat output
channel warnings) and cause the blocks to show bright green in select.
 Since multiple PLB blocks per FBM has previously been an acceptible
and well documented option (although it required the obvious
engineering to not actually use duplicate output channels, and isn't
necessarily a good idea) it's really irritating to suddenly have
warnings and errors as a result.  I wish Foxboro had elected the
smarter solution and actually check if the multiple PLB blocks were
USING duplicate output channels, but that would have been more
complex.

Regards,

Kevin FitzGerrell



On 2/22/07, tom.vandewater@xxxxxxxxxxxxxx
<tom.vandewater@xxxxxxxxxxxxxx> wrote:
> David,
>        Yes!  That would be nice.  I hope someone else has the answer.
> There has to be a bit or integer in the memory of the FBM that is set
> because the PLB Monitor displays a differentiating color, red, when a
> contact is actively forced on and a different color, blue, when forced
> off.  I wonder if the force info is also stored somewhere in the host
> filesystem?
>        The only ICC ladder file I am aware of is on the CP host stored
> in:
> /opt/fox/ciocfg/PLBs_CMPD_Name/PLBs_Blockname.p  We are also
interested
> in accessing current timer or counter values that are running in the
PLB
> ladder if anyone knows how.
>        As an aside, even though the ladder logic is continuously
> executed in a 3-5 ms scan, we are migrating away from running it
because
> of the many issues such as this that have continually plagued us with
> PLB's since we started using them in 1989.  The latest in a long line
is
> that FBM's running ladder logic on a loaded CP-60 fieldbus can
> repetitively cause System Alarms such as the following:
>
> 02-21-07 10:43:33      0  SYSMON =3D3D SYS21A  21CP05  Equip =3D3D =
140304
>
>  SYSMON -00069 Single PIO Bus Access Error on B
>
> 02-21-07 10:44:23      0  SYSMON =3D3D SYS21A  21CP05  Equip =3D3D =
140304
>
>  SYSMON -00071 Single PIO Bus Access Recovery on B
>
>        We have already reconfigured a lot of our ECB8/Software Type 8,
> (Ladder Logic), FBM's to be ECB5/Software Type 5, (CIN/COUT),
compatible
> and use dedicated CIN and COUT blocks for each IO point instead of the
> ladder embedded CIN/CO's.  More blocks, slower scan, but more reliable
> and document able.
>
> Cheers,
> Tom V.
>
> -----Original Message-----
> From: foxboro-bounce@xxxxxxxxxxxxx
[mailto:foxboro-bounce@xxxxxxxxxxxxx]
> On Behalf Of David Johnson
> Sent: Wednesday, February 21, 2007 2:03 PM
> To: Foxboro@xxxxxxxxxxxxx
> Subject: [foxboro] Determining Forces in PLB
>
> Hi List,
>
> Is there a way to get a force list for a PLB without having to =
look=3D20
> at each line and visually determine if anything is forced?  We'd
like=3D20
> to be able to generate a report of PLB forces (the actual item =
that=3D20
> is forced, and if it is forced high or low), but I have no idea =
how=3D20
> you would do that.
>
> Thanks,
> David
>
> =3D20
> =3D20
>
_______________________________________________________________________
> 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
> =3D20
> foxboro mailing list:
http://www.freelists.org/list/foxboro
> to subscribe:         =3D
> mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3Djoin
> to unsubscribe:      =3D
> mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3Dleave
> =3D20
>
>
>
_______________________________________________________________________
> 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:
http://www.freelists.org/list/foxboro
> to subscribe:
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Djoin
> to unsubscribe:
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
>
>
=20
=20
_______________________________________________________________________
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
=20
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         =
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Djoin
to unsubscribe:      =
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
=20
 
 
_______________________________________________________________________
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:             http://www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave

Other related posts: