Re: [foxboro] OMI - Operator Message Interface

  • From: brad.s.wilson@xxxxxxxxxxxxxx
  • To: foxboro@xxxxxxxxxxxxx
  • Date: Fri, 31 Mar 2006 16:28:39 -0500

Tom,

I understand what you're saying, but it seems like this will handle only
one SNxxxx per dynamic text element.  If I wanted to be able to send
message strings from several seqs to the same dynamic text element, I can't
see how that would work with your arrangement.  I could see having each seq
write its message (since a seq can only generate one msg at a time) to a
different SNxxxx of a separate IND block, then having that IND block cycle
through its SNxxxx to drive the text element ... but that would be
effectively be re-creating OMI in HLBL - exactly what I was trying to
avoid.

Brad Wilson
Process Control Engineer
ExxonMobil Chemical Co
Edison Synthetics Plant
732-321-6115
732-321-6177 fax
Brad.S.Wilson@xxxxxxxxxxxxxx


                                                                           
             <tom.vandewate                                                
             r@xxxxxxxxxxxx                                                
             om>                                                        To 
             Sent by:                 <foxboro@xxxxxxxxxxxxx>              
             foxboro-bounce                                             cc 
             @freelists.org                                                
                                                                   Subject 
                                      Re: [foxboro] OMI - Operator Message 
             03/31/06 02:36           Interface                            
             PM                                                            
                                                                           
                                                                           
             Please respond                                                
                   to                                                      
             foxboro@freeli                                                
                sts.org                                                    
                                                                           
                                                                           




Brad,
             I guess it depends on what you mean by interactive messages.
We
used to use OMI for sequence messages but I never really liked it
because if the host died or was rebooted all the sequence interaction
with production was not possible.  We decided to bite the bullet and
eliminate OMI by building a text field on the sequence graphic that was
tied to .MSGNO and .SN0001-SN0010 of the sequence. =20
             In the sequence code you just change your SENDMSG from
MSGGR1-4
to SN0001-10 as you see fit.  If you need confirmation to proceed you
can build that into the sequence code as needed as Boolean or Integer
inputs that get sent to the sequence from the sequence graphic.  Same
for alarms. =20
             By default, our message box is 60 characters long but the
message you send can be any length up to that.  In order to get the text
string to dynamically update on the graphic, you configure the text
placeholder which we usually build in DispBuilder as:
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

In the Disp Configurator connect the 60 character text element as
follows:
Contents <<  (contents in text)
Path Name:  COMPOUND.YOURSEQ.MSGNO
Connection to TEXT  (not REAL)
Parameter: .SN0001  (or whatever .SN  you did SENDMSG to in YOURSEQ).

             In this way you are no longer dependent on an OMI server that
can hose all 19 of your sequences at one time and the messages are
exactly as reliable as your FT CP because that is what will be serving
them.  If that sequence fails you lose it's messages but none of the
others!  But don't get SNDMSG happy in your sequence because the
sequence compiler has a limit to the maximum # of characters it can
compile and the error message that it displays when the threshold is
exceeded is quite cryptic, but you would have run into that even using
OMI as your message server.  Hope this helps dig you out from under the
OMI kludge.

Tom VandeWater

-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of brad.s.wilson@xxxxxxxxxxxxxx
Sent: Friday, March 31, 2006 12:19 PM
To: foxboro@xxxxxxxxxxxxx
Subject: [foxboro] OMI - Operator Message Interface

I wanted to resurrect an old thread, because time marches on and I still
have no solution.

We are moving from v4.3.2 to v7.x and upgrading our AW51B's to AW51F's.
We
are still using RBatch (1) and use OMI extensively for operator
interface
to sequence code.  I see from an old post (Nov 2003) that FoxView does
not
support OMI ... if that is the case, then I guess we'll have to remain
on
DM, even after we upgrade our WP30's.  We have 3 instances of OMI
running
(both 51B's and a PW-OE) which provides us with 57 message files (19 per
instance), and we are using every single file, and could use about 20-30
more.  In Feb 2003, Alex Johnson mentioned a package called ODS which
supposedly replace OMI, but I've never heard of it.

My problem is that I am rapidly running out of hosts for OMI, and I'm
not
certain that it will even run when those hosts are upgraded to newer hw
&
sw.  We will be replacing our PW-OE with X-windows, so I plan on keeping
that for OMI (assuming it will still run v4.3 on a v7.x network).  On my
bench I have 3 PW-OE in various stages of repair which I would like to
get
back running again to provide OMI hosts.  I would have a tough sell to
my
bosses to upgrade my WP51's to AW51's just to be able to host message
files.

So my questions to the list are ...
Does anyone have a feel for whether my PW-OE idea will work (as long as
I
can keep the hardware alive) ?
Does anyone have other solutions for "interactive" operator messages
from
sequence code ?

Here is my original posting from April 2004 (edited for present
conditions):

Our system is ... v4.3 (soon to be v7), 2x AW51B's (soon to be 2x
AW51F's),
2x WP51's, 2x WP30's, 2x X-stations, 1x PW-OE ... you may be thinking
"How
do they keep that old stuff running?" Well, it's not always easy. We are
a
batch plant with several operating units, each running concurrent
sequence
blocks, so I need a way to view & respond to messages from more than 1
sequence block at a time. We use OMI (operator message interface), which
works well for us. The problem is that each instance of OMI can only
host
19 message files. We have one running in each 51B and in the PW-OE.
(Originally, we had 2x AP20's which were replaced by 1x 51B, thus losing
us
an OMI.) We are set to replace the PW-OE with an Exceed station, thus
losing another OMI. We'll be left with only 2 possible OMI hosts ... the
51B's. Our problem is that 2 OMI's (38 message files) is not enough.
Short
of trying to keep the PW-OE running as as OMI host (plus the 3 other
PW-OE's I have in various states of repair), does anyone have a
solution?
Perhaps a way of hosting more than 19 files per station? Or an
alternative
to using OMI? I've thought of upgrading some of the WP30's to 51's, but
that a very expensive option. (Of course, when WP30's are no longer
supported, we may have no choice ... like with our PW-OE's.)

This was Brian Long's reply:

I don't have an answer for you but you are not alone.  I have a whole
bunch
of 51B's and WP30's, and plan to run them til they quit.   I discussed
the
with Foxboro a 100 times and can't seem to get anywhere.

There were other postings about "home-grown" message interfaces, but I
don't feel that I should have to re-create something that Foxboro
already
has a great solution for.

Brad Wilson
Process Control Engineer
ExxonMobil Chemical Co
Edison Synthetics Plant
732-321-6115
732-321-6177 fax
Brad.S.Wilson@xxxxxxxxxxxxxx

=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:             //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:             //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: