Tac 50- fault 106, 53, 981

So current state of the car: Was previously running fine, now it will not reach contract speed of 350. However If I change the contract speed in the parameters to 175 it will run to any floor with no issues. But if I place it back at 350 it Consistently everytime throws a 53 fault: safety string error open during run causing an emergency stop. After watching a few times it Seems that as soon as the speed reaches around 200 is when the fault happens... the decel rate is confirmed a proper speed at 120.. Also intermittently thows 981 fault. I have rescanned hoistway and back up scan as well. confirmed etsd, ecnt, edet, ncnt, and all the fixin's on vane in HW are not out of adjustment.. They all activate in IOs proper times at both Term landings.
all parameters and adjustments seem to be set properly... Taking a step back to how this all started; arrived onsite and very hungry to multiple 106 faults: DSP battery backup failure. Before replacing the battery and During troubleshooting, the car would ONLY INTERMITTENTLY stop during a high speed run as if opening a safety circuit but not throwing any faults. during this time it would also loose all communication with the IMS program. To me it was Basically indicating power loss to the dsp board or communication board...the 12v dsp battery only had 4volts, so replaced battery. Repowered iOs and CPU checked and verified proper output voltage on All 4 power supplys in cabinet. PS4 seemed a little bit finicky, could've been my meter leads, But ultimately in the it ended up holding the proper voltage consistently at 15v once the new battery was in it stop the communications loss to the IMs system but fault continued and still will not reach contract speed... ANY help or advice at all would be greatly appreciated.... also to answer the question, no I have not adjusted or changed anything in the oscilloscope in reference to acceleration or deceleration and I would appreciate it if i could keep it that way. Thanks in advance

Team effort hear we need help

Have you verified your feed back signal with a meter or oscilloscope? It’s best to use a oscilloscope. Have you checked for any noise on the lines for the encoder?

JKH

If you jump out contacts on voltage monitor does issue persist? I think the orange ones are problematic, you could possibly rap on the side of it with screwdriver handle to recreate issue.

Verifying all DC controller voltages is important on these units. 5 vdc, 15 vdc, and , 24 vdc. Also occasionally pulling all cards and cleaning up edge connectors with scotch brite or pink pearl eraser.

I only mention this because possibly those faults are a symptom of another issue

Might check power supplies for ac ripple have had a lot of issues caused by bad power supplies also might take a look at your traveling cable I think there is a fuse on the sap as well

Sap? Checked and confirmed dsp board fusses

Its a 908 fault I believe causing the 53 fault.
We have done h.w. Scan and backup scan.
Ran new wires across m.r. Floor with grounded shielded pair
To encoder board.
Done basically all the rest of what the 908 fault describes
I am looking for the pmi output modules what board are they on.

Also cannot find dz0 or dz1 fast adjustments in the tool anywere I know im just missing something.

Ok, 908 makes more sense, more like I was thinking anyway. Do you have reduced stroke buffers with physical switches in the hoistway in addition to vanes? They would occupy the first like 8 I/Os ETU1, ETD1, ETU2, ETD2, etc. if you do, make sure all are high when the car is in the middle of the hoistway.

Or
You may have some bad data in the DSP for ETS tables. Put car in the middle of the hoistway on inspect. In this order, cycle CPU power, NTSI, ETSI, TBSS, Y, ETSS, Y, cycle CPU power again, NTSI, ETSI, TBSS, Y, ETSS, Y, cycle CPU power again, take car to bottom on inspect, put on auto, do a backup scan.

If that doesn’t work, check the snubbers on NCNT, NDET, ECNT, EDET inputs. If you position encoder is the optical wheel in gov, check alignment and clean wheel.

And it was said above but is worth saying again, make sure there isn’t excessive AC from V+ to VC

Indirtwetrust
Will be onsite in am what do you mean by snubbers on inputs
And does anyone know were output modules or pmi output modules are on what board for the steps to fixing this fault.

Snubbers are suppressors. They’ll be wired from each input to VC on the controller terminal strip. The print tells you where the PMI module is. Inside the triangle there is an O for Output or an I for Input, then the I/O name, then x-n where x=the PMI card number and n=the module number on that card. It’s best to confirm with the PMI chart or IMS. In IMS you should be using 16 bit ports and there are 48 PMI modules on each card so the first 3 columns are PMI 1, 4-6 are PMI 2, 7-9 are PMI 3 etc. first column is PMIs 1-16, 2nd column is PMIs 17-32, 3rd column is PMIs 33-48. Hope that makes sense. There should also be a chart in the controller door.

Thank you so much that was very helpful to put the puzzle pieces together. I am sure now i will be much better informed and ready to help tcelevator2 fix this thing. We are gettin our butts kicked on this one. Thanks to everyone who has helped.
Will updae again after we try all this again in am.

Indirtwetrust I cannot thank you enough! just to reconfirm we did not have the first 8 iOS or reduced stroke buffers so we went ahead with the next step and confirmed we did seem to have bad data in the DSP for the ETS tables. because after the power cycles and commands and backup scan we are back up to contract speed of 350. Not sure how we initially corrupted the data files in the DSP but I will say we did measure a quick spike of 350mv AC between V+ to VC during a run.

I was thinking maybe someone ran a backup scan while the bad battery was pulling the voltage down to 4v.

Thats a good possibility