...SelectedFocuser.IsMoving returns false before focuser completes move

[lowenthalm]

I have some misbehaving Python code that waits for my Celestron SCT focuser to complete its move. My focuser settings in SharpCap are configured to always approach in the negative direction with overshoot set to of 100 and settle time is set to 1 second.

After I set the desired focus position in Python code, which then calls this function:

Code: Select all

	# returns True focuser finished moving before the timeout, otherwise returns False
	def WaitForFocuserToFinishMoving( self, timeout_in_sec = 8, poll_frequence_in_sec = 0.5 ) -> bool :
		from System.Threading.Tasks import Task
		debug_count_down = 0 # set to non zero positive loop count to debug without focuser available

		def IsFocuserMoving( debug ):
			if debug > 0:
				return debug - 1
			else:
				#print( "Debug mode off: actually checking focuser for movement" )
				return SharpCap.Focusers.SelectedFocuser.IsMoving

		wait_time_in_ms = int(poll_frequence_in_sec * 1000)

		loops = int( timeout_in_sec / poll_frequence_in_sec + .99 )
		#print( f"Waiting with timeout {timeout_in_sec}, polling every {wait_time_in_ms} milliseconds, max {loops} loops until timeout." )
		for t in range( 0, loops):
			print( f"Waiting for focuser to settle...{t}" )
			is_moving = IsFocuserMoving( debug_count_down )
			if not is_moving:
				return True
			if debug_count_down > 0:
				debug_count_down = is_moving
			SharpCap.SafeWaitForAsync(Task.Delay(wait_time_in_ms))

		print( "Focuser Timeout occurred!" )
		return False

If I am moving the focuser in the negative direction, the above method correctly waits until the move is complete. However, If I move the focuser in the positive direction, the method will exit after the focuser completes the 100 step overshoot. I discovered this by printing the the focuser position when it exited and found the focuser was 100 steps above the focus position I had set.

It seems to me that SharpCap.Focusers.SelectedFocuser.IsMoving should return True until SharpCap has truly completed the entire focus move it needs to make. The current behavior is new, as the code above seemed to work fine back in October 2025. It may be a problem that arose in one of this years releases.

I worked around this by retrying calls WaitForFocuserToFinishMoving if I found the focuser was not in the final position yet.

[admin]

Hi,

that's interesting - there is code to cover this scenario in the overshoot handling - it should return moving if the underlying focuser is moving *or* there is a second target position lined up for the second part of the goto movement.

However, it looks like there is a small window where SharpCap is just sending the command for the second move and it clears the information about the second target at that point. Maybe the underlying focuser is still 'getting going' with the move and not yet reporting moving at that point.

I will see what I can do to close that window so that it works robustly - this will go into SharpCap 4.2

cheers,

Robin