Hi Leute, hat schon mal jemand beim Programmieren mit VB6 SP5 die Erfahrung gemacht, dass beim Schließen einer Form (eines Fensters), in dem Daten per RS232 ausgetauscht wurde, trotz ordnungsgemäßem Schließen des ComPorts eine '0' gesendet wird? Der Effekt tritt bei einigen Rechnern mit WIN XP SP2 auf, bei Anderen mit demselben OS nicht. Liegt das evtl. an der Hardware? Wäre prima wenn jemand was wüsste!
>gemacht, dass beim Schließen einer Form (eines Fensters), Was den nun, Form oder Fenster, oder vielleicht was anderes? >in dem Daten per RS232 ausgetauscht wurde, Wie soll ich mir das vorstellen? Das Formster sendet Daten an eine RS232 Schnittstelle, diese ist mit einer anderen RS232-Schnittstelle verbunden, welche ihre Daten wieder ans Formster sendet, so dass dieses mit sich selbst Daten austauschen kann? >trotz ordnungsgemäßem Schließen des ComPorts eine '0' gesendet wird? Welche Daten gesendet werden, ist unabhängig davon, ob das Schließen ordnungsgemäß durchgeführt wird. Denn beim Schließen ist der Datentransfer ja bereits erledigt. Stell dir mal vor, es gäbe keine '0' im Zeichensatz, na gut, könnte man durch den Buchstaben 'o' ersetzen, viele schreiben ja auch 2oo6 uns so. >Der Effekt tritt bei einigen Rechnern >mit WIN XP SP2 auf, bei Anderen mit demselben OS nicht. Das zeigt die hervorragende Fehlertoleranz von WIN XP SP2. Dank des selbstlernenden OS werden problematische RS232-Form-Fenster direkt mit der MS-Datenbank abgeglichen, so daß weitere Fenster-Daten-Austausche wieder problemlos funktionieren. Es ist also alles in Ordnung.
OK, war vielleicht 'n bischen oberflächlich. Ich tausche Daten per MSComm - Steuerelement in einer Form mit einem externen Gerät aus. Der Datenaustausch ist beendet. Ich schließe die Form (unload Me). An der RS232 (überwacht per Terminal an anderem Rechner) wird eine (dezimal, Hex) '0' empfangen. Es sollte eigentlich NICHTS gesendet werden, der Code enhält nichts was das auslösen könnte. Manche Rechner machen das, andere nicht, alle mit demselben OS. Mein Problem war, dass das Gerät, mit dem kommuniziert wird, durch das zuviel gesendete Byte einen unkontrollierten Zustand annimmt und sich nicht mehr ansprechen lässt.
btw: '0' bezeichnet üblicherweise die ASCII-Kodierung der Ziffer 0. Du meinst aber wohl das tatsächliche Null-Zeichen, das mit '\0', 0x0 oder einfach 0 (ohne '') geschrieben wird. Zu deinem Problem: Hat das Gerät keine Fehlererkennnung, um Übertragungsfehler zu bemerken und fehlerhafte/unvollständige Befehle zurückzuweisen? Vielleicht solltest du versuchen, das Protokoll robuster zu gestalten, wenn es über eine unzuverlässige Verbindung wie RS232 übertragen wird. Wenn dein Programm die RS232-Schnittstelle freigibt, gestattest du damit beliebigen anderen Programmen (Betriebssystem einschließlich) Zugriff darauf. Das heißt nach dem Schließen des Handles darf das Betriebssystem (AFAIK) ganz offiziell völlig beliebige Daten senden.
>Manche Rechner machen das, andere nicht, alle mit demselben OS. Hast du gelesen, was ich schrieb? Wenn XP solche Fehler bemerkt, versucht es, das Problem zu beheben. Darum kann ein anderes Gerät anschließend anders reagieren. >Mein Problem war, dass das Gerät, mit dem kommuniziert wird, durch das >zuviel gesendete Byte einen unkontrollierten Zustand annimmt und sich >nicht mehr ansprechen lässt. Wie du schreibst, ist das dein persönliches Problem. Ein Gerät, das durch einen Datenstrom in einen unkontrollierten Zustand versetzt werden kann, ist ein Sicherheitsrisiko. Den Fehler bei VB oder XP zu suchen, heißt die Ursache zu ignorieren, denn diese Produkte sind äußerst ausgereift und bestimmt nicht der Grund.
OK, das Gerät habe ich selbst gebaut und der Fehler (dass unkontrollierte Zustände auftreten können) ist mittlerweile 'raus. Das Ganze fiel aber erst nach 3 Jahren störungsfreiem Berieb auf, als der Rechner und das OS erneuert wurden. Mal abgesehen vom fehlerhaften Gerät das dranhing ist das meiner Meinung nach ein dicker Hund seitens Microsoft. Wenn ich nicht ausdrücklich sage dass Daten gesendet werden sollen erwarte ich auch, dass keine kommen! Die '0' hab' ich nur wegen der visualisierung so geschrieben, sorry, nächstes mal 0. @ MS-VB Certified Expert: wo liegt der Fehler wenn ich eine Form beende? Es besteht überhaupt kein Unterschied zu einem andern OS oder sonstwas. Da sollte auf der RS232 überall dasselbe passieren.
>Mal abgesehen vom fehlerhaften Gerät das dranhing ist das meiner Meinung >nach ein dicker Hund seitens Microsoft. Das ist schon ne üble Unterstellung. >@ MS-VB Certified Expert: >wo liegt der Fehler Wie bitte? Du benutzt ein fehlerhaftes Gerät und ein fehlerhaftes Programm und fragst mich, wo de Fehler liegt, ohne einen Schaltplan oder Quellcodeausschnitte zu zeigen? Du hattest ursprünglich gefragt, ob es evtl. an der Hardware liegt. Das ist ziemlich eindeutig der Fall. Und zwar an der Hardware, die deine Tastatur bedient.
>Du hattest ursprünglich gefragt, ob es evtl. an der Hardware liegt. Das >ist ziemlich eindeutig der Fall. Und zwar an der Hardware, die deine >Tastatur bedient. Nu mach mal halblang! Ich wollte nur wissen, ob jemand auch die Erfahrung gemacht hat, dass sich die serielle Schnittstelle selbstständig macht. >Das ist schon ne üble Unterstellung. Nee, ist Fakt. Codebeispiele hier zu posten macht wenig Sinn, das Teil (Datenlogger) ist mittlerweise recht umfangreich und Codeschnipsel würden niemand wirklich etwas sagen. Aber wenn jemand Bock hat, sich in 2 Jahre Arbeit von 3 Personen einzulesen mach' ich das schon. Wie gesagt: der Fehler ist 'raus! Wollte nur wissen warum XP selbstständig Bytes über RS232 ausgibt. Ich bedanke mich bei allen für die Antworten, scheint wirklich an Bill G. zu liegen. Bleibt nix anderes übrig als darauf zu reagieren.
Darf ich dich an deine Bemerkung erinnern: >OK, das Gerät habe ich selbst gebaut und der Fehler [...] >ist mittlerweile 'raus. Nun wiederholst du >Wie gesagt: der Fehler ist 'raus! Und schließlich >Wollte nur wissen warum XP selbstständig Bytes über RS232 ausgibt. Warum um alles auf der Welt willst du, nachdem du den Fehler an deinem Gerät behoben hast, nun XP in die Schuhe schieben, daß es den Fehler verursacht hätte? Da du außerdem behauptest, nicht in der Lage zu sein, die wesentlichen Angaben zu machen, die irgendwem eine Idee von deinem Problem vermitteln könnten, geselle ich dich jetzt einfach zu den anderen mir bekannten Trolls.
Nun gut, MS-VB Certified Expert, dann merk' ich mir halt deinen Nick und ignorier' die Postings, du bist echt keine Hilfe hier! NOCHMAL: ich wollte nur wissen, warum Windows selbsttätig die RS232 bedient. Scheinbar weiß das keiner. Ich klinke mich jedenfalls wegen der schlechten Stimmung hier aus. Gut's Nächtle!
>NOCHMAL: ich wollte nur wissen, warum Windows selbsttätig die RS232 >bedient. Scheinbar weiß das keiner. Weil das scheinbar eine unbegründete Behauptung deinerseits ist.
Sonic wrote: > Nun gut, MS-VB Certified Expert, dann merk' ich mir halt deinen Nick > und ignorier' die Postings, du bist echt keine Hilfe hier! > > NOCHMAL: ich wollte nur wissen, warum Windows selbsttätig die RS232 > bedient. Scheinbar weiß das keiner. Nicht wirklich. Ich hab ein ähnliches Problem mit der Parallelen. Nachdem sie freigegeben wird und Windows wieder die Kontrolle kriegt, pfriemelt es nach ca. 5 Sekunden an den Pins rum. Das kann ich noch verstehen, ist sein gutes Recht, schliesslich hab ich die Kontrolle über die Schnittstelle abgegeben. Ich denke mal, dass Windows nach einem möglichen Drucker sucht. Ev. ist das was ähnliches an der Seriellen.
MS-VB Certified Expert wrote: >>NOCHMAL: ich wollte nur wissen, warum Windows selbsttätig die RS232 >>bedient. Scheinbar weiß das keiner. > > Weil das scheinbar eine unbegründete Behauptung deinerseits ist. Ich kann mir nicht vorstellen, dass jemand der einen Portlogger an der Schnittstelle betreibt, nicht feststellen kann, wann genau auf der Schnittstelle ein Byte, dass er nicht gesendet hat, auftaucht.
So ist es, ich habe auch oben geschrieben, dass ich das mit einem Terminalprogramm mittels zweitem Rechner festgestellt habe. Es ist nun mal definitiv so, dass der eine Rechner die Null sendet, der Andere nicht. Könnte gut sein dass das mit Plug-and-play zu tun hat. Danke Karl Heinz, werde in der Richtung mal forschen. Vor 'nem Kunden steht man nach 3 Jahren störungsfreiem Betrieb natürlich blöd da!
Bill G. die Schuld an allem zu geben ist einfach, löst dein Problem aber nicht Ich denke du übersiehst einiges. 1. Möglichkeit: Du sendest noch während du die Form schließt. (Senden dauert ne weile) je nach Rechner geht das unterschiedlich schnell (das schliessen der Form) und damit siehst du auf der anderen Seite was oder nicht. potentielle Kandidaten zur suche sind alle Senderoutinen besonders in eventroutinen. Einfacher Test in der Form.Unload ? Routine als letztes 1 Sekunde warten. 2. Möglichkeit Die 0 die du bekommst, ist das ein Sendefehler oder wirklich ein Zeichen? Je nach Einstellung der dcb kann ein Sendefehler durch ein anderes Zeichen vorzugsweise 0 ersetzt werden. Test mit Oszi, seriellen Portlogger auf Senderseite oder "ordentlichem" Terminalprogramm z.B. Hterm auf Empfängerseite, das kann auch Fehler anzeigen. 3. Nochmalige Kontrolle aller Senderoutinen und Nachlesen in der MSDN und Microsoft Technet, im Internet findest du eine Menge Senderoutinen die äußerst fehlerhaft arbeiten, weil Leute nicht in der MSDN nachlesen oder es nicht verstehen. 4. Auf Sende und Empfangsseite das Handshaking überprüfen, nicht das hierdurch etwas blockiert wird und durch das "loslassen" des Ports diese blockierung sich löst. 5. Durch ein falsches Byte sollte ein Gerät niemals blockieren Das sind die Sachen die du erstmal selbst machen könntest 6. serielle Mäuse werden nur am Anfang getestet, schau mal nach Activesync etc. 7. möglicherweise Fehler oder Feature von Bill, aber es gilt 5. und auch auf die Gefahr hin das du dieses Posting auch ignorierst: MS-VB Certified Expert hat es vielleicht nicht sehr höflich ausgedrückt aber ich tippe auch darauf: zu 99% liegt der Fehler bei Dir.
Hm, ich habe drei Rechner nebeneinander stehen, alle dasselbe OS. Auf einem läuft zur Überwachung Hterm. Auf den zwei Anderen ist dieselbe SW installiert und deren Einstellungen sind identisch. Der eine Rechner schickt eine 0 (mit Hterm eingelesen) beim Schließen der Form, der Andere nicht. In der Form kann die Kommunikation schon 30 Minuten beendet sein, die 0 kommt trotzdem. Geöffnet ist die COM im Binary-Mode und nach der Kommunikation wieder geschlossen worden. Ich will hier nicht die Schuld auf Windows schieben, auch wenn's so rübergekommen ist. Ich wundere mich nur dass der eine Rechner anders reagiert als der Andere.
Du könntest auf den betreffenden Rechnern mal PortMon* von Sysinternals laufen lassen, vielleicht bringt das ja etwas Erleuchtung. *) http://www.microsoft.com/technet/sysinternals/utilities/portmon.mspx
>Hm, ich habe drei Rechner nebeneinander stehen, alle dasselbe OS.
Hast du auf allen drei die Festplatte formatiert, das OS installiert und
zur gleichen Zeit die gleichen Programme in gleicher Abfolge gestartet?
Es reicht aus, dass irgendein Prozess auf einem Rechner einmal auf die
serielle Schnittstelle zugreift, auf dem anderen aber nicht, damit sie
hinterher unterschiedlich konfiguriert sind. Wenn dein Programm dann
keine saubere Initialisierung vornimmt, verhalten sie sich eben
unterschiedlich.
Auch das ist kein Problem von Windows. Wer bestimmte
IO-Port-Eigenschaften braucht, muss diese halt setzen und nicht hoffen,
dass der Port zufällig so arbeitet, wie es den Gedanken des
Programmierers entspricht.
Ok jetzt kennt man den Versuchsaufbau, >In der Form kann die Kommunikation schon 30 Minuten >beendet sein, die 0 kommt trotzdem. Geöffnet ist die COM im Binary-Mode >und nach der Kommunikation wieder geschlossen worden unmittelbar nach der Kommunikation? so richtig Port.Close und unload des Moduls? Wenn dein Programm nicht sendet kannst du dann den COMPort mit einem anderen Programm öffnen? In HTerm Fehler anzeigen aktiviert? Was zeigt das Oszi?
Nunja, auf die restliche Konfiguration habe ich keinen Einfluss mehr, da es ein Kundenrechner ist. Wie gesagt, mittlerweile ist ein Blockieren des Gerätes nicht mehr möglich, wurde in der Firmware korrigiert und es läuft auch wieder wie's soll. Das Portmon schau' ich mir mal an, auch mit dem Oszi werd' ich mal rangehen, evtl. 'erleuchtet' mich das dann ;-) Erstaunlich ist halt, dass es drei Jahre lang keine Probleme gab, die tauchten erst mit XP SP2 und dem neuen Rechner auf. Vorher war's übrigens auch XP, aber ohne SP2. Ich werde jedenfalls weiterforschen, auch meine SW nochmal genauer unter die Lupe nehmen. Ich danke euch für die Beiträge und lass' es euch wissen wenn ich den Fehler gefunden habe!
@Wolfram: Ja, unmittelbar nach der Kommunikation mit .portopen=False. Kann grade leider nicht messen, habe das Oszi nicht zur Verfügung. Hterm Fehler Anzeigen hatte ich noch nicht aktiviert, werd's aber testen. der Port lässt sich nach der Kommunikation von anderen Programmen öffnen, ist ja schließlich geschlossen.
>Vorher war's übrigens auch XP, aber ohne SP2.
pruuust Und das nennst du das gleiche OS? Spätestens jetzt muss auch
ich gratulieren. In diesem Zusammenhang ist dir das Unmögliche gelungen:
du hast eine dumme Frage gestellt. Und auch gleich die Marke sehr hoch
angesetzt, Respekt!
>*pruuust*
Den ganzen Thread gelesen? Offensichtlich nicht!
BEVOR das Problem auftrat war's XP ohne SP2.
Bitte erst lesen bevor man anderen an den Karren fährt!
> Wenn dein Programm die RS232-Schnittstelle freigibt, gestattest du > damit beliebigen anderen Programmen (Betriebssystem einschließlich) > Zugriff darauf. Das heißt nach dem Schließen des Handles darf > das Betriebssystem (AFAIK) ganz offiziell völlig beliebige Daten > senden. Hast du diesen Absatz eigentlich gelesen? Der Fehler liegt ganz offensichtlich nicht auf der Seite von Windows. Wenn du willst, dass die Schnittstelle ruhig bleibt, muss dein Programm sie eben belegen. Das ist ja wie wenn du dich beschweren würdest "wenn ich einen Speicherblock mit free() freigebe, wie kann Windows dann einfach auf die Idee kommen darin rumzuschreiben? Bill ist daran Schuld, ganz klar!!1".
Ja, ist mir schon klar dass Windows dann drauf zugreifen darf. Nur frage ich mich eben: warum macht es das? Da sonst keine Applikationen laufen sollte eigentlich Ruhe herrschen, was bei den meisten Rechnern auch der Fall ist, die ich getestet habe (mittlerweile 12 Stück). Bei 3 von 12 Rechnern kommt die Null beim Schließen der Form, beim Rest ist Ruhe. Also kann's nicht an meinem Programm liegen, das habe ich nochmal durchgeforstet, beim Schließen ist die COM zu und in der 'Unload' - Funktion wird sie auch nicht mehr angesprochen. Sei's wie's ist: ich lebe damit.
> Ja, ist mir schon klar dass Windows dann drauf zugreifen darf. > Nur frage ich mich eben: warum macht es das? Ohne die Kompetenz dieses Forums in Frage stellen zu wollen schätze ich, dass du hier keine Antworten darauf erhalten wirst, die keine Mutmaßungen sind. Und zwar einfach aus dem Grund, weil das wohl nur ein Experte beantworten kann, der sich mit Windows-Treiberprogrammierung allgemein, bestimmten Treibern im speziellen usw. sehr gut auskennt. > Da sonst keine Applikationen laufen sollte eigentlich > Ruhe herrschen, [...] Eben das ist eine unzulässige Annahme. Wenn du die Schnittstelle freigst, hat Windows volles Anrecht darauf und kann machen, was es will.
>hat Windows volles Anrecht darauf und kann machen, was es will.
Hab' ich jetzt auch berücksichtigt. Die ext. Hardware ist so abgesichert
dass Windows das gerne machen kann.
Ich denke auch dass Windows und die Applikationen die drauf laufen
mittlerweile so komplex sind, dass man fast keine Chance mehr hat
solchen Sachen auf den Grund gehen zu können.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.