Windows und .NET auf Echtzeitkernel: Problem bei Kommunikation über RS232
Hallo,
ich suche nach Erfahrungen zu einer speziellen Laufzeitumgebung.
Mein Softwarepaket (Client-Server-Applikation) ist ursprünglich für eine Standard-Windows-Umgebung auf Basis .NET konzipiert und läuft dort auch (im Haus und bei Kunden) ohne größere Probleme.
Die Clients sind verschiedenartige Bedienprogramme für externe Geräte, die Serveranwendung übernimmt die Kommunikation zu diesen Geräten über verschiedene Schnittstellen (beispielsweise über RS232)
Jetzt habe ich allerdings eine abweichende Laufzeitumgebung vorliegen. Es handelt sich im einen PC mit Echtzeitkernel (CoDeSys), auf den ein Windows 7 mit .NET 4 aufgesetzt ist. Schnittstelle ist RS232.
In dieser Konstellation habe ich massive Probleme, die sich darin äußern, dass die Clientanwendung einfach "hängenbleibt" und in den Zustand "not responding" verfällt. Es sieht aus, als hätte sich der Windows-Scheduler innerhald ber Anwenung "verabschiedet". Die Serveranwendung hingegen läuft zuverlässig weiter und kommuniziert fehlerfrei über RS232.
Wird die Serverapplikation alternativ in einem OFFLINE-Modus gestartet, also ohne Kommunikation über RS232, laufen die Clients problemlos.
Gibt es hier Erfahrungen bzgl. WIndows und .NET auf Echtzeitkernel? Erfahrungen bzgl. der Schnittstellenbehandlung unter diesen Umständen? Erfahrungen bzgl. eventueller Schaduler-Anomalien? Ich bin für jeden Hinweis dankbar.
Gruß
Christel
Es ist schlimm, eine Ausnahme zu sein, aber noch schlimmer, keine zu sein.
Hi,
eine ähnliche Konstellation (allerdings kein CodeSys) hatte ich auch schon ohne Probleme laufen.
Hast du mal probiert deine Echthzeitumgebung durch eine Simulation auszutauschen und dem Client Programm so Kommunikation vorzugaukeln - einfach um debuggen zu können bei welcher Kommunikation das passiert?
Hallo,
naja, mein OFFLINE-Modus macht genau das. Falls ich Deinen Vorschlag richtig verstehe. Zur Erklärung:
Im realen RS232-Modus werden Werte durch die Serveranwendung über die RS232 in das externe Gerät geschrieben oder von dort gelesen.
Im OFFLINE-Modus simuliert die Serveranwendung die RS232-Kommunikation, indem die Werte beim Schreiben intern gespeichert und beim Lesen von dort zurückgegeben werden. Die Anwendung gaugelt dem Client die Kommunikation nur vor.
Der Rest des Softwarepaketes arbeitet für beide Modi absolut identisch.
Und ja, im OFFLINE-Modus funktioniert alles super, problemlos und absolut zuverlässig. Kommt die wahre Schnittstelle ins Spiel, funktioniert zwar die direkte Kommunikation über die RS232 (mit einem Monitortool überprüft), aber der Client macht die Hufe hoch.
Danke,
Christel
Es ist schlimm, eine Ausnahme zu sein, aber noch schlimmer, keine zu sein.
Hallo,
es gibt ein Update:
Das Verhalten hat offensichtlich mit der Belastung der Serveranwendung durch Kommunikationsaufgaben zu tun. Diese Belastung lässt sich verringern durch
- Heraufsetzen der Baudrate (57600 statt 9600)
- Minimieren der Kommunikationshäufigkeit
Beide Ansätze führen dazu, dass die Clientsoftware problemlos läuft.
Leider sind sie nicht praktisch umsetzbar, für die Kundenapplikation nicht praktikabel.
Was leider keine Verbesserung bringt, ist die Modifikation der Prioritäten im Taskmanager, also Server mit niedriger Priorität und Client mit hoher Priorität.
Hat auf Basis dieser Details noch jemand nen Tipp für mich?
Besten Dank
Christel
Es ist schlimm, eine Ausnahme zu sein, aber noch schlimmer, keine zu sein.
Das klingt ehrlich gesagt eher danach, als würde sich die Clientsoftware in ihrer Empfangsroutine verhaspeln, wenn sie mit echten Daten gefüttert wird.
Dafür spricht aus meiner Sicht auch, dass eine Baudratenänderung hilft.
Du könntest, mit einer geeigneten Hardware einmal die Kommunikation auf dem RS232 aufzeichnen und als Simulation gegen den Clienten abspielen (sofern das implementierte Protokoll das hergibt und nicht alles durcheinander bringt) oder die Aufzeichnung gegen die Simulation gegenprüfen.
Hallo,
den Datenverkehr über die RS232 erledigt komplett die Serveranwendung, diese läuft auch kontinuierlich und ohne Aussetzer weiter, konnte ich mitloggen. Der Client (der ja hängenbleibt) empfängt die Daten, indem er sich diese zyklisch aus dem Server abholt und per Event an die einzelnen Controls verteilt.
Im Simulationsmodus funzt alles super, der Server hat nicht viel zu tun und der Client läuft nebenher ohne Aussetzer. Der Kommunikationsmechanismus zwischen beiden ist übrigens identisch für Simulation und echtem Datenaustausch. Der Client weiß nichts vom Simulationsmodus oder allgemein von der Art der Kommunikation, das ist sauber getrennt.
Folgende neue Erkenntnis gibt es:
Der Client inkl. GUI geht ja in den Zustand "not responding". Dieser Zustand lässt sich beenden, indem man mit der rechten Maustaste auf irgendein Symbol in der Taskleiste klickt und dann die Maus in das sich öffnende Popup bewegt, ohne einen Click auszuführen.
Der Effekt tritt nur auf manchen SingleCore Prozessoren auf, bei MultiCore Prozessoren nie.
Es sieht aus, als würde der Windows Scheduler den Prozess ignorieren und bräuchte nur einen Anstoß ... höchst mysteriös.
Danke
Christel
Es ist schlimm, eine Ausnahme zu sein, aber noch schlimmer, keine zu sein.