can i cancel some inputs which causes diagnostic alarm and use the spare inputs in DTBA or DTBB? there found false alarm 86DM10 because controler R&S gives false logic and T is true.

I check DTBB okay (controller T only change its logic when i make DM10 off position).

How to cancel these input in DTBB and use spare input?

 

The Mark V Maintenance Manual, GEH-5980, has a section on assigning spare I/O points. It's not difficult, <b>BUT</b> the real problem comes in if the operator interface is a GE Mark V HMI (with MS-Windows and CIMPLICITY), especially if there are multiple units and HMIs on the StageLink.

I/O assignments are made in IO.ASG in the F:\UNITn directory (where 'n' is the unit number). You should be able to use the Maint. Manual descriptions and an examination of IO.ASG to figure out what to do to move the wiring to an unused, "spare", input, compile the changes, do the downloads/reboots.

However, if the unit uses GE Mark V HMIs, you're on your own after that. Be aware that if the process (which isn't documented anywhere for the any of the various versions of TCI/CIMPLICITY) isn't followed exactly (kind of hard to do if it's not documented properly, right?!?!?) you can end up with a useless HMI.

The moral of this story is: If you're going to attempt this (with an <I> or a GE Mark V HMI), <b>MAKE BACKUPS FIRST!</b>

By the way, I've never seen a DM610 alarm message. (And I've seen a LOT of Diagnostic Alarms.)

 

We have one unit controlled by two computers and the IDOS— Computer operating system. I found the I/O chapter IN GEH-6195. I like to know (step by step) how i cancel (software) any input in DTBA
thanks for your help

 

You're not 'canceling' any inputs. You will be relocating (moving) them to unused inputs.

For example, say you L33CB1O is assigned to:

Q_QD1_CI12 L33CB1O CIM ;xxxx....xxxx

and you have a spare input at:

Q_QD1_CI22 Q_QD1_CI22 CIM ;xxxx....xxxx

(When the name in the second column matches the name in the first column, the point is a "spare" unused point.)

You would make the following changes:

Q_QD1_CI12 Q_QD1_CI12 CIM ;xxxx....xxxx
.
.
.
Q_QD1_CI22 L33CB10 CIM ;xxxx....xxxx

You have now moved (relocated) the 33CB-1 input assignment from CI12 to CI22, and you will need to move the wire from DTBA-23 to DTBA-43.

You next need to check in the I/O Configurator to see if the input you are relocating is inverted. If it is inverted at it's current location, you need to make sure the new location is inverted, 'Verify' the screen, save the changes and exit the I/O Configurator.

You would then follow the remaining steps of running MK5MAKE.BAT, choosing to compile the CSP when prompted, then downloading the USER partition to the Mark V processors (<R>, <S>, <T> for a TMR panel), then rebooting the processors one at a time, waiting approximately two minutes after the processor which was just re-booted reaches A7 status before re-booting the next processor.

Finally, you will need to re-start the <I> to get the new UNITDATA.DAT loaded into RAM. At this point, you need to test your new input assignment to see that it works (after you have re-booted the <I>).

So, you're not canceling anything, you're just moving or relocating an input from its current assignment to a spare location, making the current assignment a spare location in the process.

Anything after the semi-colon ( ; ) is a comment and is ignored by the compiler. It would probably be helpful to you or the next person if you identified the bad location with some comment to that effect.

Because you have two <I>s, hopefully you use only one <I> for downloads. You should make the changes on that <I>, download from that <I>, and then re-boot that <I>.

Once you're done, you need to copy the contents of the unit-specific directory from that <I> to the other <I>, then re-boot the second <I>. That way both <I>s will have the same information in case the first <I> has problems in the future.

Actually, since you are only changing IO.ASG on the first <I>, you could just copy that file to the second <I>, then run MK5MAKE.BAT on the second <I>, then re-start the second <I>. (You don't need to download from the second <I>; you just need to get the same I/O Assignment file incorporated into UNITDATA.DAT, and then load the new UNITDATA.DAT into RAM by re-booting the <I>.)

If the site has been using both <I>s for downloading by hasn't been copying files between the two <I>s properly, the whole thing can be quite dodgey and a little bit risky. If the site hasn't designated one <I> to be the 'engineering workstation' then there's no time like the present to take the opportunity to do so, and then don't fail to copy any changes to the second <I> when downloads are done from the designated engineering workstation, and re-boot the second <I> to get the changes loaded in <I> RAM.

It's very difficult to describe, this business of keeping two or more Mark V operator interfaces "equal", but it's absolutely critical for disaster recovery purposes, in the event of a failure of either <I>. And if you're still using <I>s, you need to be prepared for a failure of some sort if you're not doing proper maintenance on the CPUs (cleaning; disk defragmentation; etc.).

Don't forget to write and let us know how you fared--and don't forget to make back-ups before trying this just in case you need them if it doesn't work out.

 

I would like to thank you very much and I will write you what is happening to me in the reply may be late because of circumstances at work

 

My manager refused to make the amendment to it so we replaced the two cards (tcda ) with new. Your solution is very useful to me and I will use in the future .

 

Thanks very much for the feedback!