Experience helps a lot, ojt, listening to others advice,
The FDSI relationship with the CP in almost all cases is asynchronous. AJ just
said that.
This means to me and how I configure DCI vs scan rate the following;
FDSI Scan Rate = 500 msec ------ DCI period = 1000 msec or slower
Regards,
Scott
________________________________________
From: foxboro-bounce@xxxxxxxxxxxxx [foxboro-bounce@xxxxxxxxxxxxx] On Behalf Of
Joseph M. Riccardi [Joe@xxxxxxxxxxxxx]
Sent: Wednesday, June 15, 2016 5:33 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] DCI Block on-demand scanning vs scheduled
AMEN, Tom... Every time I configure one of these FDSIs, I spend 10X the
amount of time establishing the initial communications than I do the
subsequent configuration of 1,000 blocks. And yes I try to follow your
advice (RTFMs) but I find them confusing at best...
Joseph M. Riccardi
386-451-7607 Cell
Joe@xxxxxxxxxxxxx
"To give real service you must add something that cannot be bought or
measured with money; and that is sincerity and integrity." - Donald A. Adams
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of Vandewater, Tom (HI Contractor)
Sent: Wednesday, June 15, 2016 2:51 PM
To: 'foxboro@xxxxxxxxxxxxx' <foxboro@xxxxxxxxxxxxx>
Subject: Re: [foxboro] DCI Block on-demand scanning vs scheduled
Alex Johnson,
I don't know if you are in a position to recommend a resource, but
it would be helpful to many of us if a Foxboro FDSI Communication
Development expert could shed a bit more light on the communication
mechanisms employed by the FDSI. I do think they have been continually
modifying/optimizing this over time so it probably depends what version
software, firmware, and drivers you are using. I also realize it is a
complex issue because of the all the different communication protocols
possible, and might be considered a "can of worms";<) What many would like
to understand is there a best practice recommended to optimize communication
bandwidth while minimizing data timeouts. We are like a blind man trying to
describe an elephant by touching it everywhere we can reach;<) Thanks for
anything you can offer. We are RTFM but it doesn't give us quite enough
info to understand what we should do to optimize.
Matt,
I agree that if you read what you found, (posted below), in B0700AH
it would lead you to believe that you CAN control data requests across the
FDSI data communication link using PERIOD and PHASE settings. I have not
found that to be true. By default, it appears to me, that a list of
variables defined by the DCI Blocks you create, gets created and then that
list is sent to the FDSI Parent. It may do some optimization of the
requests to minimize the communication load as best it can. From there, by
default, it polls all of those data registers and gathers the response in
its own data table for the DCI blocks to read. By default, the FDSI starts
the next data cycle request as soon as the last communication handshake is
complete so there is no lag of communication across the data link. When you
use Child ECB 201 DVOPT qualifiers you can tell the Parent to pause in
between the requests by a defined FDSI Comm period as Brahm mentioned:
"DVOPTS= EIP/CLX+@10+TO=20+XML+SN=2+TS"
"This syntax indicates that the driver name is EIP, the device is the
ControlLogix type, the scan message period is 1000 ms, the response timeout
is 2000 ms, a device configuration file is used, and the ControlLogix
processor card (Logix 55xxx or Logix 56xxxx) is located at slot 2 of the
ControlLogix chassis.
To use the "TS" option, configure the ControlLogix device as described in
Chapter 4 "Control-Logix Configuration"."
There are also "scan message period" and "response timeout" settings
available for each Port defined in a parent ECB200.XML file. At least for
the Serial communication FBM230. I have used it on at least one occasion by
adding the following command at the Serial Port definition section of the
.XML flie <driver>Modbus+@100+TO=200</driver>
Regards,
Tom VandeWater
Control Conversions, Inc.
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of Kinsinger, Matthew R
Sent: Wednesday, June 15, 2016 1:48 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] DCI Block on-demand scanning vs scheduled
I guess what I was trying to build on was the following excerpt from B0700AH
**Start Quote**
ECBs scheduled to be processed are executed to read fresh inputs:
When a parent or child ECB is processed, its DCI linked list is examined.
For each DCI input or output block ready to be run in that BPC, its DCI
connection requests are added to a read list for that ECB.
When the read list is complete, a Read_Data message is sent to the FBM to
retrieve the current data contained in the DCI connection records in the
FBM. (If necessary, multiple messages are used to retrieve, from each FBM,
all data required by the DCI blocks for that BPC.) All read list data is
moved into the DCI connection records in the DCI blocks as data is
retrieved.
**End Quote**
However, based on Tom V and gheyll's emails (along with some other's info),
I'm wondering if this is never true for the FDSI to Ethernet device
communication? Or if possibly you can only prove this sort of a change on
initial setup with a clean, initialized installation?
Matt Kinsinger
mkinsinger@xxxxxxx
330-472-1454 ppg cell
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of Joseph M. Riccardi
Sent: Tuesday, June 14, 2016 10:04 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] DCI Block on-demand scanning vs scheduled
I am not on site and working from memory but aren't the ECBs
(driver/scanner) in the Compound:ECB? Let me re-paraphrase the manual
explanation...
CMP - On/Off is a parameter that enables or disables the "execution" of all
blocks (including ECBs) within the compound, where: 1 = on; 0 = off.
Not sure if I am barking up the wrong tree or not...
Joseph M. Riccardi
386-451-7607 Cell
Joe@xxxxxxxxxxxxx
"To give real service you must add something that cannot be bought or
measured with money; and that is sincerity and integrity." - Donald A. Adams
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of gheyIl .
Sent: Tuesday, June 14, 2016 8:49 PM
To: Foxboro mailing list <foxboro@xxxxxxxxxxxxx>
Subject: Re: [foxboro] DCI Block on-demand scanning vs scheduled
My experience with FDSI is that the compound/block status only affects how
the CP reads the data from the FDSI.
Once the scan has been built, the FDSI will always scan the device as long
as comms are enabled.
Turning off the compound, or putting the block in manual, only stops the CP
from reading the input table in the FDSI.
_________________________________________________________________________
This mailing list is neither sponsored nor endorsed by Schneider Electric
(formerly The Foxboro Company). Use the info you obtain here at your own
risks. See the disclaimer at 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 Schneider Electric
(formerly The Foxboro Company). Use the info you obtain here at your own
risks. See the disclaimer at 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 Schneider Electric
(formerly The Foxboro Company). Use the info you obtain here at your own
risks. See the disclaimer at 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 Schneider Electric
(formerly The Foxboro Company). Use the info you obtain here at your own
risks. See the disclaimer at 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 Schneider Electric
(formerly The Foxboro Company). Use the info you obtain here at your own
risks. See the disclaimer at 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 email has been scanned by the Symantec Email Security.cloud service.
______________________________________________________________________
*** Confidentiality Notice: This e-mail, including any associated or attached
files, is intended solely for the individual or entity to which it is
addressed. This e-mail is confidential and may well also be legally privileged.
If you have received it in error, you are on notice of its status. Please
notify the sender immediately by reply e-mail and then delete this message from
your system. Please do not copy it or use it for any purposes, or disclose its
contents to any other person.
_________________________________________________________________________
This mailing list is neither sponsored nor endorsed by Schneider Electric
(formerly The Foxboro Company). Use the info you obtain here at your own
risks. See the disclaimer at 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
