Work Day 7th October 2017

The focus has been on getting the LCP fully serviceable again so no other topics to report on until now.  I am delighted to be able to say that serviceability has indeed been achieved; the investigation has revealed that we had, at least, two faults:

Fault 1
The ‘Mode Change Not Allowed’ fault was due to a faulty GX processor for whatever reason it was not reading PeriBus replies from just the Digital Input box. We shall have to research this to help identify what could be wrong with the GX.

Fault 2
The ME186 PeriBus converter was preventing the initialising of the software which was  preventing the Bloodhound banner from displaying. This fault occurred last Saturday and was additional to Fault 1.

Resolution of the problems has been delayed, in part, due to the unknown condition of spares, especially GX processors. Serviceable GX and ME186 are now installed with known good spare GX in the LCP. Back in the workshop we tested it by installing and running the simulator.

We established early on that no inputs were being read from the Digital Input box and Stuart’s software analysis showed us what should happen and the messages that should be displayed depending on the Mode and Roll switches on the console, but whatever we did it was always the same message that was stopping the simulator booting – ‘Missiles not at Reload’ indicating the A and B Reload/Available switches where in the wrong ‘Available’ position which they were not. All other aspects and indications of the boot sequence were correct, displays, flashing lamps etc. but nothing happened when pressing the Simulator button.

Initial indications pointed to a problem with the Digital Input box or a switch, an obvious place to start. Could it be a faulty input card ‘locking’ data bits, could it be a faulty Serial to Parallel converter? Fortunately we have a spare Digital input box so I built a test rig consisting of my PeriBus simulator, a Digital Input box and switchable inputs to Slot 14, all cards were rotated through Slot 14 for testing. Slot 14 was used as it was the only card position that used a single input socket (OA8) and the slot also used the lower voltage (3V) bias. I had an original OA8 wired socket, carefully salvaged by Mike with all other wiring and connectors from a derelict LCP at Luffenham. It was simply a case of adapting it to connect to a +5V supply to simulate switched inputs. With this rig I could test all input cards, Termination Buffers and Serial to Parallel Converters. Several faults were found including a Serial to Parallel converter with a U/S 74S04 [amazing how many of this gate device has been a problem! – Ed] setting two data bits permanently, an input card with a U/S LM337 giving a bias of 11 v instead of 6v and an open circuit leg on a plug in DIL component (Ferranti PAL) due to oxidisation. All good stuff and an expectation that the fault would be cleared, but it wasn’t.

It was appreciated from the beginning that there could be a PeriBus problem and other fault finding measures including swapping out the ME186 PeriBus converter on the A700, as well as all other cards except the GX. The reason being that the spare GX in the LCP was definitely U/S. I originally considered the GX to be the likely problem as it was handling all other routines for starting the simulator software. Surely if there was a problem with the PeriBus it would affect everything that is connected to it. The Serial PeriBus cable and termination were also replaced.

On Saturday Sept 30th, Pete M and I tested the Digital input box in-situ with the PeriBus test set and all looked to be OK and working normally. Attention then reverted back to the A700 and the GX as it was the only item not swapped out. Removing and reinserting the GX caused another problem (fault), the boot message on the FT81 only displayed the three initial lines then everything stopped, the boot sequence was not completing to the stage it was with the ‘Missiles not at Reload’ message. Priority was now to get a serviceable (spare) GX.  I am able to test GX processors to a point where the software can be booted but it does not proceed past the first line of the boot message, normal for a standalone A700 which is what I have at back in the workshop [used to be called home for Pete H! – Ed]. On Saturday I arrived at the LCP with two spare GX’s. Both GX’s then gave the same fault of the first three lines of the boot message on the FT81 – both GX’s could not have the same fault. Swapping cards revealed it was the ME186, PeriBus Converter, causing the three line boot fault. We now had two faults, the ME186 obviously going U/S on Sept 30th.

Once the ME186 was exchanged and a working ‘spare’ GX was fitted in the A700 the simulator booted correctly and ran as expected, fault fixed. I then spent an hour breaking the rule of, ‘if it’s working don’t touch it’, swapping back in the original faulty GX and ME186 to prove the fault conditions which confirmed the original GX was the cause of the permanent ‘Missiles not at Reload’ status message and the ME186 was the cause of the halted boot after three lines, this elimination task was needed to prove that we had two separate faults and this it wasn’t the ME186 causing both all along.

Moral of this saga, always ensure we maintain a set of known good spares in the LCP. What follows on from this fault is our ability to repair faulty cards. I have started on the Digital Input box and look to extend this testing capability to all I/O boxes and their cards. The challenge is to test and repair A700 cards, i.e. no extender cards exist for a start; then there is the fact that we do not have any test specifications.

As Dave has already suggested, a fault log is required and steps are in hand to set one up to be kept in the LCP.

To help understand which processor handles which task our software guru has been studying the Argus 700 source code [Coral 66 – Ed] which is from another military customer’s archives but close enough to the RAF’s and came up with this list of definitions in the BHMACRO file which shows which processors in which tasks are run. SYSSUP, which does all the MODE and ROLE button input reading, would seem to be running in GL2:

+ Task numbers for BH2 programs. Bracket comments
+ show the processors that run each of the programs.
‘C’ Task number £42 is spare ;
‘C’ Task numbers £60 to £63 are spare ;

This indicates that not all tasks are fixed to a processor but this begs the question, how are non-fixed tasks managed;  assigned dynamically or shared perhaps?
We initially assumed (mistakenly) that the GX was OK because the system correctly read the console keyboards. The keyboards are read by the BHTEST.BH2 task, which it seems is not fixed to a processor. Note also that CHARGE displays were not affected because FDCP is fixed to GL2.
If the above makes sense to you it might mean you are an expert with Coral66; please make yourself known if you are.

Big hooray; we ran the simulator again today for a visitor and it remains ‘S’

UK P Display Tgt Data - Num Errors.JPG

One thought on “Work Day 7th October 2017”

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.