[foxboro] Super Duper Tools, was: IACC Product and Integration with existin g I/A tool s
- From: "Sieling, Marcel" <Marcel.Sieling@xxxxxxxxxxxxxxxx>
- To: "'foxboro@xxxxxxxxxxxxx'" <foxboro@xxxxxxxxxxxxx>
- Date: Fri, 4 Feb 2005 05:12:24 -0500
Tom wrote:
> This type of information is most important when=20
> deleting existing blocks because a sequence trying to get or=20
> set a variable that no longer exists will cause the sequence=20
> to hang up. =20
And I'd like to add [I take the risk to repeat myself in this issue]:
...if you don't use Standard Block Exceptions. If you do (TO_SYS_ERROR =
in
this case) it's easy to issue a well defined error message, where the =
line
number of the source code and the error number (OP_ERR -1 or -45, =
depends
upon read or write has performed) is printed and the block does NOT =
hang up.
However, the Super Duper I/A Browser is a great idea and for sure =
extremely
useful.
> My question to IACC users is:
> Is there any way in IACC to see if a block is being=20
> manipulated by a sequence get or set?
No way, sorry.
> How do other users address this situation?
my personal Super Duper I/A Browser for omsets and gets in Sequence =
Code is
called "grep", preferably executed in =
/opt/fox/ciocfg/<COMPOUNDNAME>/*.s.
;-)))
Best regards -
Marcel Sieling
Systems Technologies
Invensys Systems GmbH
Emanuel-Leutze-Str. 11
40547 Duesseldorf
Germany
Tel.: +49-211-5966-302
Fax: +49-163-99-5966302=20
Mobile: +49-163-5966302
Email: mailto:marcel.sieling@xxxxxxxxxxxxxxxx
Homepage: http://www.foxboro-deutschland.de
> -----Urspr=FCngliche Nachricht-----
> Von: foxboro-bounce@xxxxxxxxxxxxx=20
> [mailto:foxboro-bounce@xxxxxxxxxxxxx] Im Auftrag von=20
> tom.vandewater@xxxxxxxxxxxxxx
> Gesendet: Donnerstag, 3. Februar 2005 20:37
> An: foxboro@xxxxxxxxxxxxx
> Betreff: Re: [foxboro] IACC Product and Integration with=20
> existing I/A tool s
>=20
>=20
> We haven't taken another look at IACC since the early=20
> days for a variety of reasons but the biggest reason is listed below:
>=20
> In the infant days of IA we used to create block=20
> interconnection diagrams, like FoxCae and IACC can provide,=20
> by hand in a CADD environment. When FoxCae came out we were=20
> excited because that laborious task would be replaced, but we=20
> found out that FoxCae, and now IACC have no knowledge or way=20
> of documenting gets and sets of variables that are made from=20
> sequence coding, which we use extensively in our automation efforts. =
> If you are going to make online changes to blocks in a=20
> 24/7/365 environment like we are in, you have to know=20
> conclusively what could be affected by those changes. Using=20
> iccprt in conjunction with scripts that parse om gets and=20
> sets from the sequence code, we developed a global database=20
> that can be queried from a browser. (we call it the Super=20
> Duper IA Browser). The interface is simple yet elegant and=20
> allows the user to search for all connections, gets or sets=20
> to any given block or groups of blocks. The table that the=20
> browser queries is dead simple including only 4 fields:
>=20
> 1. Compound:Block of the "Sink" Block
> 2. Block Type
> 3. Parameter of the "Sink" block containing external=20
> connection 4. "Source" Cmpnd:Blk.Prm being used by the "Sink"
>=20
> Gets and sets generated by sequences always show the sequence=20
> block as the "sink" the block type as "SOFT" and the=20
> Cmpnd:Blk.Prm being manipulated by the sequence in the source=20
> field. The query searches through all records of the table=20
> looking for any record that contains any part of the string=20
> entered in the browser window by the user. We currently have=20
> over 62,000 connections but the search returns the=20
> information to the user in just seconds. It doesn't take=20
> long to get used to looking at this tabular data and making=20
> informed decisions when adding, deleting, or modifying blocks. =20
> This type of information is most important when=20
> deleting existing blocks because a sequence trying to get or=20
> set a variable that no longer exists will cause the sequence=20
> to hang up. I have used the Super Duper IA Browser=20
> extensively lately while replacing more than 700 PID,E,X, and=20
> XE blocks with PIDA's while the process is still running! =20
> There is a point in time that the old PID block must be=20
> deleted before adding the new PIDA block using the same name.=20
> I would be afraid to do that using only the information in=20
> FoxCae or IACC.
>=20
> My question to IACC users is:
> Is there any way in IACC to see if a block is being=20
> manipulated by a sequence get or set?
>=20
> How do other users address this situation?
>=20
> Thanks,
> Tom VandeWater
>=20
> -----Original Message-----
> From: foxboro-bounce@xxxxxxxxxxxxx=20
> [mailto:foxboro-bounce@xxxxxxxxxxxxx]On Behalf Of Boulay, Russ
> Sent: Thursday, February 03, 2005 9:55 AM
> To: 'foxboro@xxxxxxxxxxxxx'
> Subject: Re: [foxboro] IACC Product and Integration with=20
> existing I/A tool s
>=20
>=20
> One of the issues of note is Corey's last statement where he=20
> would load VNC to be able to configure control database from=20
> different locations.
>=20
> This is one of the areas that have been missed in these discussions.
>=20
> With IACC you can have an "off platform" IACC server and then=20
> have your AW70's/WP70's be IACC clients to that server. The=20
> server can also be one of your AW70's. So using the=20
> server/client functions of IACC, config work can be performed=20
> from different locations.=20
>=20
> There are the IACC rules of accessing the database one user=20
> at a time, but this would be similar to ICC and have=20
> configuration tools from any workstation that you designated=20
> as a IACC client.
>=20
> -----Original Message-----
> From: foxboro-bounce@xxxxxxxxxxxxx=20
> [mailto:foxboro-bounce@xxxxxxxxxxxxx] On Behalf Of=20
> tom.vandewater@xxxxxxxxxxxxxx
> Sent: Thursday, February 03, 2005 9:35 AM
> To: foxboro@xxxxxxxxxxxxx
> Subject: Re: [foxboro] IACC Product and Integration with=20
> existing I/A tool s
>=20
> Corey,
> You said:
> "I like to use iccprt to get configuration data out of the=20
> system. I have several scripts that parse this data for=20
> various purposes. Even if I did decide to use IACC for all=20
> my configuration, I'd still like to have this capability. I=20
> suppose if the "ownership" of a CP is determined merely by a=20
> text file somewhere, as Doug suggests, it's easy enough to=20
> get around, though even doing what he describes for a quick=20
> iccprt dump is more effort than I'd like."
>=20
> You may have missed it in all of these postings on this=20
> issue but Iccdrvr.tsk is still supported if you are using=20
> IACC even without switching back to ICC so your iccprt=20
> scripts should still work. We, too, are heavily utilizing=20
> Iccdrvr.tsk functionality.
>=20
> Read the last line of the anonymous posting below:
>=20
> > Did you previously use ICC or FOXCAE?
> Yes, ICC, FoxCae and IACC hold no secrets for me, it's my job=20
> for over 6 years. ICC is great for changing/building a single=20
> block but otherwise useless in my work. FoxCae is great for=20
> generating large databases, it has a very fast and reliable=20
> database, but it's a complex, unintuitive program. IACC is=20
> different and has its issues, but has some definitive=20
> advantages as well. "Iccdrvr.tsk is also still my good friend."
>=20
> Tom
>=20
> -----Original Message-----
> From: foxboro-bounce@xxxxxxxxxxxxx=20
> [mailto:foxboro-bounce@xxxxxxxxxxxxx]On Behalf Of Corey R Clingo
> Sent: Thursday, February 03, 2005 9:17 AM
> To: foxboro@xxxxxxxxxxxxx
> Subject: Re: [foxboro] IACC Product and Integration with=20
> existing I/A tools
>=20
>=20
> This is becoming an interesting discussion :)
>=20
> I would hope that switching between IACC and ICC was=20
> relatively easy, if=20
> you kept the database sync issues in mind. I can see using IACC on a =
> large project, with its template capabilities, but ICC from=20
> what I've seen=20
> is easier for the day-to-day stuff. I bought IACC at version=20
> 1.0 to play=20
> with it, and see if I could use it for back documentation=20
> (the price was=20
> *very* attractive at the time) and this was the conclusion I=20
> reached. I=20
> guess I ought to look into a 2.0 upgrade and re-evaluate this=20
> situation.
>=20
>=20
> I like to use iccprt to get configuration data out of the=20
> system. I have=20
> several scripts that parse this data for various purposes. =20
> Even if I did=20
> decide to use IACC for all my configuration, I'd still like=20
> to have this=20
> capability. I suppose if the "ownership" of a CP is=20
> determined merely by=20
> a text file somewhere, as Doug suggests, it's easy enough to=20
> get around,=20
> though even doing what he describes for a quick iccprt dump=20
> is more effort=20
> than I'd like.
>=20
>=20
> I've also grown used to having configurators available at any=20
> station on a=20
> DCS (I/A of course fakes it by X-Window from the host AW, but=20
> that's good=20
> enough). Whether this is good or not is debatable, and=20
> probably depends=20
> on your environment, but we like it. I guess I'd be loading=20
> VNC on the=20
> Windows box running IACC and all the WPs so I could retain that "from =
> anywhere" capability with IACC.
>=20
>=20
> Alex mentioned FF configuration. I wonder if IACC eventually=20
> be able to=20
> identify FF (or HART, or Profibus) devices on a segment, and=20
> show them in=20
> some kind of tree view or something, so the user can=20
> "drag-n-drop" them=20
> into configuration (a la Emerson DeltaV)?
>=20
>=20
> Corey Clingo
> BASF Corp.
>=20
>=20
> =20
> =20
> ______________________________________________________________
> _________
> This mailing list is neither sponsored nor endorsed by=20
> Invensys Process Systems (formerly The Foxboro Company). Use=20
> the info you obtain here at your own risks. Read=20
> http://www.thecassandraproject.org/disclaimer.html
> =20
> foxboro=20
> mailing list: //www.freelists.org/list/foxboro
> to subscribe: =20
> mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Djoin
> to=20
> unsubscribe: =
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
> =20
> =20
> =20
> ______________________________________________________________
> _________
> This mailing list is neither sponsored nor endorsed by=20
> Invensys Process Systems (formerly The Foxboro Company). Use=20
> the info you obtain here at your own risks. Read=20
> http://www.thecassandraproject.org/disclaimer.html
> =20
> foxboro=20
> mailing list: //www.freelists.org/list/foxboro
> to subscribe: =20
> mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Djoin
> to=20
> unsubscribe: =
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
> =20
>=20
> =20
> =20
> ______________________________________________________________
> _________
> This mailing list is neither sponsored nor endorsed by=20
> Invensys Process Systems (formerly The Foxboro Company). Use=20
> the info you obtain here at your own risks. Read=20
> http://www.thecassandraproject.org/disclaimer.html
> =20
> foxboro=20
> mailing list: //www.freelists.org/list/foxboro
> to subscribe: =20
> mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Djoin
> to=20
> unsubscribe: =
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
> =20
> =20
> =20
> ______________________________________________________________
> _________
> This mailing list is neither sponsored nor endorsed by=20
> Invensys Process Systems (formerly The Foxboro Company). Use=20
> the info you obtain here at your own risks. Read=20
> http://www.thecassandraproject.org/disclaimer.html
> =20
> foxboro=20
> mailing list: //www.freelists.org/list/foxboro
> to subscribe: =20
> mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Djoin
> to=20
> 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
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:
- » [foxboro] Super Duper Tools, was: IACC Product and Integration with existin g I/A tool s
