Re: [foxboro] Super Duper Tools, was: IACC Product and Integratio n with existin g I/A tool s
- From: "Carter, Andrew" <acarter@xxxxxxxxxxx>
- To: "'foxboro@xxxxxxxxxxxxx'" <foxboro@xxxxxxxxxxxxx>
- Date: Fri, 4 Feb 2005 16:24:27 -0500
Maybe I don't get outside my Region here in the SouthEast much, but I have
never heard this "UNIX bigot" term until seeing it posted here. I think
long-time Foxboro employees take pride in the UNIX offering we have provided
over the years.
Andrew W. Carter
Invensys Process Systems
235 Quail Ridge Road
Helena, AL 35080
Office: (205) 428-9242
Cell: (205) 215-9440
Fax: (205) 428-9223
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of Johnson, Alex (Foxboro)
Sent: Friday, February 04, 2005 2:19 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Super Duper Tools, was: IACC Product and Integratio n
with existin g I/A tool s
Re: the term "UNIX bigots"
Personally, I find the term offensive. I think it denigrates those of our
customers who find that part of our offering to be the one that best meets
their needs and it de-humanizes our customers and their needs. I implies
that the speaker thinks the user of that technology doesn't understand their
own needs.
I will not tolerate the usage of the term by Invensys folks.
Re: I believe he (Alex) thinks the "UNIX Bigots", (and I mean that in the
nicest possible way everyone), should be more accepting of the new Windows
based apps.
I stated in front of several hundred users in San Antonio that our (IPS')
goal is to make our applications so valuable that you want to upgrade your
systems to use them.
I strongly believe this. If we don't make our offering compelling we aren't
succeeding.
Re: IACC
The current IACC is the first step. We are actively working the next
generation and we hope it will be even more compelling.
Regards,
Alex Johnson
Invensys Process Systems
Invensys Systems, Inc.
10707 Haddington
Houston, TX 77043
713.722.2859 (voice)
713.722.2700 (switchboard)
713.932.0222 (fax)
ajohnson@xxxxxxxxxxx
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of tom.vandewater@xxxxxxxxxxxxxx
Sent: Friday, February 04, 2005 1:00 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Super Duper Tools, was: IACC Product and Integratio n
with existin g I/A tool s
Thanks for the feedback Marcel. You are obviously quite
knowledgeable about IACC and I appreciate the time you have taken to share
your experiences.
We have used the Exception Handler in our code where it is
appropriate. In most instances our sequences are ("sequential" ;) and we
don't want them to proceed unless the previous step has been properly
executed. We use the sequence alarm capability, (OP_OPT), to notify the
appropriate operating technician of problems with sequences so they can
contact us.
As far as using grep, we have over 50 CP's running our processes
which work together in a continuous train. There are significant
interactions between the CP's across both the nodebus and the sitewide
CBLAN. To insure we catch all of those potential interactions we would have
to grep all of the .s files in all of the compounds on all of the AW's. It
could definitely be done with an automated script but it would take a little
longer than searching our database with the Super Duper IA Browser.
IACC definitely sounds like a better tool to consider if a user is
starting out from scratch, but it still doesn't address all of the problems
that users have. Because of this, users have created scripts and databases
to meet their needs. Most of the people on this list have used UNIX as
their building block and are used to using commands like grep, awk, sed, and
a host of other command line tools to get what they want from the object
manager or text based configuration files. That is at the root of Fox IA's
appeal to many of the users and it creates problems for those users when new
applications are developed, especially on a different OS that is GUI based,
if those applications don't eliminate the need for all of the UNIX/Command
Line based applications. I have had this discussion personally with Alex.
I believe he thinks the "UNIX Bigots", (and I mean that in the nicest
possible way everyone), should be more accepting of the new Windows based
apps. I say they will be accepted when those applications make conversion
from the old to the new relatively painless and they offer more
functionality and possibilities than the old stuff. So far there is enough
advantages for us to do it. I keep asking questions to try and make sure I
understand the new capabilities.
Besides the CSD capability, another initial attraction to using IACC
for me was the ability to create consistent graphical conventions for the
depiction of common block types, but we would have to use Foxview/Foxdraw
and we currently use the Display Manager. Considering the 50 CP's, you can
imagine that we have several hundred megabytes of DM graphics. I have heard
people say that they had no problems converting DM graphics to Foxview but
when I tried it with ours, the conversion was far from satisfactory. The
problems were especially noticeable with the font conversions, but there are
also problems with line sizing and aspect ratios. That meant we would have
to go into FoxDraw and fix all of the graphics just to get them to look like
they did in the DM. I worked on a moderate sized file to see how long that
would take and it took me about 30 minutes to re-adjust. That calculates
into man-months of effort for all of our graphics.
We have already created globally generic overlays for each block
type that we use in the DM environment. That allows us to define the
Compound and Block so the DM can build and call up a faceplate on the fly,
eliminating our need to build individual faceplates for each loop created in
the ICC. We call user generated library elements that are already
configured onto a base graphic. They "know" how to invoke the generic
overlay when clicked on by a mouse.
So, for me, I can't justify the time, expense, and training it would
take for us to move our applications from the old to the new. I wish the
applications were compelling enough for me to want to transition to them
regardless of whether I could justify it, but that is not yet the case for
me and I think many others on this list.
Tom VandeWater
Control Systems Developer/Analyst
Dow Corning Corporation
Carrollton, KY USA
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx
[mailto:foxboro-bounce@xxxxxxxxxxxxx]On Behalf Of Sieling, Marcel
Sent: Friday, February 04, 2005 5:12 AM
To: 'foxboro@xxxxxxxxxxxxx'
Subject: [foxboro] Super Duper Tools, was: IACC Product and Integration
with existin g I/A tool s
Tom wrote:
> This type of information is most important when=20
> deleting existing blocks because a sequence trying to get or=20
> set a variable that no longer exists will cause the sequence=20
> to hang up. =20
And I'd like to add [I take the risk to repeat myself in this issue]:
...if you don't use Standard Block Exceptions. If you do (TO_SYS_ERROR =
in
this case) it's easy to issue a well defined error message, where the =
line
number of the source code and the error number (OP_ERR -1 or -45, =
depends
upon read or write has performed) is printed and the block does NOT =
hang up.
However, the Super Duper I/A Browser is a great idea and for sure =
extremely
useful.
> My question to IACC users is:
> Is there any way in IACC to see if a block is being=20
> manipulated by a sequence get or set?
No way, sorry.
> How do other users address this situation?
my personal Super Duper I/A Browser for omsets and gets in Sequence =
Code is
called "grep", preferably executed in =
/opt/fox/ciocfg/<COMPOUNDNAME>/*.s.
;-)))
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
_______________________________________________________________________
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:
