Good to hear from you Rick. Was there a way to force the CP and the MTK to
regain their connection?
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Richard RYS
Sent: Friday, March 25, 2016 3:37 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] CP TIME SYNC WITH MASTER TIME-KEEPER (and associated
process alarm time-stamp)
Tom,
I had a system once where some of my CP 270's would lose their connection to
the MTK. So we built a CALCA block in each CP and outputted the seconds from
midnight (TIM) to IO01. We then build a tabular display that showed for each
CP: all the Station Block time parameters YYMMDDHHMM and the output from the
CALCA that showed seconds from midnight. That way we could see the time that
each CP had to the second.
Rick Rys
On 3/25/16, 8:45 PM, "Vandewater, Tom (HI Contractor)"
<foxboro-bounce@xxxxxxxxxxxxx on behalf of
TVandewater.contractor@xxxxxxxxxxxxxx> wrote:
Thanks for that feedback Alex. I would expect the CP's to be within a
second also but we ALWAYS see the same .MINUTE on all 35 CP's on our
MESH. Our CP image doesn't support reading the .SECOND value from the
CP's, but using omgetimp to get the .MINUTE value in a quick loop shows
us that the .MINUTE values are rolling to the next minute by as much as
30 seconds after the MTK rolls to a new minute. Most of these CP's
have been running continuously since Oct 2009. If the MTK isn't
updating them it would be a surprise to me that they could all still be
running within the same minute after 6+ years. Is there any way that
the MTK multicast could update each CP with every time/date value
except the SECONDS? The Service Rep here is also surprised by this.
Thanks again for your feedback,
Tom VandeWater
Control Conversions, Inc.
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx
[mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of Johnson, Alex
Sent: Friday, March 25, 2016 2:14 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] CP TIME SYNC WITH MASTER TIME-KEEPER (and
associated process alarm time-stamp)
The CP is supposed to be +/-1s of the MTK. If it is not, something is
wrong.
The SYSTEM block parameters reflect to time as the CP knows it. The MTK
does not change them. It sends messages to the CP and the CP adjusts
it's time. That is then reflected in the SYSTEN block.
The clock drift of the CP is quite low so the 30s offset should not occur.
Either the MTK's multicast messages are being list or the CP is sick.
I'd go with the messages being lost. I suggest that the traffic be
examined.
Regards,
Alex Johnson
Schneider Electric
10900 Equity Drive
Houston, TX 77041
+1 713 329 8472 (o)
alexander.johnson@xxxxxxxxxxxxxxxxxxxxxx
Sent from my iPhone. Please forgive the typos.
On Mar 25, 2016, at 6:56 PM, Vandewater, Tom (HI Contractor)
<TVandewater.contractor@xxxxxxxxxxxxxx> wrote:
Russ, David, and Alex,
Thanks so much for your very rapid response to some things I
could probably have found somewhere in the manuals but it is so much
nicer/easier to hear it from knowledgeable people;<) I didn't expect
to hear any feedback until after the Easter weekend.
We currently have our Foxboro Field Service Rep at site and he
told me that he thought the CP's are synced once every 10 minutes by
the MTK. He also said the Process Alarm time stamping was done by the CP.
He was surprised to see that the CP time could be off by as much as 30
seconds from the MTK time but he saw it with his own eyes. We are now
wondering, based on your comments, if the MTK cannot actually write
the SECONDS at our CP Software REV and thus only updates the CP's
.MINUTE value. This would cause the CP's to always be within a minute
of the MTK but each CP has its own SECOND counter and the MTK update
from the MINUTE write doesn't cause the SECOND to automatically reset
when the MTK syncs?? Just our thoughts.
Is there any other reason an FCP might be up to 30 seconds away from
the MTK SECOND?
To David Johnson, thanks for that +SYNC tip for the TRICONEX
TSAA interface. It is a good thing to know when using/referencing the
SOE time/date functionality provided in the Triconex application. I
expect the SYNC is using the FDSI host CP's time/date info and not the
MTK directly. Do you know if that is true?
Thanks again and Happy Easter,
Tom VandeWater
Control Conversions, Inc.
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx
[mailto:foxboro-bounce@xxxxxxxxxxxxx] On Behalf Of Johnson, Alex
Sent: Friday, March 25, 2016 11:36 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] CP TIME SYNC WITH MASTER TIME-KEEPER (and
associated process alarm time-stamp)
Process Alarms are time stamped by the CP.
System Alarms are time stamped by the System Monitor.
The original STATION block did not show all the time date available
to the CP. Don¹t ask me why. I haven¹t a clue.
The MTK does not time stamp anything. It simply sends out information
about the current time to the stations. The stations use that
information.
AJ
----------- Please note that my email address has changed. Please
update my contact information to reflect my address as forwarding for
the old address will end on January 1st 2016. The only change is
modifying the domain name of the email address from @ppetrol.com to
@parpacific.com.
_____________________________________________________________________
_ ___ 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
----------- Please note that my email address has changed. Please
update my contact information to reflect my address as forwarding for
the old address will end on January 1st 2016. The only change is
modifying the domain name of the email address from @ppetrol.com to
@parpacific.com.
_______________________________________________________________________
__ 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
