CCDCamera.Filter Mismatch With Reality After Startup

Discussion in 'Scripting and Programming' started by Bob Denny, Oct 24, 2014.

  1. Bob Denny

    Bob Denny Cyanogen Customer

    Joined:
    Oct 12, 2014
    Messages:
    801
    Location:
    DC-3 Dreams, SP, Mesa, Arizona +1 480 396 9700
    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!
     
  2. Andrei Ioda

    Andrei Ioda Cyanogen Customer

    Joined:
    Oct 13, 2014
    Messages:
    42
    Location:
    k.Stan
    I confirm this issue. I've had problems with flats.
     
  3. Owen Lawrence

    Owen Lawrence Retired Staff

    Joined:
    Oct 1, 2014
    Messages:
    1,397
    Filter wheels don't always have the ability to report their current position. Our camera plugin API reflects this by exposing a "push only" protocol. Hence, you should set the desired filter position at least once. Monitoring the CCDCamera.Filter property will only catch changes a user makes manually through the GUI. That property is a "user setting", and that's why it's persistent.

    - Owen -
     
  4. Bob Denny

    Bob Denny Cyanogen Customer

    Joined:
    Oct 12, 2014
    Messages:
    801
    Location:
    DC-3 Dreams, SP, Mesa, Arizona +1 480 396 9700
    Hmm... so CCDCamera.Filter is not reliable? In my purist way of thinking, if MaxIm is not able to provide an answer to X = CCDCamera.Filter then it should raise an error "I don't know how to answer this query because the filter wheel doesn't tell me where it is". Really. If it had adhered to the basic rule "Do it right or raise an error" much pain would have been avoided :) :) It should definitely not provide an incorrect answer as though it did know!
     
    LDunn1 likes this.
  5. LDunn1

    LDunn1 Cyanogen Customer

    Joined:
    Oct 27, 2014
    Messages:
    7
    Bob, apart from not want to add unnecessary wear to the filter wheel components, I would imagine that completing an image run with no filter move would be desirable so that flat lights can be taken through the unmoved filter at the end of a light run through a filter.......how confident would one be of the filter returning to exactly the same spot after each move such that a spec of dust or hair would shadow exactly the same pixels. Just a thought......
     
  6. Bob Denny

    Bob Denny Cyanogen Customer

    Joined:
    Oct 12, 2014
    Messages:
    801
    Location:
    DC-3 Dreams, SP, Mesa, Arizona +1 480 396 9700
    Yeah, I understand Owen's info, but I'm trying to help get the API more robust. I will press again after the SWAP/ASAE show (I leave tomorrow).
     
  7. Andrei Ioda

    Andrei Ioda Cyanogen Customer

    Joined:
    Oct 13, 2014
    Messages:
    42
    Location:
    k.Stan
    That is strange.

    Screenshot 2014-10-30 23.58.18.jpg Screenshot 2014-10-30 23.58.39.jpg
     
  8. Bob Denny

    Bob Denny Cyanogen Customer

    Joined:
    Oct 12, 2014
    Messages:
    801
    Location:
    DC-3 Dreams, SP, Mesa, Arizona +1 480 396 9700
    Andre I don't understand. That slot 1 in MaxIm is slot 0 in ACP?
     
  9. Andrei Ioda

    Andrei Ioda Cyanogen Customer

    Joined:
    Oct 13, 2014
    Messages:
    42
    Location:
    k.Stan
    Hi Bob,

    It's a part of my conversation about a bug in FM (beta). We've solved this issue.

    Concerning issue with filters, i have one idea. I suppose need to try put command into ShutdownObs script to change filter to Luminance (#0).

    Could you give me this part of code? I will test.
     
    Last edited: Nov 7, 2014
  10. Bob Denny

    Bob Denny Cyanogen Customer

    Joined:
    Oct 12, 2014
    Messages:
    801
    Location:
    DC-3 Dreams, SP, Mesa, Arizona +1 480 396 9700
    I'm working on solutions that force the filters in MaxIm to match.
     

Share This Page