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:
- 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.
- 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.
- 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