TiGra Networks
The Small Business IT Specialists
TiGra Networks
The Small Business IT Specialists
www.tigranetworks.co.uk

Dome Response

Latest post 11-30-2008 20:08 by paulshulins. 4 replies.
  • 12-02-2006 6:59

    Dome Response

    Hi Tim,

    We are using ACP and your DDW driver V1.  At times the dome fails to rotate when the telescope is slewed to a new position. Then after several seconds it does slew to the correct position but sometimes after the first image is taken.  Is there a poll setting in the configuration I can change or is this something in the DDW hardware?

    • Post Points: 0
  • 12-02-2006 17:03 In reply to

    Re: Dome Response

    I've seen this happen (but not on my dome) and I'm not sure what causes it. ACP uses a dual strategy for positioning the dome. When the telescope is slewed, ACP tries to move the dome directly to the target position at that time. Between slews, ACP constantly monitors the dome position and nudges it to track the telescope. This approach works well but sometimes the initial slew doesn't seem to happen; the dome eventually catches up when ACP resumes slaving at the end of the telescope slew. I'm not sure if ACP isn't sending the initial slew or if there is some sort of interaction between ACP and DDW that's causing the slew to fail - I can't reproduce it here. What we would really need is to try to reproduce the failure with the dome driver debugging enabled, so we can see what commands are being sent to the dome. We'd need to watch the dubug output to see whether ACP is sending the initial slew.

    If we assume the problem is in the dome driver, then I can see some situations that might lead to this happening:

    1. Sometimes DDW can miss commands if the internal PIC controller is busy. The manual says that if DDW doesn't respond then the command should be retried. The driver has logic to do that. Currently, it re-tries once then gives up. Maybe I should increase the number of re-tries - I will look into the implications of doing that.
    2. If the dome receives characters on the serial port while a command is in progress, then the new command will be interpreted as an All Stop command - motion will stop and the second command will be discarded. The DDW driver is actually not very 'chatty' and only communicates with the hardware when it is absolutely necessary (it doesn't 'poll' continuously like some drivers do). If the application sends a new command while another is still in progress, then the driver will first send an All Stop command, then execute the new command. Again, this will show up in the debug logs.
    3. There is one occasion when the driver sends unsolicited traffic. It has a keep-alive timer that is designed to send a status poll every few minutes, to prevent DDW from thinking it has lost communications and closing the dome. The driver is designed so that it only sends this poll if it needs to (i.e. there has been not data sent for a while). If this poll were to be sent just after a command from the application, then it could have the effect of cancelling the command.

    As I can't reproduce the problem here, I have to rely on your willingness to help troubleshoot the problem. The easiest way to start is probably to eliminate the keep-alive timer as the source of the problem. We can do this by editing the DDWSettings.xml that is in the driver directory. Edit the file with notepad or an XML editor and look for the following line:

    <nKeepAliveInterval>60000</nKeepAliveInterval>

    The value is in milliseconds so the default is 1 minute. Change the 60000 value to something stupidly large, like 86400000 (which is 24 hours expressed in milliseconds) that should effectively prevent any keep-alives from ever being generated. See if the problem re-occurs. Note, if ACP doesn't send and movement commands for a few minutes, the dome will auto-close, so be aware of that.

     

    Tim Long TiGra Networks http://www.tigranetworks.co.uk

    Filed under:
    • Post Points: 0
  • 04-04-2007 6:43 In reply to

    Re: Dome Response

    Hi Tim,

    I'm just now getting back on this.  I changed the keep alive timer and all it did was close the dome after a period of inactivity. :-)  I've never gotten to monitor the system with the debugger.  Is that the DDW Diagnostic panel?

    I've asked Bob Denny about adding something to ACP that monitors the dome position so it doesn't start an exposure until the dome actually moves. He said that wasn't practical to do and that perhaps you could add polling to the driver.

    On another note, i've tried the V2 driver twice now.  The first time I used it the dome closed during a run.  This last time I got a shutter error message during the night and things came to a halt.  When I opened the DDW program it said the shutter was open and when I reconnected it to ACP it too said things werethen OK.  Thanks.

    John G

    • Post Points: 0
  • 05-03-2008 2:59 In reply to

    Re: Dome Response

     Hello,

     

    I am having the exact same problem. Has there been a solution found?

     

    Thanks,

     

    Paul Shulins

     Andover, MA

     

     

    • Post Points: 0
  • 11-30-2008 20:08 In reply to

    Re: Dome Response

    Hi Tim,

     

    I was going to get back on this. Are you still available to help troubleshoot?

    Was not sure if you were still maintining the driver for DDW.

     

    Thanks,

     

    Paul

     

    • Post Points: 0
Page 1 of 1 (5 items) | RSS
Locations of visitors to this page
Copyright © 2005-8 TiGra Networks, all rights reserved
Powered by Community Server (Non-Commercial Edition), by Telligent Systems