SerialPort.Write Programm Crash wegen Threat Ends (Polling)

  • VB.NET
  • .NET (FX) 4.0

Es gibt 8 Antworten in diesem Thema. Der letzte Beitrag () ist von steffenforever.

    SerialPort.Write Programm Crash wegen Threat Ends (Polling)

    verwendet wird : Visual Studio 2015 und .net 4.0

    Hallo,

    ich versuche nun schon eine ganze Weile das mein Programm nicht abstürzt sowie ich den Seriellen Stecker raus ziehe. Ich bin irgendwie zu blöd keine Ahnung, die Serielle Schnittstelle in vb.net macht graue Haare.

    Ich verwende wie überall empfohlen die BeginnInvoke Methote um die Daten in eine Textbox und Label etc. zu schreiben soweit klappt das auch.

    Zum Ablauf: ich sende aller 100ms einen String mit SerialPort1.Write zur SPS um den Status abzufragen. Die Rückmeldungen werden eingelesen und in der Form visualisiert. Wenn ich nun den Stecker ziehe bricht alles mit Thread Ende zusammen eine Wiederaufnahme der Kommunikation ist nicht mehr möglich das Programm stürzt ab oder muss neu gestartet werden.

    Wieso endet der Thread vom SerialPort1_DataReceived Event ständig. Ich verstehe die Zusammenhänge nicht. Es muss doch irgendwie möglich sein einfach weiter zu senden ohne das es Abstürze gibt, so das ich den Stecker einfach wieder anstecken kann und alles geht weiter.

    Hier die Fehlermeldung vom Kompiler :Ausnahme ausgelöst: "System.IO.IOException" in System.dll

    hier mal meine Kommunikationsparameter :

    Quellcode

    1. With SerialPort1
    2. .PortName = MetroComboBox1.Text
    3. .BaudRate = 115200
    4. .DataBits = 7
    5. .Parity = Parity.Even
    6. .StopBits = StopBits.One
    7. .Handshake = Handshake.None
    8. .Encoding = System.Text.Encoding.Default
    9. .DtrEnable = True
    10. .ReadTimeout = SerialPort.InfiniteTimeout
    11. .WriteTimeout = SerialPort.InfiniteTimeout
    12. .NewLine = vbCrLf
    13. End With






    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „steffenforever“ ()

    @steffenforever Deine Parameter sind nicht primär relevant für Dein Problem.
    Besser wäre es, wenn Du die DataReceived-Methode gepostet hättest.
    Wenn Du sicherstellen willst, dass das Herausziehen des Steckers das Programm nicht zum Absturz bringt, musst Du die Codezeilen in Erfahrung bringen, wo es crasht und darum ein Try / Catch machen.
    Und:
    Der Compiler meldet keine IOException, sondern die Runtime während des Debuggens. ;)
    Poste mal den betreffenden Code und dessen Umgebung und markiere die crashende Zeile.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Quellcode

    1. Private Sub SerialPort1_DataReceived(ByVal sender As System.Object, ByVal e As System.IO.Ports.SerialDataReceivedEventArgs) Handles SerialPort1.DataReceived
    2. ' Note this subroutine is executed on the serial port thread - not the UI thread.
    3. Try
    4. Do While comOpen AndAlso SerialPort1.BytesToRead > 0
    5. Me.BeginInvoke(New StringSubPointer(AddressOf DoUpdate), SerialPort1.ReadLine)
    6. Loop
    7. Catch ex As Exception
    8. ' MessageBox.Show(ex.Message & ex.StackTrace)
    9. End Try
    10. End Sub
    11. Public Sub DoUpdate(ByVal Buffer As String)
    12. '... Zuweisung zu Textbox und Controls
    13. End Sub



    Quellcode

    1. Private Sub Timer_Clock_Tick(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Timer1.Tick
    2. Try
    3. SerialPort1.Write(":04030000FF00609A" & vbCrLf) ----> Hier stürzt er immer ab
    4. Catch ex As Exception
    5. ' MessageBox.Show(ex.Message & "Zeilennummer: " & ex.StackTrace)
    6. End Try
    7. End Sub



    Ich habe das zyklische Schreiben auch schon ohne einen eigenen Timer ausprobiert geht auch nicht.

    Try / Catch
    hilft nicht Anwendung kann keine erneute Serielle Verbindung aufbauen.

    Deine Parameter sind nicht primär relevant für Dein Problem.
    Ich war mir nicht sicher ob es irgendwas mit ".DtrEnable = True" zu tun hat, deswegen habe ich die Parameter mal mit gepostet.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „steffenforever“ ()

    steffenforever schrieb:

    VB.NET-Quellcode

    1. .DataBits = 7
    sehe ich gerade, alle SPSse, die ich kenne, auch die von vor 25 Jahren, haben mit 8 Bit gearbeitet.
    Probier das mal aus.
    ====
    Ist Dein Port ühaupt geöffnet?

    VB.NET-Quellcode

    1. SerialPort1.Open()

    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „RodFromGermany“ ()

    7 Bit stimmen unter 8 Bit läuft gar nichts. Es ist eine Crouzet Millenium M3 SPS. Die Paramater habe ich so aus dem Datenblatt übernommen.

    Edit: Der Kommunikationsaufbau funktioniert ja eigentlich wunderbar. Es gibt immer nur Probleme wenn ich den Stecker bei aufgebauter Kommunikation abziehe, dann hagelt es "Ausnahme ausgelöst: "System.IO.IOException" in System.dll" wenn der SerialPort1.Write(":04030000FF00609A" & vbCrLf) Schreibbehl ausgeführt wird.

    Manchmal kann man den Stecker 2-3 mal abziehen und alles läuft weiter ohne Absturz, manchmal reicht es auch schon wenn man den Stecker nur 1x neu steckt.

    Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von „steffenforever“ ()

    @steffenforever OK.

    RodFromGermany schrieb:

    Ist Dein Port ühaupt geöffnet?

    VB.NET-Quellcode

    1. SerialPort1.Open()
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    Ich habe 2 Buttons im Programm "Verbinden" und "Trennen". Der Port bleibt solange geöffnet bis "Trennen" gedrückt wird oder die Form verlassen wird.
    Dadurch das ich alle 100ms die Rückmeldung der SPS anfordern möchte bleibt der Port immer offen.

    Sollte man den Comport evtl. in Abhängigkeit des SerialPort1_DataReceived Events zyklisch mit Öffnen und Schließen ?

    Edit :
    Ich habe den Quellcode oben etwas eingekürzt alle Abfragen sind immer in einer IF Bedingung zum ComPort.open


    Hier mal eine besser Fehlermeldung :

    Quellcode

    1. Ausnahme ausgelöst: "System.IO.IOException" in System.dll
    2. Der E/A-Vorgang wurde wegen eines Threadendes oder einer Anwendungsanforderung abgebrochen.
    3. Zeilennummer: bei System.IO.Ports.InternalResources.WinIOError(Int32 errorCode, String str)
    4. bei System.IO.Ports.SerialStream.EndWrite(IAsyncResult asyncResult)
    5. bei System.IO.Ports.SerialStream.Write(Byte[] array, Int32 offset, Int32 count, Int32 timeout)
    6. bei System.IO.Ports.SerialPort.Write(String text)
    7. bei WindowsApplication3.Form1.Timer_Clock_Tick(Object sender, EventArgs e) in C:\Users\..\Documents\Visual Studio 2015\Projects\WindowsApplikation3\Form1.vb:Zeile 982.
    8. Ausnahme ausgelöst: "System.IO.IOException" in System.dll


    Zeile 982 :

    Quellcode

    1. ​SerialPort1.Write(":04030000FF00609A" & vbCrLf)

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von „steffenforever“ ()

    Ich habe jetzt mal mein Programm mit den gleichen Parametern auf einem anderem Rechner mit physischer ComPort Schnittstelle probiert und dort funktioniert das Trennen und Verbinden.

    Offenbar liegt es an dem Serial to USB Converter !

    Das komische ist wenn ich ziehe nur den Seriellen Stecker und nicht den USB Stecker ab. Was kann ich nun tun um die Serielle Verbindung auch bei USB Adaptern zu halten ?
    So hier eine gute Erklärung zum Verhalten beim Abziehen von USB zu Serial Port Adaptern ... leider in Englisch : https://www.reddit.com/r/programming/comments/24yq5w/net_serialport_class_library_is_horrendous/

    Habe auch tausend Sachen ausprobiert aber der Programm Absturz lässt sich nicht vermeiden.

    Kann jemand eine alternative zur MS Variante empfehlen ?