Re: [foxboro] IACC Product and Integration with existing I/A tool s
- From: tom.vandewater@xxxxxxxxxxxxxx
- To: foxboro@xxxxxxxxxxxxx
- Date: Thu, 3 Feb 2005 09:34:49 -0500
Corey,
You said:
"I like to use iccprt to get configuration data out of the system. I have
several scripts that parse this data for various purposes. Even if I did
decide to use IACC for all my configuration, I'd still like to have this
capability. I suppose if the "ownership" of a CP is determined merely by a
text file somewhere, as Doug suggests, it's easy enough to get around,
though even doing what he describes for a quick iccprt dump is more effort
than I'd like."
You may have missed it in all of these postings on this issue but
Iccdrvr.tsk is still supported if you are using IACC even without switching
back to ICC so your iccprt scripts should still work. We, too, are heavily
utilizing Iccdrvr.tsk functionality.
Read the last line of the anonymous posting below:
> Did you previously use ICC or FOXCAE?
Yes, ICC, FoxCae and IACC hold no secrets for me, it's my job for over 6
years. ICC is great for changing/building a single block but otherwise
useless in my work. FoxCae is great for generating large databases, it has a
very fast and reliable database, but it's a complex, unintuitive program.
IACC is different and has its issues, but has some definitive advantages as
well. "Iccdrvr.tsk is also still my good friend."
Tom
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx
[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 existing I/A
tools
This is becoming an interesting discussion :)
I would hope that switching between IACC and ICC was relatively easy, if
you kept the database sync issues in mind. I can see using IACC on a
large project, with its template capabilities, but ICC from what I've seen
is easier for the day-to-day stuff. I bought IACC at version 1.0 to play
with it, and see if I could use it for back documentation (the price was
*very* attractive at the time) and this was the conclusion I reached. I
guess I ought to look into a 2.0 upgrade and re-evaluate this situation.
I like to use iccprt to get configuration data out of the system. I have
several scripts that parse this data for various purposes. Even if I did
decide to use IACC for all my configuration, I'd still like to have this
capability. I suppose if the "ownership" of a CP is determined merely by
a text file somewhere, as Doug suggests, it's easy enough to get around,
though even doing what he describes for a quick iccprt dump is more effort
than I'd like.
I've also grown used to having configurators available at any station on a
DCS (I/A of course fakes it by X-Window from the host AW, but that's good
enough). Whether this is good or not is debatable, and probably depends
on your environment, but we like it. I guess I'd be loading VNC on the
Windows box running IACC and all the WPs so I could retain that "from
anywhere" capability with IACC.
Alex mentioned FF configuration. I wonder if IACC eventually be able to
identify FF (or HART, or Profibus) devices on a segment, and show them in
some kind of tree view or something, so the user can "drag-n-drop" them
into configuration (a la Emerson DeltaV)?
Corey Clingo
BASF Corp.
_______________________________________________________________________
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:
