[foxboro] Using IACC where and when, was: IACC Product and Integration with existing I/A tools

  • From: "Sieling, Marcel" <Marcel.Sieling@xxxxxxxxxxxxxxxx>
  • To: "'foxboro@xxxxxxxxxxxxx'" <foxboro@xxxxxxxxxxxxx>
  • Date: Thu, 3 Feb 2005 11:16:37 -0500

Hi list,

> I would hope that switching between IACC and ICC was=20
> relatively easy, if you kept the database sync issues in=20
> mind. =20

Absolutely. Switching back and forth is a matter of just editing one =
line in
a config file and that's it.

> I can see using IACC on a large project, with its template=20
> capabilities, but ICC from what I've seen is easier for the=20
> day-to-day stuff. =20

I would totally NOT agree with this. ;-)

Besides sophisticated features for importing and bulk generation the =
very
strength of the IACC product (and I'd say the focus of it's developers) =
is
it's intuitiveness in building prototypes or simple loops, not =
dependent on
templates. Configuring and linking blocks on a CSD canvas (Control =
Strategy
Diagrams, say Loop) together graphically and then testing that in an
animated CSD instantly after having it downloaded is just one click =
away.=20

IACC supports this very comfortable, as you can choose to download =
without
checkpointing. This actually keeps the driver task session open and
checkpoints are performed in the background at a specifiable given time
(e.g. every hour). In each CSD you can right click on the background =
and
choose "Download changes" which will download only the changes on all =
blocks
on this CSD. In addition in each parameter change dialog there is a =
Button
"Apply" which confirms the changes to the IACC database, but also a =
button
"Download" which directly confirms them to IACC and CP at the same =
time. So
changing just a single value of a block in a running plant, which is in =
sync
is easier and quicker than in good old ICC because you can do it =
graphically
and there is no need to checkpoint each and every time. With the =
animated
loop all building of group displays with additional test and debug
information suddenly has become obsolete!=20

These are really dramatic advantages compared to the classic ICC and / =
or
FoxCAE-ICC offering.

> I guess I ought to look into a 2.0 upgrade and re-evaluate this=20
> situation.

I strongly agree. Version 2.0 is for sure the preferred choice of IACC =
right
now. Make sure you get a current build, we use here since late 2004 =
"IACC
2.0 I7 build 247", which may be a little outdated in the meantime but =
which
runs pretty stable though.

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 Corey R Clingo
> Gesendet: Donnerstag, 3. Februar 2005 15:17
> An: foxboro@xxxxxxxxxxxxx
> Betreff: 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

 
 
_______________________________________________________________________
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] Using IACC where and when, was: IACC Product and Integration with existing I/A tools