Are you sure there aren’t even dynamic sensors that come 12” before the top floor slowdown? TPDL and TPDR. And a WJR command should tell you what has caused the resync attempts.

Yes, I am sure, Three different techs have confirmed it. On the prints for this job page 19 is labeled Telescoping Jack Sensors and the only thing on the page is the BLO Input and output

We did a WJR and it gives us a list of the dates and times it was resynched along with I assuming the inches of travel. Those are a lot different. They range from 3.19in to 6.5 in

Run the elevator to the top floor and look from the lower floor (if its 2 foors, or middle floor if its 3) and watch the upper and lower pistons on both sides. You might have a bad lower seal casing the elevator to drift. OR possibly the pistons arent bottoming out when on the springs. Remove the springs and either lay in the pit or set a camra up to see if the car stops on the stand. for some reason the pistons need a little more weight to fully resync and might need to shorten the buffer stands.

What happens if you preform a CPU resync? Does it do everything properly?

What doesn’t make sense though is how do you get a 1068 without any jack sensors to tell the controller it’s out of sync? Even if the jacks were so far out that the car was getting stuck in the hoistway or one jack was topped out before the top floor, the controller would have no way to know the jacks are the problem. You’d just get a stall up, stall down or MLT kind of fault. This depends on software version but when you do the WJR does it say the reason for each resync? They should either be “timed” from the JRT setting typically every night, “motor” from the start counter re-sync setting, “dynamic” meaning it saw the dynamic sensors too far out, or “static” meaning it saw the static sensors too far out. The 1068 should only happen after trying several “static” or “dynamic” resyncs without seeing the sensors match.

Agreed, we do not know why it will go down on the 1068 with no sensors. The jacks are in together the whole way through. It will go months with no issues, then for a week or two give us the 1068 faults. I have attached the screen shot of WJR

That’s what I would expect it to look like with no sensors. Can’t explain the 1068 faults. What generic software is in the controller and when you do an FLTN where is the car when the 1068 is logged?

The sensors may be jumped. And I’ve seen the inputs disappear .. with a brown out code usually. I think 1069. Then after a reload they reappeared 🤷‍♂️ Any wires on TPSR and TPSL on the terminal strip in controller

1068 only comes in with a “view” of the pistons not being synced. Does your I/O show sensor inputs? If it does delete them, think they would be on port 9 bits 1-2 for Dynamics. As Dirt asked could be an older software that would bring this about not liking the discrepancy of numbers for resync? Could try adding in another convenient resync time so it does it twice a day and keeps the numbers closer?

Have not looked at the sensor inputs....It has not gone down since last week. Will double check the software when we look at the inputs.

Update...Has not gone down again...we went by to perform the maintenance on it.

The software is V4R5D.

The inputs are there(TPDL,TPDR TP3SL,and TP3SR) TP3SL and TP3SR go high at leveling speed as it comes in to the top floor(2 stop car)...TPDL and TPDR come on as soon as a down direction starts and stays on until car stops at bottom floor, even during leveling.

There are no wires in the terminals for the sensors.

Will have to wait until we get the fault to find out what FLTN indicates.

So are there sensors in the hoistway then? There must be. And something is wired to the inputs if they’re changing state. What port are the IOs in? Look at the corresponding plug on the188e to see if there are wires there. The way they’re coming in isn’t right. The static sensors should be on at both floors and the dynamics should come on and go off 12” below the top floor slowdown. Start with fixing that.

There are no sensors or magnets on the jacks. When on inspection at any place in the shaft, in the down direction TPDL and TPDR come high, in the up direction TP3SR and SL come high. Does not matter where in the shaft the car is those come high depending on direction.

In IMS row 9, line 1 has TPDR, Line 2 has TPDL, line 3 has TP3SR and line 4 has TP3SL. How does that correlate with the cons on the 188 e board? Con 9 on the 188e board does not have any wires in it.

I think you need to reload. Port 9 should be your valve coils and from the what you’re describing, they are. 9-1 and 9-2 are VC1A and VC1B, down slow. 9-3 and 9-4 is VC2A and VC2B, up slow. Jack sensors are typically on port 7 on a TAC20. Ports 1-8 correspond directly to Con1-8 but 9 directly pick K relays. Now I’m pretty sure you are looking at the IO map of a TAC32. Their jack sensors are in port 9. I strongly suggest that you make new networks for every job. When you re-use the same network, inevitably someone forgets to reload the job and a ton of time is wasted looking at the last car you worked on’s IO map.

I have heard to make a new network before, but never realized why, as the fault codes came up for us. Now I see why. Thanks.