TIME DIFFERENCE IN CIMPLICITY OVER VIEW AND ALARM VIEW
- Thread starter anees
- Start date
Hello Anees,
The thing that you can do for your information, is to have read on these threads regarding incorrect time/date inMark HMI/CIMPLICITY:
https://control.com/forums/threads/...el-date-and-time-using-hmi-not-lt-i-gt.25552/
https://control.com/forums/threads/mk-5-hmi-time-display-problem.25450/
Thats what i can suggest till now , without be able to have a read on Mark5 HMI/CIMPLICITY manual.
I am sure it can help for resolving this issue.
ControlsGuy25.
The thing that you can do for your information, is to have read on these threads regarding incorrect time/date inMark HMI/CIMPLICITY:
https://control.com/forums/threads/...el-date-and-time-using-hmi-not-lt-i-gt.25552/
https://control.com/forums/threads/mk-5-hmi-time-display-problem.25450/
Thats what i can suggest till now , without be able to have a read on Mark5 HMI/CIMPLICITY manual.
I am sure it can help for resolving this issue.
ControlsGuy25.
The top picture shows the time that is displayed by the MKV itself. The alarm manage application utilizes the clock on the local HMI. Timesync.dat is the file that needs to be configured.
I usually have one HMI that can use NTP from a time source. That is the master. All other HMI and the MKV are slaves.
I usually have one HMI that can use NTP from a time source. That is the master. All other HMI and the MKV are slaves.
CAN YOU ANY ONE HELP ME WITH THIS ?
Well, uh, ..., er, ..., you have no data showing on the Overview display. And, no Diagnostic Alarms in the Alarm Window. There is no communication with a Mark V panel, as shown by the has marks in the data fields. I would imagine any display elements that are tied to logic states are also black or dark--because there is not data being received from a Mark V.
I, personally, have NEVER seen a date of 1601 (A.D.) shown on any CIMPLICITY display. I would have to say that--and this is a first for me, too--that the CPU (Central Processing Unit--the PC that's being used as an HMI) is not an "approved" CPU. I feel fairly safe in saying this for another reason--because the ARCnet card is apparently NOT communicating with a Mark V, and that's probably because the CPU and/or the ARCnet card is probably not configured properly and/or are not compatible. (I see this a lot--when a GE Mark V HMI CPU dies, people just go and obtain another CPU and (wrongly) believe all CPUs are the same and it should (will) work fine. BUT, that's NOT true. The CPU BIOS has to be capable of communicating with and using the ARCnet card, and the microprocessor and other components of the CPU have be able to communicate with each other (via buses and such).)
Write back when you have data and alarms--communication with a Mark V. You'll have a different picture to show, and probably different questions, too.
[The Alarm Window of a GE Mark V HMI is a special object (as it is called) that just gets the honor of being allowed to appear in a CIMPLICITY display. It uses a proprietary communication protocol to be made aware of alarms (both Process and Diagnostic) and events (SOEs and EVENTs--isn't this FUN!!!???), directly via the ARCnet card and StageLink. Alarms and events that appear in the Alarm window object get their time tag from the Mark V. I am guessing it's possible that there is some communications going on between the HMI CPU and ARCnet card and that the time in the Mark V the HMI CPU is connected to is the same as the time shown on the LCC/SLCC displays of the Mark V panel.... But, that's a SWAG (Scientific Wild-Arsed Guess). The time shown in the top of the CIMPLICITY display, I believe (if I recall correctly) comes from the CPU BIOS clock, which I feel pretty safe in saying is not set correctly, if at all.]
Again, write back when you get the time set in the HMI CPU, and when you get data in CIMPLICITY fields.
Well, uh, ..., er, ..., you have no data showing on the Overview display. And, no Diagnostic Alarms in the Alarm Window. There is no communication with a Mark V panel, as shown by the has marks in the data fields. I would imagine any display elements that are tied to logic states are also black or dark--because there is not data being received from a Mark V.
I, personally, have NEVER seen a date of 1601 (A.D.) shown on any CIMPLICITY display. I would have to say that--and this is a first for me, too--that the CPU (Central Processing Unit--the PC that's being used as an HMI) is not an "approved" CPU. I feel fairly safe in saying this for another reason--because the ARCnet card is apparently NOT communicating with a Mark V, and that's probably because the CPU and/or the ARCnet card is probably not configured properly and/or are not compatible. (I see this a lot--when a GE Mark V HMI CPU dies, people just go and obtain another CPU and (wrongly) believe all CPUs are the same and it should (will) work fine. BUT, that's NOT true. The CPU BIOS has to be capable of communicating with and using the ARCnet card, and the microprocessor and other components of the CPU have be able to communicate with each other (via buses and such).)
Write back when you have data and alarms--communication with a Mark V. You'll have a different picture to show, and probably different questions, too.
[The Alarm Window of a GE Mark V HMI is a special object (as it is called) that just gets the honor of being allowed to appear in a CIMPLICITY display. It uses a proprietary communication protocol to be made aware of alarms (both Process and Diagnostic) and events (SOEs and EVENTs--isn't this FUN!!!???), directly via the ARCnet card and StageLink. Alarms and events that appear in the Alarm window object get their time tag from the Mark V. I am guessing it's possible that there is some communications going on between the HMI CPU and ARCnet card and that the time in the Mark V the HMI CPU is connected to is the same as the time shown on the LCC/SLCC displays of the Mark V panel.... But, that's a SWAG (Scientific Wild-Arsed Guess). The time shown in the top of the CIMPLICITY display, I believe (if I recall correctly) comes from the CPU BIOS clock, which I feel pretty safe in saying is not set correctly, if at all.]
Again, write back when you get the time set in the HMI CPU, and when you get data in CIMPLICITY fields.
I just got a hand on this interesting GEI100513 HMI TIME SYNCHRONIZATION Manual:
https://pdfslide.net/documents/gei-100513-hmi-time-synch.html
Also , I strongly suggest you to read the GEH-6126C Vol I&II HMI application guide.
I am sure that it got the solution for this issue!
ControlsGuy25.
Dear all , thank you for you support
i try editing timesync.dat but nothing is changing ....
dear #CSA this CPU which we are using is HP compact dc 7700 . this is same using in the most plants in mark v hmi as per my knowledge . and there no communication problem with markV and hmi . i tried timesync , aslo NTP .
BUT NOTHING IS CHANGING .
AND NOW I AM STRACK WITH THIS .
TIMESYNC.BAK IS THERE AND TIMESYNC.DAT IS THIS BOTH ARE SAME ?
TIMESYNC.BAK
; Timesync.dat file generated by TCICPL on 13:03:26 07-18-2020
TIMESYNC LOWRES
LOCAL_TIMESET ENABLED
TIME_LOAD LOCAL
TIMESYNC.DAT
; Timesync.dat file generated by TCICPL on 18:11:31 07-18-2020
TIMESYNC LOWRES
LOCAL_TIMESET DISABLED
TIME_LOAD LOCAL
IS THERE ANYING WRONG ??
CAN YOU ANY ONE HELP ME WITH THIS ?
i try editing timesync.dat but nothing is changing ....
dear #CSA this CPU which we are using is HP compact dc 7700 . this is same using in the most plants in mark v hmi as per my knowledge . and there no communication problem with markV and hmi . i tried timesync , aslo NTP .
BUT NOTHING IS CHANGING .
AND NOW I AM STRACK WITH THIS .
TIMESYNC.BAK IS THERE AND TIMESYNC.DAT IS THIS BOTH ARE SAME ?
TIMESYNC.BAK
; Timesync.dat file generated by TCICPL on 13:03:26 07-18-2020
TIMESYNC LOWRES
LOCAL_TIMESET ENABLED
TIME_LOAD LOCAL
TIMESYNC.DAT
; Timesync.dat file generated by TCICPL on 18:11:31 07-18-2020
TIMESYNC LOWRES
LOCAL_TIMESET DISABLED
TIME_LOAD LOCAL
IS THERE ANYING WRONG ??
CAN YOU ANY ONE HELP ME WITH THIS ?
Hello ALL?
Anees,
Did youy have look on GE doc that I shared?
I am not at your site but this document, should be an help/support for getting that Time synchronysation configured .
Thanks for your feedback,
ControlsGuy25.
Yes.... i tried with the documents you give... its also not worrking.
There is 2 faile in F drive.
One is tymesync.dat.
And ome is tymesync.bat
I cahnged tymesync.dat. is that both file to be edited or only faile need to change...???
I sincerely question why ANY file has to be edited!!! When did this problem start? In other words, when did this problem become apparent--and most importantly what happened immediately before the time the problem became apparent???!!!???
A . bat file is a batch file--it executes a series of command's/programs when it is run from a command prompt. A .bat file is an ASCII text file, so it can be opened and viewed with any file editor/viewer to see what is in the file. (I wouldn't go editing the . bat file, and when exiting the file I would be sure NOT to save any changes and to make sure it gets saved in the format it was opened in (plain ASCII text, in other words).)
TIMESYNC.DAT is a file that usually only has to be created ONCE--during commissioning, because that's when the local time offsets (from GMT/UTC and any local time adjustments) are incorporated to the file to be used by NTP.
At this point, I'm going to suggest the problem is with the master time signal--whatever that is coming from (usually, on newer systems it comes from a master time server, which gets it's signal from an antenna of some kind or from an Internet connection, then broadcasts the signal out to all of the NTP clients on the network. Some older time synchronization systems used coaxial cables to broadcast the master time signal to NTP (which is a program/app which runs in the background on an HMI--there is usually a little analog clock face in the status bar at the lower right corner of the display; if the face is white it means one thing; if the face is green it means another thing; if the face is red it means something else).
Newer systems connected the output of the Master Time Server to the UDH network (which a Mark V doesn't have) which is a UTP cable, usually, which transmitted the master time signal on to the UND (Unit Data Highway) which was then picked up by NTP.
There are several types of master time signals/formats, as well as several types of formats of the master time signal which is sent out by the master time server over whatever network/media is being used. HAS SOMETHING CHANGED WITH THIS NETWORK RECENTLY???
anees said the HMI CPU is the same as one frequently used for GE Mark V HMIs--but he didn't say if it is the original HMI or one which has been found which is being used to replace one which has failed.
I have NEVER persosnally seen any time/date on a GE Mark V HM other than one that started in Jan 1980 (when the system clock has not been initialized), or one that is off by a few hours or days or weeks or months--but not by centuries. To me, being off by centuries reaks of problems with NTP and the master time source/signal. Especially with the new displays that were just attached to the most recent post by the original poster.
AGAIN: What changed immediately before this problem was solved??? Is this the original HMI CPU or some replacement that is "like" the one being replaced? Has the master time server been replaced, or reset, or are the cables properly connected? Has someone been mucking with the format of the master time signal (pulses per second, or pulses per minute, etc.)?
Finally, a .bak file is a back-up file. GE, as a way of protecting well-meaning people from themselves, used to have their programs create . bak files every time a new file (say a .dat file, for example) was created; the . bak file was the file being replaced. This way, recovery for those who failed to make back-ups BEFORE they start running programs willy-nilly was a little easier.
Anyway, something we haven't been informed of has changed. And, now someone is trying to recover from this change without telling all of the details--thinking that if they can just get a procedure for the entire set-up of a time synchronization scheme on a GE Mark V HMI that everything will be alright. Well, that's just not true. There were several iterations and generations and (per-)versions of time synchroniztion. Some shared some of the same files and configuration information, and some didn't. We have no idea where the master time signal comes from or passes through (as was said is a previous thread--sometimes, one of the HMIs was used as the master time signal "processor" and the "antenna" signal was passed to it, and from there it was passed to other HMIs (and Mark Vs). We would really need to see the 4108 (or, A108) Network Topology drawing to know how time synchronization is being done at the site. But, it's probably a very safe bet to say: It WAS working, until something (which we haven't been informed of) was done or happened or changed, and now it's NOT working.
That's about it. When problems like this happen, it's usually traceable back to something which was done, intentionally or unintentionally, that precipitated the problem. When something WAS working, and then it stops working--even if it's software (and not a failed pump bearing or solenoid) it's usually because something happened. Figure out, or tell us, what happened, and then you can set about restoring the system.
It's an unfortunate FACT that GE was very remiss in documenting all of the iterations and generations and (per-)versions of their programs and applications and configurations. As technology changed, things changed--and they just did not document those changes like they should have. Just because one has a Frame 5 or a Mark V does not mean their Frame 5 or their Mark V is the same as every other Frame 5 or Mark V. Just like every Mercedes is not like every other Mercedes.
A . bat file is a batch file--it executes a series of command's/programs when it is run from a command prompt. A .bat file is an ASCII text file, so it can be opened and viewed with any file editor/viewer to see what is in the file. (I wouldn't go editing the . bat file, and when exiting the file I would be sure NOT to save any changes and to make sure it gets saved in the format it was opened in (plain ASCII text, in other words).)
TIMESYNC.DAT is a file that usually only has to be created ONCE--during commissioning, because that's when the local time offsets (from GMT/UTC and any local time adjustments) are incorporated to the file to be used by NTP.
At this point, I'm going to suggest the problem is with the master time signal--whatever that is coming from (usually, on newer systems it comes from a master time server, which gets it's signal from an antenna of some kind or from an Internet connection, then broadcasts the signal out to all of the NTP clients on the network. Some older time synchronization systems used coaxial cables to broadcast the master time signal to NTP (which is a program/app which runs in the background on an HMI--there is usually a little analog clock face in the status bar at the lower right corner of the display; if the face is white it means one thing; if the face is green it means another thing; if the face is red it means something else).
Newer systems connected the output of the Master Time Server to the UDH network (which a Mark V doesn't have) which is a UTP cable, usually, which transmitted the master time signal on to the UND (Unit Data Highway) which was then picked up by NTP.
There are several types of master time signals/formats, as well as several types of formats of the master time signal which is sent out by the master time server over whatever network/media is being used. HAS SOMETHING CHANGED WITH THIS NETWORK RECENTLY???
anees said the HMI CPU is the same as one frequently used for GE Mark V HMIs--but he didn't say if it is the original HMI or one which has been found which is being used to replace one which has failed.
I have NEVER persosnally seen any time/date on a GE Mark V HM other than one that started in Jan 1980 (when the system clock has not been initialized), or one that is off by a few hours or days or weeks or months--but not by centuries. To me, being off by centuries reaks of problems with NTP and the master time source/signal. Especially with the new displays that were just attached to the most recent post by the original poster.
AGAIN: What changed immediately before this problem was solved??? Is this the original HMI CPU or some replacement that is "like" the one being replaced? Has the master time server been replaced, or reset, or are the cables properly connected? Has someone been mucking with the format of the master time signal (pulses per second, or pulses per minute, etc.)?
Finally, a .bak file is a back-up file. GE, as a way of protecting well-meaning people from themselves, used to have their programs create . bak files every time a new file (say a .dat file, for example) was created; the . bak file was the file being replaced. This way, recovery for those who failed to make back-ups BEFORE they start running programs willy-nilly was a little easier.
Anyway, something we haven't been informed of has changed. And, now someone is trying to recover from this change without telling all of the details--thinking that if they can just get a procedure for the entire set-up of a time synchronization scheme on a GE Mark V HMI that everything will be alright. Well, that's just not true. There were several iterations and generations and (per-)versions of time synchroniztion. Some shared some of the same files and configuration information, and some didn't. We have no idea where the master time signal comes from or passes through (as was said is a previous thread--sometimes, one of the HMIs was used as the master time signal "processor" and the "antenna" signal was passed to it, and from there it was passed to other HMIs (and Mark Vs). We would really need to see the 4108 (or, A108) Network Topology drawing to know how time synchronization is being done at the site. But, it's probably a very safe bet to say: It WAS working, until something (which we haven't been informed of) was done or happened or changed, and now it's NOT working.
That's about it. When problems like this happen, it's usually traceable back to something which was done, intentionally or unintentionally, that precipitated the problem. When something WAS working, and then it stops working--even if it's software (and not a failed pump bearing or solenoid) it's usually because something happened. Figure out, or tell us, what happened, and then you can set about restoring the system.
It's an unfortunate FACT that GE was very remiss in documenting all of the iterations and generations and (per-)versions of their programs and applications and configurations. As technology changed, things changed--and they just did not document those changes like they should have. Just because one has a Frame 5 or a Mark V does not mean their Frame 5 or their Mark V is the same as every other Frame 5 or Mark V. Just like every Mercedes is not like every other Mercedes.
Dear CSA ,
this problem has started when we removed hard disk for taking back up . did the back up with acronics . and that back alos working fine . but time is same .
and our HMI is original one .
#ControlsGuy25 :
timesync.test file you have sherd and in my F drive time sync file is totally different
timesync.dat :
; Timesync.dat file generated by TCICPL on 18:11:31 07-18-2020
TIMESYNC LOWRES
LOCAL_TIMESET DISABLED
TIME_LOAD LOCAL
this problem has started when we removed hard disk for taking back up . did the back up with acronics . and that back alos working fine . but time is same .
and our HMI is original one .
#ControlsGuy25 :
timesync.test file you have sherd and in my F drive time sync file is totally different
timesync.dat :
; Timesync.dat file generated by TCICPL on 18:11:31 07-18-2020
TIMESYNC LOWRES
LOCAL_TIMESET DISABLED
TIME_LOAD LOCAL
Okay; so we now know when it started--though it's UNCLEAR why the hard disk had to be removed to make the Acronis back-up.
For future reference, when making a back-up with an application or program like Acronis, one needs only to stop CIMPLICITY (yes; stop CIMPLICITY (or PROFICY Machine Edition if that's what the GE HMI is using)), and for a Mark* V or Mark* VI one needs to stop TCI. After waiting a couple of minutes, then one can run the imaging application. Most work well with an external USB hard drive, though it's a little slower (especially if the HMI CPU only has USB 2.0 ports; it runs much faster (though not THAT much faster with a USB 3.0 port on the HMI CPU (and the external hard drive must also be capable of USB 3.0). And that's it--nothing else should be required. After the imaging app/program is finished, just re-start TCI and after a couple of minutes if the CIMPLICITY project doesn't automatically re-start, re-start the CIMPLICITY project which should launch the CIMPLITITY overview displays.
So, what's not clear is: Did you re-install the original hard drive, or did you re-install a newly made hard drive using the image created by Acronis? If you didn't re-install the original hard drive, can you?
I believe TIMESET.DAT is created when TIMESET.BAT is run. BUT, make a back-up of the "working" TIMESET.DAT file just in case. I also believe that if you create a new TIMESET.DAT file you either have to stop and re-start NTP, or you have to re-start the HMI (I think it will work in either case--and by "work" I mean the new TIMESET.DAT file will get loaded into the HMI CPU RAM and accessed by NTP). There shouldn't be much else to do. (I believe one can open the MS-Windows Services control panel applet and search for the NTP service, and stop it, wait a couple of minutes, then re-start it--that's the way I have always used instead of re-booting the HMI--but re-booting the HMI clears out the HMI CPU RAM and reloads all of the relevant TCI files. Just remember to do an orderly shutdown of the HMI; don't just give it a three-fingered salute!)
TIMESET.DAT is going to be different for different versions of NTP and TCI--as well as for different time zones around the world.
What we now need to understand is: What color is the NTP clock face which should be visible in the System Status "tray" on the far right side of the MS-Windows Task Bar? Is it green? Is it white? Is it red? What happens when you double-click (left click) on the NTP icon? What happens when you right-click on the NTP icon?
It really would have helped to understand exactly what happened before this problem started earlier in the thread. And, people reading this thread (now and in the future) would be able to quickly understand what precipitated this problem, and learn from the process of trying to get it resolved.
Anyway, sorry if we can't solve this problem straight away and simply; but, when the OEM doesn't document processes and procedures very well (and this OEM didn't and still doesn't) it can be difficult.
I presume the snippet you posted from TIMESYNC.DAT is from the most recent TIMESYNC.DAT which is on the HMI CPU hard drive installed and running in the HMI CPU. You can see it says TIME_LOAD LOCAL. I wonder--have you tried setting the time on the HMI CPU--either from the MS-Windows date in the far right of the MS-Windows System Status bar, and if so, have you tried going to a command prompt and setting the date from the command line? (I think the utility is named DATE--all you have to do is type DATE and press ENTER to get a prompt to set the date.) I have seen when the HMI CPU date is grossly different from the master time signal this has caused problems. I'm just trying to think of all the problems I have seen (and there have been more than a few--and because programs and processes were changed by the OEM and weren't documented, there was always a learning curve that required a phone call or email to the factory, or a PAC case, to resolve. And, then the next time there was a problem, it was something different--and because there was no new process or procedure to refer to, it took another call or email or PAC case.
Lastly, what is the BIOS time in the HMI CPU???
For future reference, when making a back-up with an application or program like Acronis, one needs only to stop CIMPLICITY (yes; stop CIMPLICITY (or PROFICY Machine Edition if that's what the GE HMI is using)), and for a Mark* V or Mark* VI one needs to stop TCI. After waiting a couple of minutes, then one can run the imaging application. Most work well with an external USB hard drive, though it's a little slower (especially if the HMI CPU only has USB 2.0 ports; it runs much faster (though not THAT much faster with a USB 3.0 port on the HMI CPU (and the external hard drive must also be capable of USB 3.0). And that's it--nothing else should be required. After the imaging app/program is finished, just re-start TCI and after a couple of minutes if the CIMPLICITY project doesn't automatically re-start, re-start the CIMPLICITY project which should launch the CIMPLITITY overview displays.
So, what's not clear is: Did you re-install the original hard drive, or did you re-install a newly made hard drive using the image created by Acronis? If you didn't re-install the original hard drive, can you?
I believe TIMESET.DAT is created when TIMESET.BAT is run. BUT, make a back-up of the "working" TIMESET.DAT file just in case. I also believe that if you create a new TIMESET.DAT file you either have to stop and re-start NTP, or you have to re-start the HMI (I think it will work in either case--and by "work" I mean the new TIMESET.DAT file will get loaded into the HMI CPU RAM and accessed by NTP). There shouldn't be much else to do. (I believe one can open the MS-Windows Services control panel applet and search for the NTP service, and stop it, wait a couple of minutes, then re-start it--that's the way I have always used instead of re-booting the HMI--but re-booting the HMI clears out the HMI CPU RAM and reloads all of the relevant TCI files. Just remember to do an orderly shutdown of the HMI; don't just give it a three-fingered salute!)
TIMESET.DAT is going to be different for different versions of NTP and TCI--as well as for different time zones around the world.
What we now need to understand is: What color is the NTP clock face which should be visible in the System Status "tray" on the far right side of the MS-Windows Task Bar? Is it green? Is it white? Is it red? What happens when you double-click (left click) on the NTP icon? What happens when you right-click on the NTP icon?
It really would have helped to understand exactly what happened before this problem started earlier in the thread. And, people reading this thread (now and in the future) would be able to quickly understand what precipitated this problem, and learn from the process of trying to get it resolved.
Anyway, sorry if we can't solve this problem straight away and simply; but, when the OEM doesn't document processes and procedures very well (and this OEM didn't and still doesn't) it can be difficult.
I presume the snippet you posted from TIMESYNC.DAT is from the most recent TIMESYNC.DAT which is on the HMI CPU hard drive installed and running in the HMI CPU. You can see it says TIME_LOAD LOCAL. I wonder--have you tried setting the time on the HMI CPU--either from the MS-Windows date in the far right of the MS-Windows System Status bar, and if so, have you tried going to a command prompt and setting the date from the command line? (I think the utility is named DATE--all you have to do is type DATE and press ENTER to get a prompt to set the date.) I have seen when the HMI CPU date is grossly different from the master time signal this has caused problems. I'm just trying to think of all the problems I have seen (and there have been more than a few--and because programs and processes were changed by the OEM and weren't documented, there was always a learning curve that required a phone call or email to the factory, or a PAC case, to resolve. And, then the next time there was a problem, it was something different--and because there was no new process or procedure to refer to, it took another call or email or PAC case.
Lastly, what is the BIOS time in the HMI CPU???
1601 solved. Attached are screenshots of HMI VIEWER that collects it's data from 6 different projects on 6 different HMI SERVERS. When the HMI SERVER that provides time was asked to reboot; the project began to shutdown processes and the result was 1601. I cannot reproduced this effect on an HMI SERVER.
