Hallo liebes Java-Forum!
Zurzeit arbeite ich an einem Programm, das über einen Comm-Port in hoher Frequenz Anfragen an eine Hardware sendet und anschließend die jeweilige Antwort auswertet. Außerdem wird dem User eine GUI angezeigt, die auf gewissen Hardware-Input reagiert.
Meine bisherige Lösung sieht so aus, dass ein erster Thread nach der richtigen Hardware sucht (Ports auflisten, öffnen, init-Nachricht senden, auf vereinbarte Nachricht warten) und den so gefundenen Port sowie Output- und Inputstream in Klassenvariablen speichert. Der Port wird also nicht wieder geschlossen. Außerdem zeigt er durch das Ändern einer Klassenvariable im letzten Aufruf der run()-Methode ggf. die erfolgreiche Kontaktaufnahme mit der Hardware an.
Ein zweiter Thread (javax.swing.Timer) läuft parallel dazu. Ist die o.g. Variable im Ursprungszustand, tut er nichts, wird die Verbindung zur Hardware signalisiert legt er los und sendet in 10ms-Intervallen verschiedene Anfragen an die Hardware und verarbeitet die Antworten mithilfe eines SerialPortEventListeners.
Das ganze Verfahren wurde noch nicht getestet.
Nun habe ich allerdings Bedenken, da der gefundene Port zur Kommunikation einmal geöffnet wird (vom ersten Thread) und danach nie wieder geschlossen. Meiner Meinung nach gibt es zwei problematische Szenarien, zu denen ich jeweils einige Fragen habe:
1) Das Programm wird beendet (Absturz, Benutzer schließt Fenster). Da ja nie ein close()-Befehl aufgerufen wird, ist der Port natürlich noch geöffnet. Hat das negative Folgen?
2) Das Programm läuft und die Hardware wird entfernt oder ausgeschaltet.
Was passiert, wenn die Hardware vom PC getrennt wird? Meldet das Programm sofort etwas oder wird erst eine IOException bei write/read-Operationen auf die Output/Input-Streams geworfen? Oder geschieht nicht einmal das?
In der Anwendung dieser Hardware könnte das zweite Szenrio im Notfall vernachlässigt werden (es zieht einfach niemand den Stecker, wenn das Programm läuft), schön wäre es natürlich trotzdem nicht.
Sollte das bisherige Design (Port einmal öffnen und dann regelmäßig write/read-Operationen ausführen) nicht geeignet sein, was sind dann Alternativen? Ist es sinnvoll, den Port nach jeder write/read-Operation wieder zu schließen und bei Bedarf wieder zu öffnen? Ist das in einem 10-100ms Takt überhaupt möglich?
Wie immer bin ich dankbar für jegliche Anmerkungen und Vorschläge. Schonmal Danke für's Lesen!
Viele Grüße,
lyrichter
Zurzeit arbeite ich an einem Programm, das über einen Comm-Port in hoher Frequenz Anfragen an eine Hardware sendet und anschließend die jeweilige Antwort auswertet. Außerdem wird dem User eine GUI angezeigt, die auf gewissen Hardware-Input reagiert.
Meine bisherige Lösung sieht so aus, dass ein erster Thread nach der richtigen Hardware sucht (Ports auflisten, öffnen, init-Nachricht senden, auf vereinbarte Nachricht warten) und den so gefundenen Port sowie Output- und Inputstream in Klassenvariablen speichert. Der Port wird also nicht wieder geschlossen. Außerdem zeigt er durch das Ändern einer Klassenvariable im letzten Aufruf der run()-Methode ggf. die erfolgreiche Kontaktaufnahme mit der Hardware an.
Ein zweiter Thread (javax.swing.Timer) läuft parallel dazu. Ist die o.g. Variable im Ursprungszustand, tut er nichts, wird die Verbindung zur Hardware signalisiert legt er los und sendet in 10ms-Intervallen verschiedene Anfragen an die Hardware und verarbeitet die Antworten mithilfe eines SerialPortEventListeners.
Das ganze Verfahren wurde noch nicht getestet.
Nun habe ich allerdings Bedenken, da der gefundene Port zur Kommunikation einmal geöffnet wird (vom ersten Thread) und danach nie wieder geschlossen. Meiner Meinung nach gibt es zwei problematische Szenarien, zu denen ich jeweils einige Fragen habe:
1) Das Programm wird beendet (Absturz, Benutzer schließt Fenster). Da ja nie ein close()-Befehl aufgerufen wird, ist der Port natürlich noch geöffnet. Hat das negative Folgen?
2) Das Programm läuft und die Hardware wird entfernt oder ausgeschaltet.
Was passiert, wenn die Hardware vom PC getrennt wird? Meldet das Programm sofort etwas oder wird erst eine IOException bei write/read-Operationen auf die Output/Input-Streams geworfen? Oder geschieht nicht einmal das?
In der Anwendung dieser Hardware könnte das zweite Szenrio im Notfall vernachlässigt werden (es zieht einfach niemand den Stecker, wenn das Programm läuft), schön wäre es natürlich trotzdem nicht.
Sollte das bisherige Design (Port einmal öffnen und dann regelmäßig write/read-Operationen ausführen) nicht geeignet sein, was sind dann Alternativen? Ist es sinnvoll, den Port nach jeder write/read-Operation wieder zu schließen und bei Bedarf wieder zu öffnen? Ist das in einem 10-100ms Takt überhaupt möglich?
Wie immer bin ich dankbar für jegliche Anmerkungen und Vorschläge. Schonmal Danke für's Lesen!
Viele Grüße,
lyrichter
Zuletzt bearbeitet:
