Understanding the guider filter wheel

[davner]

After discussing with Mike L. and Greg S. I have an understanding of how we need to proceed with the Guider filter wheel.

The GFWINIT command sends the filter wheel 2 positions forward and I believe returns a value that corresponds to the position. (Note: it may be a second command that reads the position).

The filters in the guider fw need to be in a file in the order they are in the wheel. The guider fw is dumb and has no idea what filters are in what position. The only thing it knows is what slot it is at. It is up to us to "hardcode" the available filters in the correct order in a file that can be changed by operations staff if filters are every switched.

Upon finding out the current filter position, we can populate the filter names from the text file since we know the order.

Greg has supplied this cheatsheet for the guider filter wheel.

Looking at the table Greg S. supplied, we need to see the state of those 3 sensors and derive which filter slot it is at.

[davner]

Greg S. also said

1. 1 channel on Galil controlling Oriel filter wheel using a Stepper motor.
2. No limits utilized
3. 3 inputs for position sensors.

[dsand]

From 12/2 meeting: Phil Daly will review Mike Lesser's ascii code for the guider filter wheel gui and possibly confer with Mike regarding any misalignment. Adding Mike as an assignee here.

[dsand]

I'm staring at this thread a bit, and I think it means we still do not know which guider filter was in which slot last night. Is that your read too, @jhoscheidt & @pndaly ?

[dsand]

Copying an email from @pndaly as he dives into the Galil code here:

The problem: when moving the Oriel (guider) filter wheel the command is (for example) "GFILTN=2; XQ #GFWMOV;" ... we know this works (after initialization) as it does move the filter wheel. However, there does not seem to be any read back so it gets to an​ Oriel filter wheel position and we assume it's the correct one.

The answer (I think): Greg's diagram is very helpful and identifies 3 Hall-effect sensors. Jeff Rill had previously sent schematics (dated 2010 and if anyone wants a copy holler and I'll forward them). So, yesterday I attempted to reconcile where the Hall-effect sensors are wired and how we get the feedback. That said, I quickly gave up it's all very obscure to me (although I can follow the data lines from the axis H outputs to the Galil inputs well enough but I can't tell which data register they get mapped to).

Therefore, I went back to the old Galil code and did​ discover variables called FNUM/FNUM_IN and SNUM/SNUM_IN which are mappings from requested filter/sensor numbers and actual positions. FNUM_IN is a copy of GFILTN and the translation between FNUM/SNUM is in the CONVERT and UNCONV routines in the DMC code. The mapping is:

Fnum <-> Snum 0 < - - > 7 1 < - - > 1 2 < - - > 3 3 < - - > 2 4 < - - > 6 5 < - - > 4 6 < - - > 5 7 < - - > 0

Yeah, it'd be nice if position 1-6 matched Greg's table in some way but they don't. No idea why. The code also checks 1 <= FNUM <= 6 and outputs an error message if FNUM = 0|7.

I also discovered what may be the famous missing link​: there is a routine called READSN which appears to read the Hall-effect sensors. It gets used by the GFWMOV which returns when SNUM = SNUM_IN (the present value = the requested value). So, I think SNUM are the Hall-effect sensor(s) translated into a number. The DMC code is documented poorly:

NO READ SENSORS - CONVERT TO INTEGER

NO SENSOR POLARITY: LOW = 0, HI = 1

READSN

SNUM=((@IN[15]4)+(@IN[14]2)+@IN[13])

NO MG "BIT14",@IN[14]*4

NO MG "BIT13",@IN[13]*2

NO MG "BIT12",@IN[12]

NO MG "SNUM=",SNUM

WT 500

EN

So, it reads sensors 15, 14, 13 and multiplies them by 4, 2 and 1 (because they are interpreted as binary) and the 'NO' statements are comments (no-op, I think).

We can work with this, though. All of SNUM, SNUM_IN, FNUM and FNUM_IN are readable by my new code:

Galil command, '?' for help> MG FNUM_IN;

Galil_DMC_22x0_CLI received ' 2.0000::', rb=9, gstat=0

Galil command, '?' for help> MG FNUM;

Galil_DMC_22x0_CLI received ' 2.0000::', rb=9, gstat=0

Galil command, '?' for help> MG SNUM_IN;

Galil_DMC_22x0_CLI received ' 3.0000::', rb=9, gstat=0

Galil command, '?' for help> MG SNUM;

Galil_DMC_22x0_CLI received ' 3.0000::', rb=9, gstat=0

This is consistent with the above translation table. So, we do know where things are!

What we need to do, therefore, is eyeball the Oriel filter wheel when it's moving and reconcile Greg's table and the FNUM/SNUM table. Then we're good to go.

This can be done during any day-time when myself and Greg or Joe (or anyone else who wants to stare at the filter wheel) is available. It can be done during the upcoming run or before.

[dsand]

Next step is to do @pndaly 's suggestion:

What we need to do, therefore, is eyeball the Oriel filter wheel when it's moving and reconcile Greg's table and the FNUM/SNUM table. Then we're good to go.

[davner]

Whew that is quite the read! Nice discovery!

[dsand]

Update from an email that @pndaly wrote on Feb 8, 2022. This involved @jhoscheidt and John Morris looking at which filters were in, while Phil moved the wheel.

Thanks to Joe/John for manning the ladders between bites of mountain lion chili (ask Joe) ...

These tests went well and the results were consistent after a power cycle. It also dovetails with Greg's truth-table send previously. The only interesting part is that the #GFWINIT moves the filter wheel 2 spaces but doesn't appear to read anything back (I think it just makes sure the wheel is at some detent position). The software, therefore, needs to initialize the wheel and send it to a known position.

The software simply executes "GFILTN=val; XQ #GFWMOV;" where is between 1 and 6 and represents the value in the GFILTN column in this mapping:

Filter | GFILTN | FNUM_IN | FNUM | SNUM_IN | SNUM | Eyeball

                              7                0      

green 1 1 1 1 1 5

open 2 2 ? 3 3 4

neutral 3 3 ? 2 2 3

red 4 4 ? 6 6 2

open 5 5 ? 4 4 1

blue 6 6 ? 5 5 6

                              0                7    

(... the 'eyeball' column represents what Joe/John could read on the actual filter wheel and the 'filter' column is their visual check on the chunk of glass assuming no-one is colour blind!)

Note that the FNUM readback was inconsistent but, looking at the Galil DMC code, it's not really used anyway. So, the bok_gfilters.txt now reads:

This file contains the master look-up table for the 90prime guider filter wheel.

Filter\tCode\tName

0 F0 Ignore_as_never_used

1 green green

2 open open

3 neutral neutral

4 red red

5 open open

6 blue blue

The high-level software will reflect these values.

[dsand]

Adding some screenshots of tables that did not come out quite right in the previous comment.

[dsand]

And another.

[dsand]

Further note from @jhoscheidt in the same email thread:

John and I verified # 1 and #4 were truly open by running a very small piece of wire through the open hole just to make sure there wasn't something in each slot. Just for our records, the green filter has a clamshell chip on its edge and the blue one had a smaller one.

Also, there is about 1/4" of extra room to move the guider camera if we need more focus in the "out" direction. I will see if Mario can quickly make us another little aluminum depth gauge to help us set the camera retaining ring back a little further. This should be very easy to do.

[dsand]

Update on guider filter wheel, 2/14/2022. Able to send guider filter wheel commands through an INDI panel. Easy to cycle through the filters and establish focus. Tonight the values were: ​​

Filter1. green 1900 Filter2 Open 2700 Filter3 neutral 1700 Filter4 red 1700 Filter5 Open 2700 Filter6 blue 1650

Will check focus further tomorrow. Will report back.

[dsand]

As far as the guider filter wheel goes, I believe we understand what is going on. Future issues may focus on nudging users to keep an Open filter in the light path, as well as any focus issues that might come up (none so far).