ReadEventData() failed: Error code 259

  • Hallo,


    der "Error Lockup" gibt für den Kode 259: "No more data is available. "!
    Das müssten Sie in Ihrem Programm entsprechend "handlen".

    F&S Elektronik Systeme GmbH
    As this is an international forum, please try to post in English.
    Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.

  • Danke für die Antwort, diese Information ist jedoch noch nicht ganz verständlich.
    Habe diese in msdn nachgelesen, jedoch was bedeutet das konkret?
    Bedeutet dies, dass keine weiteren Nachrichten aktuell vorhanden sind?


    Die Exception taucht nur auf, wenn keine Breakpoints gesetzt sind, bzw. keine Operationen im Receive Thread abgearbeitet werden. Anderfalls funktioniert die Applikation, aber es werden Unmengen von Nachrichten verworfen.
    Gibt es hierzu Daten zur Genauigkeit der NetDCU? Momentan sende ich von einem anderen Gerät alle 1-2 ms eine Nachricht. Somit verliere ich ungefähr die hälfte der Nachrichten, obwohl der Thread bevorzugt wird.


    Danke, MfG

  • Hallo,


    d.h. ganz einfach das keine Daten (oder nicht die geforderte Menge an Daten) in dem Puffer sind aus dem Sie lesen möchten. Das kann schon vorkommen. Ich weiß nicht wie Sie lesen, aber es ist möglich das bereits alle Daten "abgeholt" wurden und Sie lesen nochmal vor dem nächsten Dateneingang.

    F&S Elektronik Systeme GmbH
    As this is an international forum, please try to post in English.
    Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.

  • Sorry, hatte den Beitrag editiert,


    Quote


    Die Exception taucht nur auf, wenn keine Breakpoints gesetzt sind, bzw. keine Operationen im Receive Thread abgearbeitet werden. Anderfalls funktioniert die Applikation, aber es werden Unmengen von Nachrichten verworfen.
    Gibt es hierzu Daten zur Genauigkeit der NetDCU? Momentan sende ich von einem anderen Gerät alle 1-2 ms eine Nachricht. Somit verliere ich ungefähr die hälfte der Nachrichten, obwohl der Thread bevorzugt wird.


    Somit liegt das Problem darin, dass der Thread zu oft die Nachrichten abholen möchte, aber trotzdem werden laut dem Lost-Wert viel zu viele Nachrichten nicht empfangen.
    Was könnte der Lösungsansatz hierfür sein?

    Danke, MfG

  • Hallo,


    Quote

    Die Exception taucht nur auf, wenn keine Breakpoints gesetzt


    pollen Sie die Schnittstelle um Daten zulesen?
    Wenn Sie auf ein "ComEvent" warten (siehe Doku "WCE CAN Treiber") und dann erst lesen bis keine Daten mehr vorhanden sind solllte es besser funktionieren.



    Quote

    Anderfalls funktioniert die Applikation, aber es werden Unmengen von Nachrichten verworfen.
    Gibt es hierzu Daten zur Genauigkeit der NetDCU? ...


    Dazu kann man generell keine Aussagen machen. Es kommt natürch darauf was Sie "nebenbei" noch ausführen und wie die verscheidenen Prioritäten verteilt sind. Auch sollten Sie berücksichtigen das .NET Kode interpretiert werden muss und damit "langsamer" als C++ Kode ist (C++ Kode ist Echtzeitfähig, damit hatte ich auch bei 1000Nachrichten/s mit unveränderten Prioritäten keine Probleme).

    F&S Elektronik Systeme GmbH
    As this is an international forum, please try to post in English.
    Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.

  • Hallo!


    Bisher zeichne ich nur alle CAN-Nachrrichten auf, sprich nichts wirklich aufwendiges. Dies habe ich aber auch testweise deaktiviert. Auch dann werden teils bei 2000 empfangenen Nachrichten 4000 verloren.


    Der Thread liest ähnlich wie in dem Beispiel alle DataEvents in einer while-Schleife aus. Da ich Fehler 259 (ReadEventData() failed: Error code 259) bekommen würde, fange ich Exceptions mit einem Try/Catch Block ab. Diese Lösung ist alles andere als optimal, aber wie kann ich verhindern dass sonst die ReadEventData-Methode scheitert?


    sprich:


    Wie ist das CanEvent lost Attribut zu verstehen? Werden in diesem wirklich nur alle verlorenen Nachrichten zwischen der letzten und der aktuellen Nachricht angegeben?


    Danke,MfG


    edit:
    folgendes Problem wird ein Grund für die hohe Verlustrate sein: der Empfangspuffer wird erst nach und nach ausgeleert, somit sind auch Nachrichten vom vorherigen Versuch enthalten. Somit müsste man den Controller vor Messbeginn reseten. Leider fehlt mir hierzu der passende Befehl, da über Init() dies nicht funktioniert. Ebenfalls werden bei Listen_on / off und bei Enter_Standby Exceptions vor den CanPortExceptions geworfen. Somit bringt die Abfrage des Rückgabewertes nichts.


    z.B.


    if (pCAN.SetCommand(CanPort.CanCommand.ENTER_STANDBY) != 0)
    throw new CanPortException("CAN Error: Can't stop listen mode.");..



    => SetCOmmand() faild: Error code 87

  • Bei dem hier vorliegenden Treiber gibt es nicht in dem Sinne einen Empfangspuffer, sondern nur einen Event-Puffer. Empfangene Nachrichten sind somit nur *eine* Art von verschiedenen möglichen Events. Entsprechend erzeugt z.B. auch jede gesendete Nachricht einen Event, der im Eingangspuffer aufläuft. Zwar werden nur die Receive-Events als lost gezählt, aber alle anderen Events belegen trotzdem Platz. Und wenn der ganze restliche Eingangspuffer mit solchen Events gefüllt ist, passiert es schon mal schnell, dass eine regulär empfangene Nachricht keinen Platz mehr hat.


    Ich denke auch in Ihrem Beispiel ist der Sleep(0) ein gewisses Problem. Es scheint, dass in Ihrem CAN-System viele Nachrichten unterwegs sind. Wenn Sie da nach jedem empfangenen Event den Prozessor an andere Threads/Prozesse abgeben, die im Worst-Case ihre volle Zeitscheibe aufbrauchen, also immerhin 100ms mal Anzahl rechenbereiter Threads, dann kann es sehr schnell sein, dass der Event-Puffer vollläuft und Sie mit lesen nicht mehr hinterher kommen.


    Noch eine letzte Möglichkeit, die hier eine Optimierung bringen könnte: ein AcceptanceFilter. Durch Vorgabe einer solchen Maske werden nur noch die Nachrichten von der NetDCU empfangen, die auf dem CAN-Bus direkt an sie adressiert sind. Das kann ggf. die Menge der Nachrichten auch nochmal drastisch verringern.


    Mit freundlichen Grüßen,


    H. Keller

    F&S Elektronik Systeme GmbH
    As this is an international forum, please try to post in English.
    Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.