Tested a script while looking through the telescope. Script was set up to switch filters and take sequences of images.

Everything seems to be badly scrambled! Colours of filters do not match what is requested, and the sequences of images received are incorrect – for instance, when asking for 10 images at 2 seconds each I get about 3 images at 2 seconds and the rest are rushed through rapidly.

Shutter opens at strange times after a sequence.

It seems like the system is badly shaken up now. I think some of the above behaviour may explain some of the odd image-sequences we had at MLO, but the majority from MLO were good: now it all seems random.

My guess is that the LabView software has been jumbled somehow – it is easily done since the coding is not deterministic as text code is – it is all little coloured lines and boxes. It is easy to pick something up and drop it down in the wrong place. A test and a fix for this might be to restore an older version of the software – for instance something after Ingemar fixed the bad coding problems we found while at MLO and before the system was hit by lightning.

Another possibility is that hardware has been damaged in such a way as to scramble/ignore software instructions. Not sure how to test for this – we used a ‘sniffer cable’ to listen to the erroneous traffic to the mount, but I am not sure what to listen in on here?

Wonder if there is a way to ‘reset the hardware’? Perhaps the FW are ‘off by one’ – some latch is not clicking home?

—————

Inside the ‘breakout box’ there are lights to watch as a script runs. There is a light on a ‘hager’ relay and it evidently lights up when the two Thorlabs filter-wheel controllers are being adressed. They have displays that show numbers and I am guessing they show the position of the FW.

While running a sequence through the 5 filters I saw the numbers change. I think I caught a rythm corresponding to several passes through the 5 filters, but I swear there was an irregularity [hard to prove afterwards as there is lots of uncomfortable crouching and waiting to do]. Also strange is that the FW displays show two sets of numbers first, these then change to another set, then the hager light goes out and you can hear the shutter start working [its progress is uneven, however, despite being asked to take 10 identical images]. Here is a sequence:

FW2:5->5,6->1,2->3,4->2,3->4,
FW1:2->1,2->1,2->1,2->1,2->1,

where “A->B” means that the FW display first showed an A which then changed to a B, after 5 seconds or so. Notice how FW1 always goes “2->1”. FW2 seems to be cycling all numbers. Notice how the start position in one pair is always 1 higher than the end position in the previous set. There is a cryptic sentence deep inside Dave’s LabView code about how Thorlabs uses one set of indices and his code another – this could be it, I guess.

I think FW1 is the ND filter and is always set the same way – in the above test I was asking for the ‘AIR’ position and I think this is what we see. I will now run a test where I ask for one of the ND filters instead and we will see if the numbers change!

—————

OK, I did that, and it seems I am right. FW1 is the ND filter. I set it to ND2.0 and the sequence 2->1 above changed to 5->6.

Should run a sequence now of just changing the ND filters.

——————

Ok, did that too. This time I used a script that always set the ‘B’ filter, but cycled through the available ND grades – that is AIR, ND0.9, ND1.0, ND1.3, ND2.0. The typical sequence of readouts from the Thorlabs controllers was:

FW2:3->2,3->2,3->2,3->2,3->2, …
FW1:6->1,2->1,2->3,4->4,5->5, …

we see how the colour filterwheel (FW2) always sets the same filter and always seems to start at the one numbered one higher. Visual inspection during the cycling revealed that the colour of the light switched between the colour of the lamp and Green – i.e. the FW2 settings actually acquired were ‘Air’ and ‘V’ – not ‘B’ as I asked for.

FW1 meanwhile seems to have cycled irregularly – 1,1,3,4,5, … (2 is missing). It was not really easy to see whether various ND grades were inserted or not, but clearly AIR was one of them since I could see colours of the light.

Note that in a sequence “A->B” a sound – such as of a filter-wheel changing position – is heard before A, and before B.

Not sure what to make of this. It could be a signals problem where feedback from the actual position of the wheel is missed or missunderstood by the software so that new or wrong commands are sent.

Is the software that directs the FW giving absolute commands or relative ones, as in
“Go to the blue filter”
vs
“go to the filter after the one you are at, which I assume is the IRCUT filter, so that you will arrive at the B filter since it comes after IRCUT”?

Why does the wheel change position twice during a ‘set the FW-wheel’ command? Makes sense only if it always went to some home position, and then proceeded from there – but clearly it is not starting from the same position each time, given the readout above. Again, could it be that the intent is to send it to home each time but this goes wrong and it doesn’t actually arrive at home, but assumes it did for the next relative command?

NEXT time, we need ABSOLUTE ENCODERS. I want a little man inside the telescope with a cell phone calling us with the ACTUAL position of each FW!