[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.0] 9.0
Versions Affected [8.3] 8.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.