Dienstag, 10. Dezember 2013, 09:13
Hallo,
Leider besteht das Problem weiter. Seit meinen letzten Eintrag habe ich vieles Einstellungen ausprobiert, aber bisher ohne Erfolg:
Ich muss mir jetzt immer den Wecker um 23:30Uhr stellen, aufstehen und manuell die Kurslücke schließen. Das ist sehr suboptimal und ich bin auch häufig auf Dienstreise ...
Ich habe mich sehr darüber gefreut, dass das RTT-Tool jetzt auch lokal seine Einstellungen speichern kann und damit auch mehrere TWS'en besser unterstützt.
Nur leider ist der Preis hierfür, dass seit dem ich diese neuere Version nutze, dass das oben beschrieben Reconnecten, nach dem Neustart der TWS nicht mehr funktioniert. Bitte Hr. Knöpfel können Sie da mal nachschauen, ob sich hier zwischen den Versionen etwas versehentlich verändert hat.
Oder gibt es vielleicht noch einen anderen Weg, den reconnect wieder automatisiert hin zu bekommen.
Danke.
Viele Grüße,
Sten
Zitat
So kurz nach 23:10Uhr schaltet sich die TWS bei mir ab und wird 3min später wieder gestartet. RTT läuft durch und zumindestens das alte RTT konnte sich nach dieser Zeit wieder problemlos reconnecten an seine neu gestartete TWS.
Leider besteht das Problem weiter. Seit meinen letzten Eintrag habe ich vieles Einstellungen ausprobiert, aber bisher ohne Erfolg:
- die Hinweise von Frieder
- habe die Zeit bis zum reconnecten der neu gestartete TWS verkürzt von 3min -> 1min
- ich habe festgestellt, wenn man nach dem Neustart der TWS, das RTT-Tool ebenfalls manuell neu startet, dann wird die Connection wieder korrekt aufgebaut
- um das nicht jedesmal manuell machen zu müssen, habe ich im RTT die Option aktiviert, 1ne Minute nach dem Neustart der TWS, ebenfalls das RTT neu zu starten. Was manuell super funktioniert, funktioniert aber nicht automatisiert, d.h. wenn das RTT-Tool im Kursnachlademodus ist, wird der programmierte Restartbefehl ignoriert, bis alle 99 Titel nachgeladen wurden und das kann locker 1h und länger dauern
- und jetzt das nächste Problem: wenn das RTT dann endlich nach X min den Restart durchführt, setzt zwar korrekt der Kursnachlade-Modus ein, ABER es wird nicht die Kurslücke ab 23:15Uhr geschlossen, d.h. es werden die Kurse erst viel später nachgeladen, so dass ein Kurslücke bestehen bleibt
Ich muss mir jetzt immer den Wecker um 23:30Uhr stellen, aufstehen und manuell die Kurslücke schließen. Das ist sehr suboptimal und ich bin auch häufig auf Dienstreise ...
Ich habe mich sehr darüber gefreut, dass das RTT-Tool jetzt auch lokal seine Einstellungen speichern kann und damit auch mehrere TWS'en besser unterstützt.
Nur leider ist der Preis hierfür, dass seit dem ich diese neuere Version nutze, dass das oben beschrieben Reconnecten, nach dem Neustart der TWS nicht mehr funktioniert. Bitte Hr. Knöpfel können Sie da mal nachschauen, ob sich hier zwischen den Versionen etwas versehentlich verändert hat.
Oder gibt es vielleicht noch einen anderen Weg, den reconnect wieder automatisiert hin zu bekommen.
Danke.
Viele Grüße,
Sten
Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »sten« (10. Dezember 2013, 09:35)
Dienstag, 10. Dezember 2013, 10:18
Hallo Sten,
das ist ja ein ziemlicher Albtraum, den du dir da selber erbaut hast....
Wenn du schon auf die manuelle Nummer stehst, dann stelle dir doch einfach deinen Wecker auf 18:55 oder fünf Minuten vor einer anderen Nachrichtensendung, die du regelmäßig siehst: dann braucht es nur einen Klick in der TWS unter API-Eimstellungen und du stellst die API logoff-zeit von pm auf am....Thema durch! Das dauert ca. 5 sec. und ist allemal besser als der Murks, den du so beschreibst.
Unabhängig davon sind aber einige Einstellungen bei deiner API nicht korrekt, denn die von dir beschriebenen Fehler habe ich schon einige Jahre nicht mehr erlebt.
Mein Tipp: am Wochenende mal alles komplett neu installieren....
Happy fixing,
Frieder
das ist ja ein ziemlicher Albtraum, den du dir da selber erbaut hast....
Wenn du schon auf die manuelle Nummer stehst, dann stelle dir doch einfach deinen Wecker auf 18:55 oder fünf Minuten vor einer anderen Nachrichtensendung, die du regelmäßig siehst: dann braucht es nur einen Klick in der TWS unter API-Eimstellungen und du stellst die API logoff-zeit von pm auf am....Thema durch! Das dauert ca. 5 sec. und ist allemal besser als der Murks, den du so beschreibst.
Unabhängig davon sind aber einige Einstellungen bei deiner API nicht korrekt, denn die von dir beschriebenen Fehler habe ich schon einige Jahre nicht mehr erlebt.
Mein Tipp: am Wochenende mal alles komplett neu installieren....
Happy fixing,
Frieder
Mittwoch, 11. Dezember 2013, 21:21
Hallo Chris
Dieser Forums Thread fing mit einem Fehlerbild an, was mit Deinem Problem schon wegen unterschiedlicher Programme nichts zu tun hat. Dies ist unschön, weil spätere Leser im Thread dann schwer nachvollziehen können, was eigentlich los war, weil es unfein ist, in einem Thread mehrere Themen durcheinander zu bringen. Und auch unfair gegenüber dem Thread-Eigentümer (üblicherweise dem ersten Poster).
Normalerweise ist es eine gute Idee, zu jedem Problem einen eigenen neuen Thread zu eröffnen. Aber ok, vielleicht konntest Du dies nicht überblicken und fandest, Reconnect-Problem ist Reconnect-Problem. Birne ist ja auch Apfel, weil beides Obst ist. Vielleicht nennen wir sowas dann einfach "Bapfel"
Was Dein Problem betrifft, dies kann auch ganz einfach hausgemacht sein: wenn Du nämlich mehrere Investox Instanzen laufen hast, die Du mit den automatischem Reconnect beauftragt hast, und zwei davon wegen unachtsamer Parametrisierung Deinerseits die gleiche Client-ID verwenden. Wenn der eine abfliegt wie im Bild gezeigt, dann kommt der andere im selben Moment an die freigewordene Client-ID - und der Reconnect der von Dir gezeigten Instanz würde genau diese Fehlermeldung "Es konnte keine Verbindung hergestellt werden da der Client bereits benützt wird." zeigen.
Es sind noch andere Fehlkonfigurationen denkbar, die dieses Fehlerbild hervorbringen würden.
Völlig unklar bleibt, was Reconnect-Probleme von Investox 6.9.2 (Trade-Session) mit dem Thema des Threads "neues RTTv3.2.1: Probleme beim reconnect zur TWS?" (Quote-Session) zu tun haben. Bapfel.
Dieser Forums Thread fing mit einem Fehlerbild an, was mit Deinem Problem schon wegen unterschiedlicher Programme nichts zu tun hat. Dies ist unschön, weil spätere Leser im Thread dann schwer nachvollziehen können, was eigentlich los war, weil es unfein ist, in einem Thread mehrere Themen durcheinander zu bringen. Und auch unfair gegenüber dem Thread-Eigentümer (üblicherweise dem ersten Poster).
Normalerweise ist es eine gute Idee, zu jedem Problem einen eigenen neuen Thread zu eröffnen. Aber ok, vielleicht konntest Du dies nicht überblicken und fandest, Reconnect-Problem ist Reconnect-Problem. Birne ist ja auch Apfel, weil beides Obst ist. Vielleicht nennen wir sowas dann einfach "Bapfel"
Was Dein Problem betrifft, dies kann auch ganz einfach hausgemacht sein: wenn Du nämlich mehrere Investox Instanzen laufen hast, die Du mit den automatischem Reconnect beauftragt hast, und zwei davon wegen unachtsamer Parametrisierung Deinerseits die gleiche Client-ID verwenden. Wenn der eine abfliegt wie im Bild gezeigt, dann kommt der andere im selben Moment an die freigewordene Client-ID - und der Reconnect der von Dir gezeigten Instanz würde genau diese Fehlermeldung "Es konnte keine Verbindung hergestellt werden da der Client bereits benützt wird." zeigen.
Es sind noch andere Fehlkonfigurationen denkbar, die dieses Fehlerbild hervorbringen würden.
Völlig unklar bleibt, was Reconnect-Probleme von Investox 6.9.2 (Trade-Session) mit dem Thema des Threads "neues RTTv3.2.1: Probleme beim reconnect zur TWS?" (Quote-Session) zu tun haben. Bapfel.
Gruss
Bernd
Bernd
Donnerstag, 12. Dezember 2013, 09:39
Hallo,
zum Client-ID-Problem:
Es kam die Meldung:
Dies zeigt an, dass Investox einen Disconnect zur IB-API durchgeführt hat (gibt Client-ID frei). Wenn danach die API meldet, dass die Client-ID schon benutzt wird, dann hat sich die API vermutlich "aufgehängt". Wenn dies öfters vorkommt, würde ich die API-Installation überprüfen (aktuelle Relase-Version etc.). Ansonsten könnte ein (automatischer) Neustart von Investox zur kritischen Zeit helfen (Aufgaben-Manager). Ich würde auch einen Neustart von TWS bzw. Gateway alle paar Tage empfehlen, da diese nicht immer den verwendeten Speicher freigeben.
Auch das ist jedenfalls merkwürdig, da der Vorgang beim manuellen Verbinden identisch zum automatischen Verbinden ist.
Es gibt ja Warnmechanismen von Investox hierfür (Aufgaben-Manager), die beim automatischen Handeln auch genutzt werden sollten.
Viele Grüße
Andreas Knöpfel
zum Client-ID-Problem:
Es kam die Meldung:
11.12.2013 00:13:07] Verbindung zu IB-Broker abgebrochen
Details: Die IB-Broker-Verbindung wurde geschlossen
Dies zeigt an, dass Investox einen Disconnect zur IB-API durchgeführt hat (gibt Client-ID frei). Wenn danach die API meldet, dass die Client-ID schon benutzt wird, dann hat sich die API vermutlich "aufgehängt". Wenn dies öfters vorkommt, würde ich die API-Installation überprüfen (aktuelle Relase-Version etc.). Ansonsten könnte ein (automatischer) Neustart von Investox zur kritischen Zeit helfen (Aufgaben-Manager). Ich würde auch einen Neustart von TWS bzw. Gateway alle paar Tage empfehlen, da diese nicht immer den verwendeten Speicher freigeben.
Die Verbindung lässt sich nur manuell durch den Menübefehl Interactibe Broker verbinden wieder herstellen.
Auch das ist jedenfalls merkwürdig, da der Vorgang beim manuellen Verbinden identisch zum automatischen Verbinden ist.
da durch eine Fehlende Verbindung über Nacht meine US Order nicht geschlossen werden können.
Es gibt ja Warnmechanismen von Investox hierfür (Aufgaben-Manager), die beim automatischen Handeln auch genutzt werden sollten.
Viele Grüße
Andreas Knöpfel
Donnerstag, 12. Dezember 2013, 10:36
Hallo Herr Knöpfel, hallo Bernd,
@Herrn Knöpfel:
Vielen Dank für den Hinweis!
Ich hatte die TWS API Version 9.51 installiert und diese jetzt auf die noch aktuelle Version 9.69 upgedated.
Ich beobachte das Verhalten und melde mich, falls das Problem noch vorhanden ist.
@Bernd:
schön von Dir zu hören und vielen Dank für deine Antwort.
Ja, Du hast recht was deinen Kritikpunkt angeht.
Ich dachte mir, da die IB-Kommunikation nur über eine API läuft, wäre es eine gute Idee auf diesen Threat aufzuspringen.
Aber im weiteren Verlauf ist mir selber klar geworden, dass in einem Forum eine modulweise Beschreibung für andere Leser zwecks Zuordnung doch hilfreicher ist.
Also Asche über mein Haupt und sorry an dich Sten!
Ich verwende übrigens nur eine Investox-Instaz. Das Gateway zeigt aber 2 verbundene API Clients an.
Auf der anderen Seite denke ich der Hinweis von Herrn Knöpfel zur TWS-API-Version kann für den Ursprungsthread durchaus hilfreich sein.
Vielleicht haben wir hier ja mal in der Tat einen Bapfel
@Herrn Knöpfel:
Vielen Dank für den Hinweis!
Ich hatte die TWS API Version 9.51 installiert und diese jetzt auf die noch aktuelle Version 9.69 upgedated.
Ich beobachte das Verhalten und melde mich, falls das Problem noch vorhanden ist.
@Bernd:
schön von Dir zu hören und vielen Dank für deine Antwort.
Ja, Du hast recht was deinen Kritikpunkt angeht.
Ich dachte mir, da die IB-Kommunikation nur über eine API läuft, wäre es eine gute Idee auf diesen Threat aufzuspringen.
Aber im weiteren Verlauf ist mir selber klar geworden, dass in einem Forum eine modulweise Beschreibung für andere Leser zwecks Zuordnung doch hilfreicher ist.
Also Asche über mein Haupt und sorry an dich Sten!
Ich verwende übrigens nur eine Investox-Instaz. Das Gateway zeigt aber 2 verbundene API Clients an.
Auf der anderen Seite denke ich der Hinweis von Herrn Knöpfel zur TWS-API-Version kann für den Ursprungsthread durchaus hilfreich sein.
Vielleicht haben wir hier ja mal in der Tat einen Bapfel
Grüße,
Christian
Christian
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »chris2000« (12. Dezember 2013, 10:43)
Donnerstag, 12. Dezember 2013, 11:22
Hi Chris
Ja nee, is klar, Eisgekühlter Bommerlunder. 1x Investox, 1x RTT/IB, das macht zwei belegte Brote, eins mit Schinken, eins mit Ei
Ja, das macht eine Fehlkonfiguration unwahrscheinlich.
Bei mir war es bisher immer eine Fehlkonfiguration, wenn diese Fehlermeldung kam (ok, hier auch eine grössere Anzahl Investox Instanzen am Start); hängende GW's / API waren bisher dafür nicht verantwortlich. Andererseits ist Deine historische API Version schon etwas "ausserhalb der normalen Bandbreite", vielleicht lag es ja wirklich daran. Ich Drücke die Daumen, dass der Tipp von Herrn Knöpfel hilft!
Einen Bapfel wird Evolution aber wohl hier nicht gebären; hier altes API, da Problem mit neuestem RTT, es sei denn es stellte sich heraus, dass sten das aktuelle RTT mit einem archaische API betrieben haben würde
Bereitest Du Dir hier einen anderen Bapfel vor, in dem Du listig antike Release-Stände mit aktueller TWS/API/Investox Software kombinierts?
Das Gateway zeigt aber 2 verbundene API Clients an.
Ja nee, is klar, Eisgekühlter Bommerlunder. 1x Investox, 1x RTT/IB, das macht zwei belegte Brote, eins mit Schinken, eins mit Ei
Ich verwende übrigens nur eine Investox-Instaz.
Ja, das macht eine Fehlkonfiguration unwahrscheinlich.
Ich hatte die TWS API Version 9.51 ... Auf der anderen Seite denke ich der Hinweis von Herrn Knöpfel zur TWS-API-Version kann für den Ursprungsthread durchaus hilfreich sein.
Bei mir war es bisher immer eine Fehlkonfiguration, wenn diese Fehlermeldung kam (ok, hier auch eine grössere Anzahl Investox Instanzen am Start); hängende GW's / API waren bisher dafür nicht verantwortlich. Andererseits ist Deine historische API Version schon etwas "ausserhalb der normalen Bandbreite", vielleicht lag es ja wirklich daran. Ich Drücke die Daumen, dass der Tipp von Herrn Knöpfel hilft!
Einen Bapfel wird Evolution aber wohl hier nicht gebären; hier altes API, da Problem mit neuestem RTT, es sei denn es stellte sich heraus, dass sten das aktuelle RTT mit einem archaische API betrieben haben würde
Verwendung des ... RTT 2.10.x
Bereitest Du Dir hier einen anderen Bapfel vor, in dem Du listig antike Release-Stände mit aktueller TWS/API/Investox Software kombinierts?
Gruss
Bernd
Bernd
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Bernd« (12. Dezember 2013, 11:27)
Freitag, 13. Dezember 2013, 20:26
Hallo,
Welche Version der TWS sollte man derzeit am besten verwenden, die aktuellste von IB (TWS 936 • Mar 6 2013) oder die TWS 903.5 (http://www.investoxforum.de/index.php?pa…BData&dataID=95) welche in der Forumdatabase abgelegt ist?
Es gab da doch mal Probleme bzw. sind diese noch aktuell.
Danke.
Viele Grüße,
Sten
PS:
BS: winXP
RTT: 3.2.1
TWS API Version 9.60
Lenzelott: Oder einfach das gateway verwenden.
Welche Version der TWS sollte man derzeit am besten verwenden, die aktuellste von IB (TWS 936 • Mar 6 2013) oder die TWS 903.5 (http://www.investoxforum.de/index.php?pa…BData&dataID=95) welche in der Forumdatabase abgelegt ist?
Es gab da doch mal Probleme bzw. sind diese noch aktuell.
Danke.
Viele Grüße,
Sten
PS:
BS: winXP
RTT: 3.2.1
TWS API Version 9.60
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »sten« (13. Dezember 2013, 20:32)
Freitag, 13. Dezember 2013, 22:33
die aktuellste von IB (TWS 936 ? Mar 6 2013)
ich habe auf einem Rechner seit geraumer Zeit 940.4 im Einsatz. Die scheint bisher stabil im Bezug auf das Memoryallokationsproblem.
Zur Sicherheit einmal am Wochenende neu starten.
If you think it´s expensive to hire a professional, wait until you hire an amateur.
Samstag, 14. Dezember 2013, 22:27
Sollte man das zugehörige RTT-Tool zum IB-Gateway alle 24h neu starten lassen, oder kann man sich das jetzt auch sparen?
Ich lass es durchlaufen.
Restart jedes Wochenende, wo ich da in der Regel auch updates einspiele.
If you think it´s expensive to hire a professional, wait until you hire an amateur.
Ähnliche Themen
-
Datenbeschaffung »-
Datenpflege zerschiesst historische Kursreihen
(16. April 2008, 10:15)
-
- Formelsprache und Handelssystementwicklung »
-
trick zum rechenleistung sparen?
(30. März 2007, 09:23)
-
- Zusatztool Order Plus! »
-
Nach Investox-Absturz: Ordermodul kann sich nicht neu verbinden
(25. August 2006, 12:19)
-
- Zusatztool Order Plus! »
-
Tws /api
(19. Mai 2005, 11:23)
-
- Erweiterungs- und Verbesserungsvorschläge zu Investox »
-
Signal bei Abbruch der Datenverbindung
(19. Juni 2003, 11:27)