Brad, You are right in saying the graphic text connection will only show one .SN value. I guess I didn't understand what you were trying to do. I thought you were using a separate message file for each sequence you are running since you said you have three instances of OMI and 19 message files each. If you are sending messages from multiple sequences to the same message file, then it seems like you would have plenty with 57 individual files. If multiple sequences are used to perform one function you could pass integer values to a message sequence that handles all messages for that function and let it set the .SN that is connected to graphics. I believe generating the messages from CP to CP or passing them to different sequences in the same CP is still much more reliable than depending on a non-FT server, that may need to be shutdown for software upgrades while the process is running. When we used OMI we found it to function but felt we had too many eggs in the same basket, and the basket wasn't robust enough to hold all of them, but if you have something that you already like, then stick with it until the bitter end, which is evidently just around the corner. If you build your interface on the controllers, (and sequences that run in them), and Object Manager functionalities, you shouldn't have to worry about application specific solutions or licenses and servers to run them. Ever since we eliminated OMI from our system by using the sequence string variables we haven't had to buy or upgrade anything for our display of sequence messaging to function, and I am assured that it will keep working until Foxboro no longer supports the Control Block parameters and the Object Manager calls that access them. Cheers, Tom VandeWater -----Original Message----- From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On Behalf Of brad.s.wilson@xxxxxxxxxxxxxx Sent: Friday, March 31, 2006 4:29 PM To: foxboro@xxxxxxxxxxxxx Subject: Re: [foxboro] OMI - Operator Message Interface 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 =20 <tom.vandewate r@xxxxxxxxxxxx om> To=20 Sent by: <foxboro@xxxxxxxxxxxxx> foxboro-bounce cc=20 @freelists.org =20 Subject=20 Re: [foxboro] OMI - Operator Message=20 03/31/06 02:36 Interface PM =20 =20 Please respond to foxboro@freeli sts.org =20 =20 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. =3D20 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. =3D20 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 =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: //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: //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: //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