Re: [foxboro] FDSI gateway differences again

Is it a problem to have the remote setpoints go thru the FDSI (rather
than directly) and have I/A decide which value to write back?
(This would, of course, involve reprogramming the remote devices.)

Brad Wilson
brad.wilson@xxxxxxxxxxxxxxxx
Invensys Process Systems, Inc
1090 King Georges Post Rd, Suite 204
Edison, NJ  08837
732-661-4012 o
732-874-0087 c

-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of David Johnson
Sent: Wednesday, October 22, 2008 1:02 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] FDSI gateway differences again

At 09:25 AM 10/22/2008, you wrote:
>Why wouldn't you build one DCI block and connect other blocks to that?
>
>Read  FDSI --> DCI --> as many input blocks as you like

I'm good with this.

>Write FDSI <-- DCI <--  CALC or SWCH <-- multiple output blocks

OK,

The problem occurs with the following scenario.
Multiple remote modbus devices can write a setpoint (not all visible 
to  I/A, timing is flaky).
I/A needs to write the setpoint if desired from the I/A screen.  The 
setpoint is only in one holding register.

The current configuration (I didn't write this) reads the value as an 
input then writes it as an output.
AIN [Holding Reg 1]  RI01->CALC BLOCK->RO01 AOUT [Holding Reg 1]
Operator Setpoint     RI02->CALC  BLOCK
Operator Accept      BI01 -> CALC BLOCK

So I/A is constantly writing the value to the gateway, if it was 
changed remotely, I/A sees and passes this change through.   If you 
want to change it locally, the operator enters the value RI02, hits 
the accept trigger BI01, and CALC BLOCK writes the I/A value until it 
sees it come back on the modbus AIN RI01, then it releases it so 
other remote locations can set it.  This might still work with the 
FDSI by just writing the value for some fixed (sufficient) time 
period, but operationally it will be different.  Currently the I/A 
operator is guaranteed that any setpoint change from him will 
take.  If the loopback is omitted a remote operator could win, (if 
the setpoint is changed in the same couple of seconds).

Anyway it's a hassle.  Many people (some without meaning to) took 
advantage of weird things a gateway could do , and now the FDSI 
doesn't allow all of the same tricks.

Thanks,
David

* Confidentiality Notice:
This e-mail and any associated files are intended solely for the individual or 
entity to whom they are addressed. Please do not copy it or use it for any 
purposes, or disclose its contents to any other person. Further, this e-mail 
and any associated files may be confidential and further may be legally 
privileged. This email is from the Invensys Process Systems business unit of 
Invensys plc which is a company registered in England and Wales with its 
registered office at Portland House, Bressenden Place, London, SW1E 5BF 
(Registered number 166023).  For a list of European legal entities within the 
Invensys Process Systems business group, please click here 
http://www.invensys.com/legal/default.asp?top_nav_id=77&nav_id=80&prev_id=77.

If you have received this e-mail in error, you are on notice of its status. 
Please notify us immediately by reply e-mail and then delete this message from 
your system. Thank you for your co-operation. You may contact our Helpdesk on 
+44 (0)20 7821 3859 / 2105 or email inet.hqhelpdesk@xxxxxxxxxxxxx This e-mail 
and any attachments thereto may be subject to the terms of any agreements 
between Invensys (and/or its subsidiaries and affiliates) and the recipient 
(and/or its subsidiaries and affiliates).


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