Re: [foxboro] OPC & SSC

  • From: "Pat Martens" <fox@xxxxxxxxxxxxxxx>
  • To: <foxboro@xxxxxxxxxxxxx>
  • Date: Sun, 18 Feb 2007 13:17:26 +0100

Thanks Alex,

So, if I understand correctly the basics are the same as DMCbridge:

Create AOS's for each MV.
Map these to the control blocks.
Have OPC read/write the AOS's (equivalent to DMCbridge CIMIO).

Pat,

-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of Johnson, Alex P (IPS)
Sent: zaterdag 17 februari 2007 16:08
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] OPC & SSC

Pat,

I'd be happy to help you with this.

Re: OPC and SSC

The OPC Specification does not support the type of handshake required by
our Supervisory Setpoint Control mechanism.

The workaround is a piece of software sold by the Project Operations
Advanced Applications Development group. This group - which I lead in my
spare time - develops niche products for I/A Series and InFusion users.

We have developed an offering - SSCSupport - the adapts OPC based MVC to
the I/A Series SSC mechanism. I will send you the manual off list.=20

The pre-requisite for SSCSupport is the use of the latest version of
AIM*OPC DA Server and all of the required QFs.

The program was developed for a specific project almost 10 years ago for
Solaris and due to low volume (1 sale until the last year or so) t is
not sold through BuyAutomation.com. Rather, your Account Representative
needs to contact Karen Willis. The following information is required:

1) I/A Series Version
2) OS of the AW hosting the OPC DA Server

With this information, Karen can supply pricing and delivery
information.

BTW, Total is a user of SSCSupport at a different site. That site can
tell you about the issues we had and corrected. I'll send the manual
off-list.

Re: SSC control group span

An MVC controller addresses a group of control blocks (PID-family, RATIO
or AOUT) in a set of controllers. All of the control blocks in a given
CP should be assigned to the same control group using the appropriate
parameter in the block.

The reset value of that control group should set to (typically) 2.5
times the period of the controller. This is done by setting the correct
parameter in the station block.

As the MVC changes its setpoints, the countdown timer will be reset
automatically when any control block in the group has its SUP_IN
parameter set.

The control blocks in different CPs manipulated by the same MVC do not
need to be in the same supervisory group.

There is no relationship among control blocks in different CPs.


Re: DMCplus Bridge and SSC Groups

The DMCplus Bridge does require, by default, all MVs in a controller to
be in the same group, but this is not a requirement of the I/A Series.
It's merely a simplification that can be overridden at need.


Re: Example
Yes.


Re: New MVC and new CP

No problem.


Regards,
=20
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 Pat Martens
Sent: Saturday, February 17, 2007 4:25 AM
To: foxboro@xxxxxxxxxxxxx
Subject: [foxboro] OPC & SSC

Hi all,
=20

Anybody out there who has used Supervisory Setpoint Control by means of
OPC?

=20

We use the DMCbridge which works great with SSC but now need to
implement an
other application which needs to talk to I/A through OPC. I was hoping
we
could used the standard SSC methods.

Is there any documentation available (apart from the SSC B0193RY manual)
which specifically addresses the OPC/SSC combination?

=20

I am completely new to OPC so I don't know what it can/cannot do?

=20

For SSC you need to be able to set/read the status bits (.LHI, .LHO,
=2EINITC,
=2EACK etc) in/from parameters like .BLKSTA, .SUPBCO, .SUP_IN.

Also 'single shot write' to the .SE parameter should be possible.

=20

Can you do all of these things with OPC ?

=20

Another related question:

The SSC 'control group' 'span' is limited to the CP it is configured in,
right?

You would need to 'cascade' the control group by linking if you would
want
the control group to 'span' multiple CP's, right?

Example: I could have 2 individual applications both using control group
1
as long as all control blocks for applic. 1 are in CP1 and all control
blocks for applic. 2 are in CP2?

We've used up all 8 control groups already but this new application will
be
dealing with completely new CP's.=20

=20

Thanks in advance for your, highly appreciated,  feedback.

=20

Patrick Martens,

Process Automation Specialist

Total Raff. Ned. N.V

=20



=20
=20
_______________________________________________________________________
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
=20
foxboro mailing list:             //www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Djoin
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
=20



Confidentiality Notice: =0AThe information contained in this electronic m=
essage and any attachment(s) to this message are intended for the exclusi=
ve use of the recipient(s) and may contain confidential, privileged or pr=
oprietary information. If you are not the intended recipient, please noti=
fy the sender immediately, delete all copies of this message and any atta=
chment(s). Any other use of the E-Mail by you is prohibited.=0A

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