[foxboro] INtools (was: client server)

Corey,
INtools is an interesting subject. 

What should an INtools interface to our configurators do?

What about the rest of SmartPlant?

AJ


-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx on behalf of Corey R Clingo
Sent: Thu 3/29/2007 7:49 PM
To: foxboro@xxxxxxxxxxxxx
Subject: 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
 





Confidentiality Notice:
The information contained in this electronic message and any attachment(s) to 
this message are intended for the exclusive use of the recipient(s) and may 
contain confidential, privileged or proprietary information. If you are not the 
intended recipient, please notify the sender immediately, delete all copies of 
this message and any attachment(s). Any other use of the E-Mail by you is 
prohibited.


-- No attachments (even text) are allowed --
-- Type: application/ms-tnef
-- File: winmail.dat


 
 
_______________________________________________________________________
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: