Progress update on my FTS4040 repairs - this CS clock is now just playing with me!
So after rebuilding the PCB and replacing the SRAM I have for the first time a initialization LED

and after say 10 minute's the unit goes to lock) for a couple of seconds then Major fault

Communication with the Monitor3 is very hit and miss as on each powerup or Reset the Baud rate is different - I've even seen a instance when the RX / TX Baud rate differed, and the Clock select pins to the HD-4702 is constantly changing during TX / RX (or this could have been happenstance - but for sure they where alternating at a constant cyclic rate).
The EEPROM is also starting to full with what appears as nonsensical data - I'm presuming some memory field is related to the serial Baud rate - is it possible to have different Baud rate for TX / RX modes?
When the unit briefly locked, I noticed a large frequency error in the 10's of Hz... which then had me doubted my GPS locked lab standard. I opened Lady Heather and YES my GPSDO was indicating PLL unlocked (plenty of active satellites) - sure enough the VCXO DAC was at 97% meaning the Samsung STP2945 LF OCXO in the GPSDO had drifted too far off frequency for the GPSDO to compensate... I did a quick search and others had reported the same issue with this OCXO. There is no accessible trimmer to re-center the OCXO frequency - so the OCXO is dead. I'll have to order a replacement from eBay.
I'm lucky that I had Leo Bodnar's Mini Precision GPS Reference Clock on hand to use as a temporary replacement - these are great little units and "just work", Highly recommended as a "simple and affordable" GPSDO.
So - one dead OCXO... I don't know why, but I then removed the Datum 1111B (HP 10811 "type" OCXO) from the FTS4040 and decided to test it on the bench.
On first power up with 24Vdc the OCXO heated with 520mA current that quickly dropped to 28mA - but 10's of Hz negative Frequency offset - and each time I powered the OCXO from cold the time required for initial heating appeared to be getting shorter and shorter.
I could find no information on the Datum 1111B - so having nothing to work with and no clue, I opened the Oscillator and started from basics...
The HP 10811 should heat at a current limited 500mA which then drops to around 120mA when reaching operating temp - however the 1111B is a different design so I was not sure how relevant this is.
SC cut crystals are very temperature sensitive and have turn-over point around 85Deg - my 1111B was internally marked with as 82.1Deg. For sure my "oven" was nowhere near 82 DegC and even with a negative 10V on the VC pin I could not pull the Frequency to 10MHz... (the 5045 servo controller can pull the OCXO VC pin about +/- 4500mV).
Having little to work with, I started by removing the Semi-conductors and Tantalum Capacitors to measure them out of circuit - when I noticed this:-

As I was desoldering the Tant Cap. (C11) I noticed that the Positive band was connected to the Ground plane!! hold on there's no negative supply in the 1111B? Looking closer to the silkscreen markings and YES the Tantalum had been fitted in the wrong orientation from the factory

I quickly traced out the circuit and sure enough the Tant Cap. formed an RC filter on the Gate of MOSFET in line with one arm of the Temperature compensation Bridge.. I'm guessing as part of the current limiting circuit.
I replaced the Tant cap - reassembled the unit and and on testing I measured 520mA on power up - which then after a few minutes reduced to about 110mA just as the frequency was nearing -0.5Hz offset. I trimmed the OCXO to 10MHz with -410mV on the VC pin, and the oscillator was nice and stable

So in one day I've had 2 bad OCXO's - Surely I'm being Trolled by OCXO's here!!
So does the unit work now? -
Off Course Not!!! - with no apparently difference - looses lock after 1-2 seconds after coming out if Initialization (and with a large frequency offset)...
However, I now believe that the original problem (where the unit would randomly start to loose lock) was the failing OCXO - and not the PSU. Sure the capacitor's in the PSU where in a bad way, and sure the unit has been subsequently further damaged due to the failed PSU repair - but I now believe that the OCXO was the initial culprit.
I'm at a bit of a loss ATM - I'll give it a break for awhile to gather some thoughts and ponder my life choices - I also need to get to the root cause of the misbehaving MCU section.