Re: [foxboro] CP TIME SYNC WITH MASTER TIME-KEEPER (and associated process alarm time-stamp)

  • From: Richard RYS <rys@xxxxxxxxxxxxxx>
  • To: <foxboro@xxxxxxxxxxxxx>
  • Date: Fri, 25 Mar 2016 21:37:06 -0400

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




 
 
_________________________________________________________________________
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
 

Other related posts: