Re: [foxboro] IACC Product and Integration with existing I/A tool s
- From: tom.vandewater@xxxxxxxxxxxxxx
- To: foxboro@xxxxxxxxxxxxx
- Date: Thu, 3 Feb 2005 14:37:18 -0500
We haven't taken another look at IACC since the early days for a
variety of reasons but the biggest reason is listed below:
In the infant days of IA we used to create block interconnection
diagrams, like FoxCae and IACC can provide, by hand in a CADD environment.
When FoxCae came out we were excited because that laborious task would be
replaced, but we found out that FoxCae, and now IACC have no knowledge or
way of documenting gets and sets of variables that are made from sequence
coding, which we use extensively in our automation efforts.
If you are going to make online changes to blocks in a 24/7/365
environment like we are in, you have to know conclusively what could be
affected by those changes. Using iccprt in conjunction with scripts that
parse om gets and sets from the sequence code, we developed a global
database that can be queried from a browser. (we call it the Super Duper IA
Browser). The interface is simple yet elegant and allows the user to search
for all connections, gets or sets to any given block or groups of blocks.
The table that the browser queries is dead simple including only 4 fields:
1. Compound:Block of the "Sink" Block
2. Block Type
3. Parameter of the "Sink" block containing external connection
4. "Source" Cmpnd:Blk.Prm being used by the "Sink"
Gets and sets generated by sequences always show the sequence block as the
"sink" the block type as "SOFT" and the Cmpnd:Blk.Prm being manipulated by
the sequence in the source field.
The query searches through all records of the table looking for any record
that contains any part of the string entered in the browser window by the
user. We currently have over 62,000 connections but the search returns the
information to the user in just seconds. It doesn't take long to get used
to looking at this tabular data and making informed decisions when adding,
deleting, or modifying blocks.
This type of information is most important when deleting existing
blocks because a sequence trying to get or set a variable that no longer
exists will cause the sequence to hang up. I have used the Super Duper IA
Browser extensively lately while replacing more than 700 PID,E,X, and XE
blocks with PIDA's while the process is still running! There is a point in
time that the old PID block must be deleted before adding the new PIDA block
using the same name. I would be afraid to do that using only the
information in FoxCae or IACC.
My question to IACC users is:
Is there any way in IACC to see if a block is being manipulated by a
sequence get or set?
How do other users address this situation?
Thanks,
Tom VandeWater
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx
[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 existing I/A
tool s
One of the issues of note is Corey's last statement where he would load VNC
to be able to configure control database from different locations.
This is one of the areas that have been missed in these discussions.
With IACC you can have an "off platform" IACC server and then have your
AW70's/WP70's be IACC clients to that server.
The server can also be one of your AW70's.
So using the server/client functions of IACC, config work can be performed
from different locations.
There are the IACC rules of accessing the database one user at a time, but
this would be similar to ICC and have configuration tools from any
workstation that you designated as a IACC client.
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of tom.vandewater@xxxxxxxxxxxxxx
Sent: Thursday, February 03, 2005 9:35 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] IACC Product and Integration with existing I/A tool s
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
_______________________________________________________________________
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:
