Re: [foxboro] IACC Projects (was: IACC Projects)
- From: tom.vandewater@xxxxxxxxxxxxxx
- To: foxboro@xxxxxxxxxxxxx
- Date: Wed, 2 Feb 2005 10:19:08 -0500
List,
I received an email, (off list), from an IACC user that wishes to remain
anonymous. Remember, these are personal views of the responder.
Tom VandeWater
> It is worth a lot to know it is starting to be used.
Acually, IACC is being used on several projects around me since mid-2003. I
started my current project with a very early beta version of IACC 2.0
I also beta tested IACC 1.1
> Did you previously use ICC or FOXCAE?
Yes, ICC, FoxCae, and IACC hold no secrets for me. ICC is great for
changing/building a single block but otherwise useless in my project 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.
> How do they compare from your perspective?
Without going into too much detail, I'll give you an honest overview of
IACC's biggest pro's and cons at the moment, but you have to remember that
it's from a bulk-engineering point of view, and there are so many
differences I can't possibly cover them all.
Cons
- The objectstore database is a lot slower (generating,downloading) than the
FoxPro database used with FoxCae. At the moment this basically results in
drinking more coffee.... and wasting time I'm afraid. I don't think it is
significant in a running plant environment, since you don't often regenerate
thousands of blocks and do complete downloads to many CP's
- The maximum amount of, (advised), objects is only enough for about 16.000
blocks, which means you have to use more than one DB If you have more than
that. Not a real problem in my opinion. There are white papers on how to use
it and in vers. 2.0 there is a nice multiple db feature.
- There are some things we cannot do automatically in IACC for a lot of
objects at the same time, like Compiling all sequences in a CP or entire
database for that matter, generating compound order, using compound
defaults, and some other small annoyances. Most problems have workarounds
though.
- Since IACC seems to have been designed with the end-user in the plant in
mind, it has some bulk-generating issues. All have workarounds
though.
Pros
- More intuitive, much "friendlier". (But there are pitfalls. Sometimes IACC
can be "a wolf in sheeps clothes")
- Drag/drop. Building typicals (and loops off course) is much easier than
FoxCae/ICC/Iccdrvr.tsk
- Graphical additions to loop/typical. You can build your own appearances of
the blocks and draw/write a lot more in your typical/loop to make it more
understandable or just nicer.
- Online values in IACC; great for testing a prototype loop.
- Formulas in IACC are much easier (excel-type) than the Foxpro SQL in
FoxCae
- Integration with foxdraw/foxview. You can now drag a block or loop onto a
display and the display symbol will be automatically linked and configured
where you drop the loop. Save. Done. Working display. Not really useful for
me as an bulk-engineer. Great if you are in a plant and need to add a single
Analog input to a CP and display.
- Integration with System Definition, which among other things mean that the
ECB's are automatically build.
Like I said, there are more pros and cons...
Because of the fact IACC was a bit more designed for the end-user than for
the bulk-engineer, stubborn Application engineers tend to stick to FoxCae.
It's what they know, its fast and reliable. And learning something new when
you have something that works....
>Is the IACC control database being configured off line or are you actually
loading it into the FCP-270's?
Well, you always build offline and then download it to the CP, but you can
do this with 1 parameter or 4000 blocks.
2. Do you consider it robust?
Yes. Slow, but robust. The database almost never gets corrupted and if it
does it's salvageable. The only thing is that you have to be careful not to
get the IACC DB out of sync with the IA system. There are a couple of big
No-No's
3. Is it capable of handling a project of around 3000-4000 I/O points?
ONE db can "officially" handle 3-4 CP's and 16.000 blocks. Not the best
situation, but multiple databases are not as bad as it sounds.
4. How easy (or difficult) is it to backup/restore your IACC database?
Very easy. Zip a directory and copy it to a safe place, done. It's a bit
large though, but harddrives are cheap nowadays. There are also DB-export
tools
5. Does IACC have bulk configuration import capability of either Excel- or
text-formatted information?
it does for the taglists, not for the actual database.
6. Does IACC replace System Definition, or any other configurators, or
just ICC?
Yes, it CAN replace sysdef. You can also still use sysdef and import it in
IACC.
7. Does a system configured with IACC still have a CSA database?
Nothing changes with the IA System. It might sound a bit strange, but from
that point of view, IACC is nothing more than a really sophisticated
iccdrvr.tsk script generator. (that's how the downloads are done.) It does
change the "theoretical role" of the ICC workfiles on the AW a bit.
_______________________________________________________________________
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:
