Thanks for that feedback Rick. We are also running 8.4.3 and seeing the
SECONDS not being in SYNC with the MTK, but YY:MM:DD:HH:MM are in sync on ALL
35 FT FCP's on the MESH. To me it seems like the CP's are actually being
sync'ed by the MTK YY:MM:DD:HH:MM but that they continue to keep their own
SECOND value from their initial boot and ignore the MTK seconds. Since 8.4.3
CP's didn't have an OM exported value for .SECONDS until Ver. 8.5 I wonder if
this was just the way it works prior to 8.5? I am trying to decide if
upgrading the FCP images to the latest FCP270 image during a turnaround reboot
would be helpful to resolve this issue.
Any thoughts out there regarding this?
Are there any known issues with upgrading FCP images to the latest SOFTWARE
image while continuing to run Ver. 8.4.3 base IA Version?
I have implemented a SEQ Block 1st out strategy that uses the CP
YY:MM:DD:HH:MM to send and retain the last 20 shutdown causes for major pieces
of equipment. It stores the messages in SEQ block .SN0001-10 strings that can
be reviewed by operations technicians to see if they are having repetitive
causes for shutdowns. I currently only timestamp to the MINUTE because that
was all that was available from the CP's and that is good enough for the
purposes of my 1st Out. I remember seeing your SECONDS since midnight CALC
before and thinking about implementing it, but would rather the CP would
provide it and stay in Sync with the MTK. Sounds like it does at 8.5 and
greater CP image. I would also like to make sure our Triconex FDSI interfaces
are in SYNC with CP/MTK times. That sounds pretty simple using the +SYNC
command in DVOPTS parameter of the Child ECB201 as David Johnson has suggested.
Thanks to all who participated in this thread. Your contributions and
recommendations have been most helpful.
Tom VandeWater
Control Conversions, Inc.
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Richard RYS
Sent: Saturday, March 26, 2016 2:23 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] CP TIME SYNC WITH MASTER TIME-KEEPER (and associated
process alarm time-stamp)
Tom,
Our system was a testbed system not for production. Not sure we ever found out
precisely why some CP's would go out of time synch. We noticed a few CP's would
be out of synch right after initialization and reloading.
We also found some cases where the "ms" timestamp for an AIM-API datapoint was
a negative number, so that was a CAR. At that time we had a number of CP's
that exceeded the allowed number of peer-to-peer connections and we also had
some issues with a non-supported configuration for an IRIG-B GPS, so we were
not in a stable system. Time synch problems eventually cleared up, rebooting
often cleared our problem, but we had a lot of stress on that test system. We
were at IA 8.4.3.
Rick Rys
On 3/25/16, 11:04 PM, "Vandewater, Tom (HI Contractor)"
<foxboro-bounce@xxxxxxxxxxxxx on behalf of
TVandewater.contractor@xxxxxxxxxxxxxx> wrote:
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
_______________________________________________________________________
__ 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
