Was der Logbucheintrag bedeutet - Seite 4

Neuer Kommentar
 
Und ich habe OrderModify noch nicht überprüft :(
Und ausstehende Aufträge:((
 
Es ist also schon eine ganze Weile her, ein paar Tage. In dieser Zeit haben mehrere Experten ihre Arbeit getan. Hier sind die Protokolle (der Code, der diese Protokolle erzeugt, steht oben). Ich warte immer noch auf eine Antwort von den Entwicklern. Zumindest auf der Ebene von "wir erkennen das Problem an, lasst es uns beheben".

Protokoll 1:
Versuch zu kaufen, Versuch 0 fehlgeschlagen, Fehler 6
Versuch zu kaufen, Versuch 1 fehlgeschlagen, Fehler 129
Versuch zu kaufen, Versuch 2 fehlgeschlagen, Fehler 129
Versuch zu kaufen, Versuch 3 fehlgeschlagen, Fehler 129
Versuch zu kaufen, Versuch 4 fehlgeschlagen, Fehler 129
Zickzack-Kauffehler: 4050
2.28000000, 0.02700000, 0.00000000
Versuch zu kaufen, Versuch 0 fehlgeschlagen, Fehler 6
Versuch zu kaufen, Versuch 1 erfolgreich

Die Bestellung wurde beim 7. Versuch geöffnet. Auf dem Weg dorthin wurden mehrere Fehlermeldungen angezeigt, die nichts mit der Realität zu tun hatten.

Protokoll 2.
7.9.2005 11:0:15, Signal: verkaufen7.9.2005 11:0:15 Versuch zu verkaufen, Versuch 0.
Ask: 1,24820000, StopLoss: 0,00600000, TakeProfit: 0,00000000
fehlgeschlagen, Fehler 6
7.9.2005 11:0:15 Versucht zu verkaufen, Versuch 1.
Ask: 1,24820000, StopLoss: 0,00600000, TakeProfit: 0,00000000
erfolgreich

Beim zweiten Versuch. Fehler Nummer sechs war das Thema eines ganzen Zweigs mit mehr als hundert Beiträgen. Auf Anraten der Entwickler, Rosh und Composter, wurde die Fehlerhäufigkeit von "ab und zu" auf "etwa einmal in fünf" reduziert. Aber er ist immer noch da.

Protokoll 3.
Ich versuche, eine Long-Position zu schließen, Ticket: 1784257
6.9.2005 12:0:13 Auftrag mit diesem Ticket noch vorhanden, erneuter Versuch
6.9.2005 12:0:13 Auftrag mit diesem Ticket noch vorhanden, erneuter Versuch
6.9.2005 12:0:13 Auftrag mit diesem Ticket noch vorhanden, erneuter Versuch
6.9.2005 12:0:13 Auftrag mit diesem Ticket noch vorhanden, erneuter Versuch
6.9.2005 12:0:13 Auftrag mit diesem Ticket noch vorhanden, erneuter Versuch

Bei fünf Fehlversuchen gab es KEINEN Fehlercode. Das Programm dachte, diese Stelle sei geschlossen. Ich habe das Ticket in der Schleife aufgefangen, sonst wäre das Problem nicht entdeckt worden.

Und so weiter.
 
Mach es so
<br / translate="no"> void CloseBuy(string strExpertName)
{
int nTicket = OrderTicket();
SaveComment("\r\n\tVersuch, eine Long-Position zu schließen, Ticket: " + nTicket);

int nResult = OrderClose(OrderTicket(), OrderLots(), Bid, nSlip, Aqua);

Sleep(10000);

if(nResult == -1)
{
int nError = GetLastError();
Alert(strExpertName + ", Fehler: " + nError);
}

}


Ich musste ein Zitat verwenden, um den Text fett zu machen.
 
Wenn dies geschieht, wird der Fehler wahrscheinlich verdeckt. Und das Ziel ist es, den Entwicklern zu helfen, sie zu finden, damit alles ohne Schleifen funktioniert.

Der Sinn von Sleep ist es, einfach zu warten, bis der Zustand, der den Fehler verursacht hat, verschwunden ist (Sie wissen schon, die Pings gehen durch). Denn wenn man bedenkt, dass der Handel die Kontrolle "übernimmt" und sie nicht mehr loslässt, bis er zurückkommt, dann sollte ein Fehler sofort angezeigt werden. Wenn nicht, ist es ein Fehler.

Die einzige mögliche Ausnahme ist meine Schleife, die nach einem Ticket für eine gerade geschlossene Position sucht. Aber auch hier können wir darüber streiten, wie sich das System idealerweise verhalten sollte.

Auch hier besteht das Problem nicht nur darin, dass die Fehler RÜCKGELEITET werden, sondern auch darin, dass die Fehlercodes von der Obergrenze genommen werden, und manchmal gibt es überhaupt keine Codes - der Erfolgscode der Operation wird zurückgegeben.

Wenn ich etwas nicht verstehe, erklären Sie es bitte.
 
Erläuterung. Gemäß den Bedingungen eines Expert Advisors wird eine Reihe von Aktionen ausgeführt, wenn der aktuelle Ask-Kurs den Stop-Loss einer schwebenden Verkaufsorder überschreitet:
1. Es wird eine SMS verschickt, die über die Absicht informiert, einen solchen Auftrag zu löschen.
2. Es wird versucht, die Bestellung zu stornieren
3. Das Ergebnis der Funktion OrderDelete() wird analysiert, und wenn es negativ ist (der Auftrag wurde nicht entfernt), dann
4. Es sendet eine SMS zur Bestätigung des Fehlers.

Gestern haben wir 2 SMS bekommen, alles nach den Regeln, aber die Bestellung wurde in der gleichen Sekunde storniert, laut den Protokollen.
Der EA hat also versucht, das Ergebnis der Auftragsstornierung einige Sekundenbruchteile früher zu erhalten, als er das Ergebnis bekommen hat. Es ist wie in dem Witz über die Chinesen, die Kartoffeln pflanzten und sie am nächsten Tag wieder ausgruben. Auf die Frage: "Reift er so schnell?", antworteten sie: "Nein, aber er beißt" :)
 
Verstanden, ABER:
1. Ich habe diese ganze Aufregung um die tatsächlichen Bestellungen gemacht. Und wenn sie sich so verhalten, muss das behoben werden.
2) Die Idee ist, dass MT EAs in der Lage sein sollten, OHNE einen verzögerten Zyklus zu handeln. So sollte es sein.
Ich werde eine Verzögerung setzen, aber, wie man sagt, "ohne Vergnügen" :)
 
Ich habe bei mir selbst nachgedacht. Wenn ich vorschlage, eine Pause zwischen dem Vorgang der Auftragsänderung und der Überprüfung der Ergebnisse dieses Vorgangs einzulegen, bedeutet das, dass ich von einer asynchronen Arbeitsweise des EA ausgehe. Das bedeutet, dass wir eine Anfrage an den Server senden, um den Auftrag zu ändern, und dann, ohne auf die Antwort zu warten, setzt der Expert Advisor seine Arbeit gemäß dem Algorithmus fort. Standardmäßig erhält der Expert Advisor eine negative Antwort, bis er eine Antwort vom Server erhält. Wird die Antwort empfangen, handelt es sich um eine echte Antwort, andernfalls um eine virtuelle Antwort.

Ich glaube es selbst nicht, können die Entwickler erklären, wie falsch ich liege?
 
Es wurde ein Konsens erzielt. Aber ich habe eine Pause eingelegt - nur um sicherzugehen. Bevor die Verfügbarkeit eines Tickets für eine gerade abgeschlossene Bestellung geprüft wird, kann auf die Datenbank des Servers zugegriffen werden, die dann aktualisiert werden muss. Obwohl es falsch ist :)

Etwas peinlich ist die Tatsache, dass es von 37 Beiträgen in diesem Thread nur einen einzigen von den Entwicklern gibt...
 
Es ist ein wenig verwirrend, dass es in diesem Thread nur einen einzigen Beitrag eines Entwicklers in 37 gibt...

warum sich in eine bereits produktive Diskussion einmischen
 
warum sich in eine bereits produktive Diskussion einmischen

und hier sind die Produkte =)

Ich habe einige Tests durchgeführt. Ein Expert Advisor eröffnet und schließt eine Position (abwechselnd kaufen und verkaufen). Mindestpause zwischen allen Geschäften - 10 Sek.

Testzeit (durch Alpari): 02:00 - 09:30 (d.h. 7,5 Stunden)
OrderSend Versuche: 996
Erfolgreich*: 888
Fehler**: 108

* - Mit "erfolgreichem" Versuch meine ich folgendes: orderSend lieferte Ticket-Nr., GetLastError lieferte 0, offene Position erfolgreich ausgewählt orderselect.
** - Alle Fehler #148 "trade context is busy" - das ist, was Slava im nächsten Thread gefragt hat - "was, wenn wir die isTradeAllowed-Prüfung deaktivieren?". Die Fehler begannen um 07:16:46 und häufen sich immer noch)

-----------------------------------------------------------------------------------------------------------------------

OrderClose attempts: 890
Successful*: 736
Fehler**: 154

* - mit "erfolgreichem" Schließversuch meine ich folgendes: orderclose gab true zurück, GetLastError gab 0 zurück, geschlossene Position erfolgreich ausgewählt orderselect in mod_history.
** - 152 Fehler #1 "kein Fehler", einer #6 und einer #138(requotes)


Die Situation, die gefilmt wurde, ist nicht eingetreten. D.h. alle geschlossenen Positionen wurden tatsächlich geschlossen.
1234567
Neuer Kommentar
Grund der Beschwerde: