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