My client software uses MaxIm for imaging. I create a CCDCamera and 'get' the value of CCDCamera.Filter. I compare this with the filter being asked for by the run, and if they are the same I do not 'set' CCDCamera.Filter to the same value. I do this because in the past I had complaints about "some" filter wheels moving and creating excessive wear when setting the filter to the same one already set. I know it's dumb, but some of the wheels did (and probably still do) this. Imagine the wear on a photometric sequence of 800 images in one night, all in the same filter. Now for what I think is my current problem. If someone starts MaxIm, connects to the camera, then I create a CCDCamera, then read CCDCamera.Filter, I see the filter that was selected the last time MaxIm was shut down. IOW, If the previous night's imaging run ended in a V filter, I will see V selected the next night right after starting MaxIm. So far so good. However, if the particular model of filter wheel does a "home" (rotate to slot #1 or whatever) when it is powered up, MaxIm records this fact somewhere because an image taken at that point will show this filter not the previous night's filter (unless it happens to be the same home slot ). Here's what I think is the problem: In this situation, CCDCamera.Filter will continue to report the previously selected filter for imaging, not the (correct) filter after homing. So in my previous example, CCDCamera.Filter will report V when the filter wheel is actually at slot #1 (not V). Combined with my logic of skipping setting CCDCamera.Filter if I read back the one I need, the result is taking am image in the wrong filter. Can you look and see if this is right? If so I may be able to work around this mismatch, but I suspect you will want to correct the API so it always shows the currently selected filter. Thanks!