Today is...
Saturday, February 24, 2018
Welcome to, the global online
community of automation professionals.
Featured Video...
Featured Video
A demonstration of EtherCAT control of linear motors using the CTC EtherCAT master.
Our Advertisers
Help keep our servers running...
Patronize our advertisers!
Visit our Post Archive
77HT Diagnostic Alarm in Mark Vi
77HT diagnostic alarm in Mark Vi-Input signal pulse rate 1 voting mismatch. PPRO is also having diagnostic alarms.

We have frame V GT running on Mark VI e. It is recently upgraded to Mark vie from mark vi recently.

77HT diagonistic alarm in Mark Vi-Input signal pulse rate 1 voting mismatch Local=5124.417 voted =5124.110. PPRO is also having diagnostic alarms. On different days alarm appeared on <x><Y><Z><T> processors.

Beside the problem mentioned above, one more problem is noticeable. I am seeing FSR for speed and acceleration is continuously switching.

As per my analysis frequent diagnostic alarms in GT generated due to speed voting mismatch of 77HT-1, 2 & 3. The main root cause seems to be the frequent switch over between speed FSR (FSRN) and acceleration FSR (FSRACC) as minimum FSR which is causing continuous acceleration and deceleration of the machine.

Any other possible logical reasons for this event ? Please help me diagonise this problem.


If the unit uses six (6) speed pick-ups (one for each of <R>, <S>, & <T>, and <X>, <Y>, & <Z>) there is a problem with either the wiring/terminations of the speed pick-up connected to <X> or that speed pick-up is failing, or that speed pick-up's gap is incorrect.

If there are only three speed pick-ups (one jumpered to <R> & <X>, one to <S> & <Y>, one to <T> & <Z>) then the same problem exists for the speed pick-up connected to <T> & <Z>.

This not a Mark VIe problem, but a wiring/termination or speed pick-up or speed pick-up gap problem. Solve the problem with the wiring/termination or the speed pick-up or the speed pick-up gap and you will solve BOTH problems.

Please write back to let us know how you fare in resolving the problem!

Thank you CSA for prompt response. Now my biggest problem is that GT is running so I can't check wires or gap settings. As I am under immense pressure to clear this diagnostic I thought of changing the deviation value from 5% to 10%. Is it a good idea? We have 6 probes to measure speed. How is it possible that 4 out of 6 are malfunctioning? I am so confused.


There are just some things for which the unit must be shut down to troubleshoot. Speed pick-ups are critical inputs....

I absolutely DO NOT recommend changing the deviation value. If the alarm is "bothering" the operators, then tell them to Lock the alarm until such time as the unit can be shut down and the problem can be troubleshot.

The wiring connections can DEFINITELY be checked while the unit is running. Just open the junction boxes and check the screws/terminal lugs for tightness.

If four probes were malfunctioning, the unit would NOT be running.

If there are six probes for the six required speed pick-up input channels of the Mark VIe, then per the information provided in the original post it's most likely the probe connected to the <Z> PPRO input is intermittent, or there is a wiring problem (loose termination; incorrectly terminated cable shield drain wire), or the pick-up gap is incorrect or the pick-up is not secured to the mount. It's not likely the problem is the Mark VIe (unless there were commissioning issues we have not been told about). It is possible to change the PPRO I/O Pack while the unit is running but unless there are other related/relevant Diagnostic Alarms for that Pack it's probably not likely the Pack is the problem.

You should be able to look in the Application Code and see what's happening. Usually, <Q> checks its speed pick-up inputs against <W>, and vice versa, and alarms when there's an issue. If the unit is going in and out of Acceleration Control and Speed Control, then how stable is the grid frequency the unit is synchronized to??? Every time I've seen this problem it was caused by an unstable grid, not a control system issue--or even a speed sensor issue.

Have you used Trend Recorder to diagnose the issue(s)? It's very helpful.

And, Locking alarms (both Diagnostic- and Process Alarms can be locked) is one way to placate the operators (and their management). That's what Locking alarms is for--to stop constant annunciation of nuisance alarms when the unit can't be shut down to troubleshoot and resolve the alarm properly. The key is to remember the alarm is Locked, and to resolve the alarm at the earliest possible opportunity and Unlock the alarm.

This is so typical; "It worked FINE before you put that Mark VIe in!" when in fact, the previous control system had issues, but people just ignored them. BUT, now that there's a new Mark VIe, everyone expects the problems to have been solved during the upgrade--and that rarely happens. AND, the speed pick-up inputs to the Mark VIe are MUCH more sensitive than even for the the Mark VI, or the Mark V, or the Mark IV. And, so even minor issues are magnified (because of the increased sensitivity). It's possibly (likely, even) that the speed pick-up was failing before, but the previous control system wasn't as sensitive and the problem wasn't known.

Again, the unit wouldn't be running if four speed pick-ups were failing or failed. Stop, and reason your way through this issue. Think logically. And don't let operators or their supervisors pressure you to do something you can't do. Do what you can, and let things run their course. If the unit trips because of this problem, then you will have an opportunity to fix the problem. And, if that happens, then it's a management decision that forced the problem to get so bad the unit tripped--not yours.

If this is a "reliability run" after commissioning for a recently installed Mark VIe, just chill. If it trips, it trips. If the Customer won't shut the unit down, that's for management (Customer and control system supplier/packager) to resolve--not yours. You make the recommendations, and the people who get paid to make the decisions (take the risks) decide what to do.

Hope this helps! It's tough to understand exactly what the problem is without actionable data (Trends; running data), but in this case there can't be too many possibilities. And, it takes what it takes to troubleshoot and resolve the issues. TMR doesn't mean EVERY problem can be troubleshot and resolved with the unit running. It just means that most problems can be dealt with without shutting the unit down--but not ALL problems. It means the TMR system will keep the unit running until such time as the unit can be shut down and the problems troubleshot and resolved, and it will keep the unit running when a lot of other SIMPLEX or even DUAL REDUNDANT control systems might trip result in a trip. TMR is not a perfect control system, but it's better than most. And every situation is different. If they can't shut the machine down, then they will have to live with the risk(s) of keeping it running until such time as it can be shut down to solve the problems. Just because it's a programmable control system and settings and parameters can be changed DOESN'T mean that settings and parameters should be changed to get through every problem. (Because, many times, the problems don't get solved and the consequences are worse because of the "temporary" changes; or, the "temporary" changes don't get returned to normal when the problem does get resolved.)