Configuring Unused Servo output Loop #6 for IGV.

S

Thread Starter

Saber

We are using MarkV in frame 6b GE machine. IGV LVDTs are connected in 17, 18 and 19, 20 terminals respectively in TBQC terminal board. We found 19, 20 terminal showing abnormal value that means CSGV_B = 7.9 when we connect any LVDT in those terminals. But the other terminals work fine and shows CSGV=34 deg.

Then we wanted to change the terminal position 21, 22 for LVDT 1 and 23,24 for LVDT 2 to configure servo output 6 for IGV. We did as follows:

1. We configured CSGV from Q_R_POS09 to Q_R_POS11 and CSGV_B from Q_R_POS10 to Q_R_POS12 and CAGV from Q_Q_SV05 to Q_Q_SV06, CSRGVOUT from Q_Q_SV05 to Q_Q_SV06 in IO.ASG.

2. Then we modified ACALIB.DAT file by making same all fields of servo output 06 from servo output 05 (assigned for IGV).

3. At IO_CFG we modified TCQA card definition and for servo output no. 05 we put Function type and sub-type: 00 and for servo output no. 06 we put 43. Then we put all other values in servo 06 following servo no. 05.

4. Then we downloaded IO_CFG in <R>, <S>, <T> processors and rebooted one by one.

5. After this modification autocalibration and manual calibration works fine.

But the problem is:
1. INLET GUIDE VANE CONTROL TROUBLE ALARM
2. INLET GUIDE POSITION SERVO TROUBLE ALARM
this two alarms are still there even we do master reset.

Then we tried to find the cause of these two alarms: in rung no. SEQ_TRB2 101 we found CSRGVOUT=0 and CSR17CMP=34 at normal condition.

Is there any mistake during the software modification? For this modification do we need to download USER to r, s and t?
 
Can any one please help me regarding to the above threat?

Now We are running the GT with one LVDT of IGV. Is it possible to configure unused servo output no 6 for IGV?
 
Yes; it's possible. It seems you didn't run MK5MAKE.BAT to compile the changes you made to IO.ASG, then download USER to all processors (including <C>) and reboot them all one at a time. And, you will also need to calibrate the IGV LVDTs to complete the process.
 
Thank you very much for your reply.

I compiled the new program by MK5MAKE. If I download USER to all processors with new program <T> core shows error message and A7 state never comes to <T> core while rebooting. That's why I downloaded only IOCFG to r, s and t processors. Then I calibrated IGV in servo no 06, it works fine and shows calibration finished message and physical movement of IGV is excellent. After a while during startup of that unit we noticed the following two alarms persisting:

1. INLET GUIDE VANE CONTROL TROUBLE ALARM
2. INLET GUIDE VANE POSITION SERVO TROUBLE

When I checked rung then I found in (CSRGVV3)the value of CSRGV=34 and CSRGVOUT=0. Who it is possible? During the modification I did not download to <C> (my mistake)and is this the cause of getting wrong value of CSRGVOUT?

Now the machine is running with one LVDT and with old program. Can I try one more time downloading the new program IOCFG to r, s, t including c during next shutdown?

When I download old USER program to <T>, it doesn't show any error message during rebooting.
 
First, I would suggest that if the one LVDT input isn't working that you replace the terminal board where all the LVDT feedback signals are connected (I forget the name of that board at this time and I don't have access to any Mark V documentation at this time). Because, that card "fans out" the LVDT signals to all three processors via ribbon cables. So, if one input point is not working to all three processors, the thing that's common to all three processor is that input card.

Second, I'm surprised that you were able to execute AutoCalibrate successfully with <T> not reaching A7.... Something just doesn't compute here....

Third, you have provided new information that should have been included in the original post. When something like one processor failing to reach A7 occurs it's usually because there was some kind of problem during the downloading process. Like trying to download to a processor while another one is being rebooted (one should download to all three processors, then reboot them <b>one</b> at a time, waiting for a minute or two after the processor being rebooted reaches A7 before rebooting the next processor).

Or, there is some problem reported during the download on the screen that is not noticed by the person performing the download.

Or there is some pre-existing Diagnostic Alarm that complicates matters.

Or, someone is not rebooting by removing the power to the processor via the <PD> core, and is using the RESET button on the DCC/SDCC card. (When one is changing I/O Configuration, particularly, it's best not to use the RESET button to reboot the processor. So, it's always best to do a "hard" reboot by cycling power, leaving the power off for at least 15-30 seconds before reapplying it.)

Essentially the files downloaded to all three processors are identical, so there should be no differences in individual processors. The exception to this (and in GE there are always exceptions) is if someone has uploaded files to processor-specific files the EEPROM Downloader will find those files and download them rather than the generic files.

For example, let's say someone uploaded the I/O Configuration from <T>, and during the upload was prompted to save to a processor-specific file (IOCFG_T.DAT for an <I>, or IOCFG_T.AP1 for a GE Mark V HMI) or a generic file (IOCFG_Q.DAT for an <I>, or IOCFG_Q.AP1 for a GE Mark V HMI) and selected the processor-specific file. Then, every time the EEPROM Downloader was used to download I/O Configuration to <T> it would always use IOCFG_T.DAT (or .AP1) instead of IOCFG_Q.DAT (or .AP1). Now, if a change was made to I/O Configuration using the I/O Configurator, it <b>ONLY</b> saves to generic files (IOCFG_Q.DAT/.AP1), and so the change would never get downloaded to <T> because of the existence of the IOCFG_T.DAT/.AP1 file.

This is a little-known "feature" of the Mark V that has caused many problems over the years. If someone uploads files to processor-specific files, the EEPROM Downloader will always find the processor-specific files and use them instead of the generic files created by the I/O Configurator, the CSP Compiler, and the Table Compiler (the latter two are are executed by MK5MAKE.BAT).

There have been other threads on control.com describing how to use the LCC/SLCC display and keypad to troubleshoot a failure to reach A7. All cards associated with a processor must reach A6 and then all the cards--and the processors--will go to A7 (which is the state where the outputs are enabled). It would be helpful to know which card was not reaching A6.

Since all communications with <R>, <S>, and <T> go through <C> it's best when having made changes to any of the .ASG files (and you would have had to change the I/O Assignments in IO.ASG) to also download to <C> even if you didn't change anything associated with <C>. Things seem to be "reported" through <C> better that way.

Unfortunately, not being able to see the CSP for your site and see all of the Diagnostic Alarms and understand exactly what was done and what the state of the UNIT1 directory is (if there are any processor-specific download files, for example) it's not possible to say with any certainty what went wrong at your site. We've already learned that the process reported in the original post wasn't complete. When you post an issue it's most helpful if you take the time to report all steps and the results of all steps even if it doesn't seem relevant to you at the time. Because there is no GE documentation for most of these procedures, it can be very difficult to troubleshoot without understanding exactly what was done.

From what we've learned in your two posts, it would seem you've done everything that was necessary. But, again, it's taken two posts to find out this much.

And, this is a lot of trouble to go through to avoid replacing the input terminal board which the LVDT feedback signals are connected to. (It's presumed the site doesn't have a spare board.)
 
G.Rajesh,

If you like a post, just click on the "thumbs-up" icon.

If you don't like a post, click on the "thumbs-down" icon.
 
Top