[ACP-1779]  Dome Control Shows Shutter Status Even Though Correct Data is Coming From Dome Controller
Type Bug
Priority High
Severity Major
Component Main Program
Fixed In Version [9.09.0
Versions Affected [8.38.3
Severity Closed
Resolution Complete
Reported By Bob Denny
Resources Bob Denny
Start Date 7/20/2020

Description
See this Comm Center thread by Ed Michaels. This is a redux of Ed Walendowski's 2017 problem with TickCount starting out negative. See related issue ACP-1563 and the related Comm Center thread. Dome status is not being refreshed, and ShutterStatus is cold-initialized to ShutterError.

Comments
6/25/2021 11:55:48 AM   Bob Denny
No news from Stephane. Closing this.
6/9/2021 6:31:12 AM   Bob Denny
SVN Comment
Author rbdenny
Repository svn+ssh://rbdenny@a2_svn_dc3/home/rbdenny/svn/astro/acp
SVN Revision 1350
Affected files /trunk/DomeControl.cls (Modified)
Check-in comment Fix offset for GetTickCount init to a negative number like the changes I made for Telescope long ago. GEM:1779
6/8/2021 3:06:30 PM   Bob Denny
REOPENED


This is affecting Stephane Basa. I looked and I am initializing the polling counter to GetTickCount() + 10. This creates a subtle timing bug. It needs to be GetTickCount() - 10 like in ACP-1563.
7/20/2020 3:38:35 PM   Bob Denny
SVN Comment
Author rbdenny
Repository svn+ssh://rbdenny@a2_svn_dc3/home/rbdenny/svn/astro/acp
SVN Revision 1266
Affected files /trunk/ACP Help/relnotes.htm (Modified)
/trunk/ACP.vbp (Modified)
/trunk/DomeControl.cls (Modified)
Check-in comment Initialize Dome polling for system with tick-count that starts with large negative number. GEM:1779
7/20/2020 3:31:36 PM   Bob Denny
Same solution, initialize "next poll" to GetTickCount() + 10. (June 2021) No! GetTickCount() - 10.