Why does this sound so familiar??
Sent from my iPhone
On Jun 16, 2016, at 12:06 AM, "Vandewater, Tom (HI Contractor)"
<TVandewater.contractor@xxxxxxxxxxxxxx> wrote:
Joe,
I have gotten better at getting it right the first time because I have
done so many of these interfaces in the last 18 months but it is still quite
an ordeal to get it working. As you said, adding DCI blocks after it is
working correctly is not a problem.
Tom
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Joseph M. Riccardi
Sent: Wednesday, June 15, 2016 12: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 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
