Member Login
Search
Past & Future Posts
Sponsored Communities
Neat Stuff

Visit our shop for nerds in control lifestyle products.
Cool stuff
Thermal Overload
The threads that wouldn't die...
- PC reliability?
- Windows, real time
- PID loops
- PCs vs. PLCs
- Replacing people
- MS 'monopoly'?
- Software quality
- Where do we go from here?
- Why pay?
- PC reliability?
- Windows, real time
- PID loops
- PCs vs. PLCs
- Replacing people
- MS 'monopoly'?
- Software quality
- Where do we go from here?
- Why pay?
Fortune
Internet outage
RSS Feed
www.control.com/rss
from the Power-Utility-Indian Oil department...
Facing problem with Mark-ivHi There
We here at digboi refinery(Assam-india) have 3 mark-iv installations for our three 8.5 mw gts.
Recently one problem came. All the FSR related tags, logic on s-processor were reported voting mismatch. This phenomena happened suddenly and stayed for 2/3 mins. Then always the s-processor started following the other two processors(R,T),
One day peculiarly all FSR related constants in s-processor went down to the lowest and other logic even like L-4 went down.
I rebooted the s-processor online. But the process persisted. Can anybody help me trouble shooting the problem.
We here at digboi refinery(Assam-india) have 3 mark-iv installations for our three 8.5 mw gts.
Recently one problem came. All the FSR related tags, logic on s-processor were reported voting mismatch. This phenomena happened suddenly and stayed for 2/3 mins. Then always the s-processor started following the other two processors(R,T),
One day peculiarly all FSR related constants in s-processor went down to the lowest and other logic even like L-4 went down.
I rebooted the s-processor online. But the process persisted. Can anybody help me trouble shooting the problem.
Being out of touch with Mark IV for more than 15 years, I can't memorize the fine details.
If your system is Mark IV (not Mark IV Plus), it will have batterry backed RAM (called BRAM). It could be a BRAM problem. Otherwise replace the processor board.
On the later model with EEPROMs, looks like a problem with the processor board - HMPJ
Another possible area is the communication board HCMC.
If your system is Mark IV (not Mark IV Plus), it will have batterry backed RAM (called BRAM). It could be a BRAM problem. Otherwise replace the processor board.
On the later model with EEPROMs, looks like a problem with the processor board - HMPJ
Another possible area is the communication board HCMC.
You need to use a combination of the Mark IV Speedtronic Elementary, the Diagnostic Alarm Display (the oldest alarm is at the bottom of the list, meaning the beginning of the event will be at the bottom of the list of alarms), and the Logic Forcing Display to see the values of the different signals in the three processors. If L4S is dropping out, then you need to start working backwards from L4T to see what is tripping L4.
Another useful tool is the Auxiliary Display (though most sites have not kept all the display digits working properly). You can look in the Maintenance Manual and/or the Users Manual for instructions on how to use the Aux. Display to see the Process Alarm queue in each processor (remember: two of the three processors must agree that a particular process alarm must exist for it to be annunciated on the <OPM> and logged to the printer; so by using the Aux. Display to see the Process Alarm queue in <S>, you can see which trip condition that only <S> believes has occurred--but it should also be listed in the Voting Mismatch Diag. Alarms).
The information's there; you just need to use the tools to find it.
Another useful tool is the Auxiliary Display (though most sites have not kept all the display digits working properly). You can look in the Maintenance Manual and/or the Users Manual for instructions on how to use the Aux. Display to see the Process Alarm queue in each processor (remember: two of the three processors must agree that a particular process alarm must exist for it to be annunciated on the <OPM> and logged to the printer; so by using the Aux. Display to see the Process Alarm queue in <S>, you can see which trip condition that only <S> believes has occurred--but it should also be listed in the Voting Mismatch Diag. Alarms).
The information's there; you just need to use the tools to find it.
From Control Engineering magazine...
Related articles from Control Engineering magazine- Integrating PLM, ERP, MES behind the scenes
- Enterprise data historian supports management of power distribution
- Digital factory interface: XML control logic standard accepted by AutomationML
- Colfax Corp. acquires Fairmount Automation
- Oil & gas industry controller benefits from embedded database
- Wonderware names InSource “Wonderware Southeast” partner
- Researcher wins grant for holographic instrument panel controls
- Rittal launches Ri4Power power management system
Above articles copyright 2008 Reed Business Information. Subject to its Terms of Use.
Your use of this site is subject to the terms and conditions set forth under Legal Notices and the Privacy Policy. Please read those terms and conditions carefully. Subject to the rights expressly reserved to others under Legal Notices, the content of this site and the compilation thereof is © 1999-2008 Control Technology Corporation. All rights reserved.
Users of this site are benefiting from open source technologies, including PHP, PostgreSQL and Apache. Be happy.
Our Advertisers
Help keep our servers running...
Patronize our advertisers!
Patronize our advertisers!



