Focuser temperature read error

Last weekend I had a strange issue with focuser temperature read, SGPro showed “N/A” in focuser temperature window.

By digging into log, here is the normal sequence:

03:50:20.727 Connected Get True
03:50:20.727 Link Get True
03:50:20.727 Connected Get True
03:50:21.314 Focuser Transmit Command:GP#
03:50:21.349 Focuser Receive Response4724#
03:50:21.758 Focuser Transmit Command:GT#
03:50:22.195 Focuser Receive Response0047#
03:50:22.196 Temperature Get 0047
03:50:22.196 Focuser Transmit Command:ZA#
03:50:22.229 Focuser Receive Response0381#
03:50:22.229 Temperature Get 8.875
03:50:22.229 TemperatureAverage Get 8.97
03:50:22.464 Focuser Transmit Command:GP#
03:50:22.497 Focuser Receive Response4724#

For each “get temperature” request, the drive issues two commands “GT” and “ZA”, which reads current and average temperature, the driver then return one of the two back (base on an option setting). There is >0.2s from completion of “get temperature” to next request 'get position" (03:50:22.229 -> 03:50:22.464)

However the following sequence confused the driver/focuser:
03:50:40.740 Connected Get True
03:50:40.740 Link Get True
03:50:40.740 Connected Get True
03:50:41.448 Focuser Transmit Command:GP#
03:50:41.536 Focuser Receive Response4724#
03:50:41.971 Focuser Transmit Command:GT#
03:50:42.468 Focuser Receive Response0047#
03:50:42.468 Temperature Get 0047
03:50:42.468 Focuser Transmit Command:ZA#
03:50:42.504 Focuser Transmit Command:GP#
03:50:50.743 Connected Get True
03:50:50.743 Link Get True
03:50:50.743 Connected Get True
03:50:55.984 Focuser Transmit Command:GP#
03:50:57.809 Focuser Receive Response4724#
03:50:57.871 Focuser Receive Response4724#

SPPro sends a “get position” before “get temperature” request has completed.
Dirver/focuser does not get chance to complete the “get temperature” operation and does not return the value, so SGPro stops reading temperature thereafter, hence it assumed N/A for temperature reading.

So the question is that: is this a bug in SGPro, or a bug in driver? If it is driver how should driver behave?

Any help is appreciated!

I use version 2.6.0.23.

Hi,

This happens because SGP is a heavily multithreaded application. The position request and the temperature request are coming from different and unsynchronized threads inside SGP. Your focuser driver does not seem to be thread safe, as requested in the ASCOM specification.

I had the same problem with a commercial product called “USB-Focus” and I solved it by replacing it with a DIY controller and driver. What model is your focuser?

Regards,
Horia

Horia,

Thanks! It is my DIY focuser too, which has builtin temp comp so it tracks when temperature drops during frame.

Do you have an example that shows thread safe ASCOM driver? Mine is really simple so I dont think it is thread safe.

Thanks

The simplest way to make a driver thread safe is to ensure that only one thread can send a command and get a reply at a time. This can be done with the lock command in your driver, something like:

lock(lockObj)
{
serial.transmit(command);
var rx = serial.receiveTerminated(‘#’);
return rx;
}

This is done in a SendCommand function and all commands go through this. The lock command will only allow one thread through at a time.

This isn’t complete but should be enough to get you started.

Hi,

Chris allready gave you a pointer in C#. Just in case you prefer VB:

   Friend Class ComPortUser
   Private Shared resourceLock As New Object
   Private Shared c As New ComResource()

   Friend Function ComSendReceive(aCommand As String, aParameter As String) As Focuser.ComAnswer
	Dim anAnswer As Focuser.ComAnswer
	SyncLock resourceLock
		anAnswer = c.SendReceive(aCommand, aParameter)
	End SyncLock
	Return anAnswer
   End Function
End Class

The function “ComResource.SendReceive” implements the actual communication protocol for a given command, from sending the start Character of a command till the receiving the end character of the answer.

Regards,
Horia

Thanks Chris, Horia.

I will take a look.