Re: [foxboro] client server

Somewhat, perhaps, but I don't see myself using the "control strategy" 
approach much in creating them, either.  I tend to work more in the mode 
of creating all my I/O blocks first, then the higher-level stuff (PID, 
etc.) afterward, rather than all my control loops.  Maybe if I were 
putting in a grassroots 40,000 I/O refinery, I might feel differently, but 
with the magnitude of things I'm usually working on, I tend to do it in 
the manner I described.  Further, I can auto-create the I/O from, say, 
INtools data, for instance, but not an entire loop, as the PID/logic/etc. 
data is not in INtools - though I could update the existing blocks I 
suppose, as long as they are not the DCI variety :)

ICC works fine, really.   I'd of course be happier with an ICC that let me 
cut and paste, let me edit CALC block steps more like I do text files, and 
whose arrow and edit keys worked the same on all the platforms I have 
(instead of 3 different ways).  Maybe IEE offers these features, and if so 
they would attract me to it more than anything else.  But if it is slow, 
limits the number of CPs I can access, or has a large, complex database 
that can get easily corrupted, I will probably fall back to ICC.


Now, if you are going to throw in things like right-click 
cross-referencing, right-click parameter documentation that is accurate, 
edit-time resolution and warning of bad block connections, ability to look 
at HART/FF transmitter data within the config tool (or even better, drag 
and drop onto a tag and have it get ranges, etc. from the transmitter), 
one-checkbox historian configuration (again from tag data), then I'm 
interested. 


Heck, while we are at it, maybe IEC61131-style editing for automatic 
documentation (yes, this is somewhat leaning toward control strategies, 
but I'm talking built-in, native to the CP rather than layered-on).  And 
make all settable parameters connectable and retrievable.  And have a 
non-tagname-dependent shorthand for loopback connections; e.g., :::.VALUE 
rather than :B:P.VALUE.  It sounds minor but it's a PITA when duplicating 
or renaming tags, and we are doing this more and more these days to get 
around the lack of a good system-wide security model.  Or we could improve 
that model.  But those are more sweeping, CP-level changes, and probably 
not as easy to implement.


Corey Clingo
BASF Corporation


[Of course I would not have used a classic-nodebus-based I/A system to 
control 40,000 I/O, but that's another discussion.  I presume mesh and 
CP270s are more scalable.]






"Johnson, Alex P \(IPS\)" <alex.johnson@xxxxxxxxxxxxxxxx> 
Sent by: foxboro-bounce@xxxxxxxxxxxxx
03/29/2007 02:26 PM
Please respond to
foxboro@xxxxxxxxxxxxx


To
<foxboro@xxxxxxxxxxxxx>
cc

Subject
Re: [foxboro] client server






Re: I haven't used it yet, but from what I see right now (after looking
at IACC), those tools seem to be answers to a question that I never
asked.

Is that because the question you want answered has to do with reporting
on and querying control schemes versus creation of control schemes?

Regards,
=

Alex Johnson
Invensys Systems, Inc.
10900 Equity Drive
Houston, TX 77041
713.329.8472 (voice)
713.329.1700 (fax)
713.329.1600 (switchboard)
alex.johnson@xxxxxxxxxxxxxxxx

-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of Corey R Clingo
Sent: Thursday, March 29, 2007 12:54 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] client server

Assuming one could rig up a remote command execution facility on a =

Foxboro-supplied Windows box without trouble, you would be correct; I =

could get to it.  But then it is little different than running a =

Foxboro-supplied utility to get the data.  You may have more query =

flexibility with SQL, but I guess I envision dumping all the data out
and =

putting it into a database/schema of my choosing anyway, so that =

flexibility does not really buy me anything.  Others of course may feel =

different.

And maybe this mindset is also one of the things that makes me favor
using =

the checkpoint as the primary DB, with auxiliary information as
required. =

It sounds like Invensys is doing this some with IEE (i.e., SQL server
plus =

some object data), though not utilizing the checkpoint is unfortunate.
It =

is probably also why I am not so excited about or concerned with =

IACC/IEE/day-after-tomorrow's configuration tool.  I haven't used it
yet, =

but from what I see right now (after looking at IACC), those tools seem
to =

be answers to a question that I never asked.


Corey Clingo
BASF Corporation








 
 
_______________________________________________________________________
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:             http://www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave

Other related posts: