Problem mit APT und PHD2 - Guiding stoppt bei Dither (und erholt sich nicht)

[gisfmp]

Liebe Gemeinde,

ich habe neulich die ganze Steuerungssoftware und so weiter auf meinen Desktop-PC aufgespielt und das Geraffel via Kabeldurchführung mit einem USB-Kabel verbunden, so dass ich nun hübsch in der warmen Stube sitzen kann, während draußen die Aufnahme läuft.

Im Grunde hat das alles auch ganz gut funktioniert. Allerdings habe ich nun ein Problem beim Dithern. Ich verwende APT als Aufnahmesteuerung und PHD2 fürs Guiding, was bislang (vom Notebook aus) mit den jeweiligen Standardeinstellungen gut funktioniert hat. Das Guiding als solches funktioniert und das Aufnehmen von Bildern funktioniert, auch die Kommunikation zwischen APT und PHD2 funktioniert, denn das Dithern wird korrekt ausgelöst.

Nun geschieht beim Dithern folgendes:
-APT sendet den Dither-Befehl
-PHD2 pausiert das Guiding
-PHD2 dithert (sieht man daran, dass der Leitstern aus dem Fadenkreuz verschoben wird; weiterhin steht in der Statistik der Hinweis "dither")
-PHD2 macht nichts weiter (es steht unten im Fenster "angehalten")

Dann passiert nichts mehr, der Leitstern wird von PHD nicht zentriert und APT wartet auf den Abschluss des Ditherns. Interessant ist hierbei auch, dass APT trotz "dither timeout" nicht mit der Aufnahmeserie weitermacht; es scheint in einer Schleife zu hängen.

Hat irgendwer dieses Problem schon einmal gehabt und weiß vielleicht eine Lösung hierzu?? Ich habe die Software bereits deinstalliert und neu installiert, ohne Besserung.

Noch als Zusatz: der PHD2-Log sieht wie folgt aus:

[Guiding-Befehle]
48,131.462,"Mount",-0.033,0.102,-0.019,-0.102,0.000,0.000,0,,0,,,,332,12.88,0
INFO: Server received PAUSE
INFO: Server received RESUME
INFO: Server received PAUSE
INFO: SET LOCK POSITION, new lock pos = 453.686, 825.810
INFO: DITHER by -4.987, 0.636, new lock pos = 458.391, 827.584
INFO: SETTLING STATE CHANGE, Settling started
INFO: SETTLING STATE CHANGE, Settling complete
--
Dann ist Schluss, d.h. PHD2 stoppt das Guiding nicht komplett (dann steht z.B. "Guiding Ends at 2021-03-12 19:51:57" im Log).

Ich bin über alle Hinweise dankbar!

Viele Grüße
Marcel

 

[wynnie]

Hallo Marcel,

ohne jetzt Deine Logs mit meinen verglichen zu haben glaube ich, dass ich das gleiche Problem hatte. Zumindest hatte ich das gleiche Fehlerbild. Das Problem trat sowohl mit der aktuellen Version von phd auf, als auch mit der Entwickler Version. Dann habe ich APT auf die aktuelle Beta Version angehoben und das Problem verschwand.
Morgen werde ich mir noch mal die Logs abschauen und sehen ob der Fehler mit Deinem übereinstimmt.

Viele Grüße
Michael

 

[gisfmp]

Hi Michael,

vielen Dank für Deine Antwort. Ich habe inzwischen etwa mehr recherchiert und mir auch das debug-logfile von PHD2 angeschaut. Dort sind zum Zeitpunkt des Ditherns Fehlermeldungen enthalten, die bei meinem alten Setup gar nicht vorkommen, und die wohl ein Hinweis auf das Problem sind. Diese sehen wie folgt aus:

###
19:13:40.212 03.063 16348 read socket command 123
19:13:40.214 00.002 16348 SOCKSVR: Unknown command char received from client: 123

19:13:40.215 00.001 16348 Sending socket response 1 (0x1)
19:13:40.217 00.002 16348 read socket command 34
19:13:40.218 00.001 16348 SOCKSVR: Unknown command char received from client: 34

19:13:40.219 00.001 16348 Sending socket response 1 (0x1)
###

Nach einer Vielzahl solcher Fehlermeldungen, bei denen die Nummer des Clients ständig wechselt, führt PHD2 dann das Dithern durch, allerdings fängt er sich nicht wieder und kommt nicht zum Guiding zurück (weshalb wohl auch APT nicht mit der Aufnahmeserie weitermacht....).


Ich habe parallel im APT Forum angefragt und den Hinweis bekommen, dass der Port in den Einstellungen für die Kommunikation mit PHD2 auf 4400 gesetzt sein muss, bei mir war 4300 eingestellt. Konnte noch nicht probieren, ob das die Lösung ist, es klingt aber plausibel. Ich berichte nochmal, wenn das Problem damit behoben ist.

Viele Grüße
Marcel

 

[wynnie]

Hallo Marcel,

ich habe jetzt mal die Logdateien analysiert und bei mir passierte genau das gleiche :

[...]
20:06:32.062 00.000 3120 Sending socket response 1 (0x1)
20:06:32.062 00.000 3120 read socket command 49
20:06:32.062 00.000 3120 SOCKSVR: Unknown command char received from client: 49

20:06:32.062 00.000 3120 Sending socket response 1 (0x1)
20:06:32.062 00.000 3120 read socket command 125
20:06:32.078 00.016 3120 SOCKSVR: Unknown command char received from client: 125
[...]

Dann dreht er einige Runden, landet aber immer bei :

3120 Throw from C:\cygwin\home\agalasso\projects\phd2\guider.cpp:1358->Skipping frame - guider is paused

Und das wars. Mit der APT Version 3.87.8 und der gleichen PHD2 Version (v2.6.9dev4) sieht die Sache dann ganz anders aus :

[...]
20:31:28.900 00.015 7680 SchedulePrimaryMove(06BEC608, x=-0.08, y=-0.06, opts=13)
20:31:28.900 00.000 7680 Enqueuing Move request for scope (-0.08, -0.06)
20:31:28.900 00.000 3672 Worker thread wakes up
20:31:28.900 00.000 3672 worker thread servicing REQUEST_MOVE scope ofs (-0.08, -0.06) opts 0xd
20:31:28.900 00.000 3672 Handling offset move in thread for scope, endpoint = (-0.08, -0.06)
20:31:28.900 00.000 3672 Moving (-0.08, -0.06) raw xDistance=-0.10 yDistance=0.00
20:31:28.900 00.000 3672 PPEC rslt(dithering): input = -0.10, final = -0.06
20:31:28.900 00.000 3672 PPEC: input: -0.10, control: -0.06, exposure: 2000
20:31:28.900 00.000 3672 Throw from C:\cygwin\home\agalasso\projects\phd2\guide_algorithm_resistswitch.cpp:107->input < m_minMove
20:31:28.900 00.000 3672 GuideAlgorithmResistSwitch::result() returns 0.00 from input 0.00
20:31:28.900 00.000 3672 MoveAxis(E, 33, ABG)
20:31:28.900 00.000 3672 Guiding Dir = 2, Dur = 33
20:31:28.900 00.000 3672 IsGuiding returns 0
20:31:28.916 00.016 7680 UpdateImageDisplay: Size=(1280,1024) min=0, max=255, med=3, FiltMin=2, FiltMax=113, Gamma=0.340
20:31:28.916 00.000 3672 PulseGuide returned control before completion, sleep 40
20:31:28.963 00.047 3672 IsGuiding returns 0
20:31:28.963 00.000 3672 Move returns status 0, amount 33
20:31:28.963 00.000 3672 MoveAxis(N, 0, ABG)
20:31:28.963 00.000 3672 Move returns status 0, amount 0
20:31:28.963 00.000 3672 move complete, result=0
20:31:28.963 00.000 3672 worker thread done servicing request
20:31:28.994 00.031 7680 UpdateGuideState exits: m=3451 SNR=40.8 Gesättigt
20:31:28.994 00.000 7680 PhdController: settling, locked = 1, distance = 0.10 (0.70) aobump = 0 frame = 5 / 99999
20:31:28.994 00.000 7680 evsrv: {"Event":"Settling","Timestamp":1615059088.994,"Host":"ASTROLAPTOP","Inst":1,"Distance":0.10,"Time":7.0,"SettleTime":15.0,"StarLocked":true}
20:31:28.994 00.000 7680 OnExposeComplete: CaptureActive=1 m_continueCapturing=1
20:31:28.994 00.000 7680 ScheduleExposure(2000,3,1) exposurePending=0
20:31:28.994 00.000 7680 Enqueuing Expose request
[...]

Anscheinend liegt der Fehler bei APT und wurde in einer der aktuelleren Versionen behoben.
Der Port war immer 4400, hat sich also nicht geändert und es hätte sonst auch kaum funktioniert, denke ich.
Auch wenn ich sonst kein Freund von Beta Versionen bin, so kann ich nur empfehlen auf die aktuelle Beta von APT zu wechseln. Das Multistar Guiding mit PHD v2.6.9v4 funktionierte bei mir danach zwei Nächte lang ohne Fehl und Tadel.

Viele Grüße
Michael