Hallo leute,
ich habe folgendes Problem, ich habe ein Messgerät, das die Sicherheit
von elektrischen Geräten prüft. Ich möchte mit einem C-Programm die
Ergebnisse an den Pc übertragen. Ich habe dieses Programm geschrieben.
Ich kann leider die Ergebnisse nicht richtig ausgeben, es kommen einfach
sinnlosen Zahlen. Wenn ich die Ergebnisse durch den Hyper-Terminal
ausgebe, sind diese ganz normal, da ist sogar Text dabei nicht nur
Zahlen.
Dein Messgerät schickt dir Text.
Du betrachtest gerade die ASCII Codes dieses Textes. Als Dezimalzahlen
ausgegeben können die ganz schön verwirrend sein
Ich habe es gestestet und es funktioniert, leider nicht richtig :(
Die Ausgabe sind sinnlosen ASCII Zeichnen, wie zum Beispiel Smilys.
Ich lade zwei Screenshots hoch, einen mit der Ausgabe auf dem
HyperTerminal(wie es richtig ist) und den anderen ich in der Console
bekomme.
Grüße
Skaos schrieb:
> mhh die Baudrate stimmt 9600. 9600 stelle ich in dem Hyperterminal.> Wenn ich mit dem DCB nichts mache :S, wie kann ich dann etwas machen??
BuildCommDCB(...)
SetCommState(...)
Hallo danke für die schnelle Antwort, ich habe mein Programm so geändert
leider bekomme ich immer noch eine falsche Ausgabe... Ich nuetze ich
BuildCommDCB(...) SetCommState(...) falsch, ich habe aber auf die msndn
Seite nicht wirklich vrstanden :(
Edwar Yupanqui schrieb:
> Hallo danke für die schnelle Antwort, ich habe mein Programm so geändert> leider bekomme ich immer noch eine falsche Ausgabe... Ich nuetze ich> BuildCommDCB(...) SetCommState(...) falsch, ich habe aber auf die msndn> Seite nicht wirklich vrstanden :(
Entschuldige, aber:
Wie wäre es mit Gehirn einschalten?
In der MSDN ist sogar ein vollständiges Beispiel!
> GetCommState(hPort, &dcb);> BuildCommDCB("9600,n,8,1", &dcb);
Und wo ist der SetCommState?
Set Comm State
so wie "Setzen der Kommunikationsparameter"
Du machst:
Hole die momentan eingestellten Get Comm State
Erzeuge die Werte für ... Build Comm DCB
aber du setzt sie nirgends. Du aktivierst sie nicht! Nur dadurch, dass
du einer Variabeln bei dir einen Wert zuweist, stellt sich doch nicht
die serielle Schnittstelle auf einen neuen Baudratenwert ein. Du musst
dem Betriebssystem schon sagen: "Schau her. So möchte ich das Ding
eingestellt haben" - Set Comm State
Ok danke für deine Hilfe.
Ich habe aber gerade entdeckt, dass das Programm ohne SetCommState
funkrtioniert. Ich muss es so ausgeben: printf("%c",buf[0]);
Warum geht das ohne SetCommState??
Wenn ich SetCommState nutze, wäre es so?
GetCommState(hPort, &dcb);
BuildCommDCB("9600,n,8,1", &dcb);
SetCommState(hPort, &dcb);
danke und tut mir leid für meine dummen Fragen
Edwar Yupanqui schrieb:
> Warum geht das ohne SetCommState??
Weil 9600, 8N1 zufällig die Standard-Einstellung ist. Kannst du auch
im Gerätemanager umstellen.
Dieser Code beschreibt eine MFC-Klasse. Einerseits ist das C++ (und kein
C), andererseits ist die MFC nicht mit der kostenlosen Visual Studio
Express-Variante nutzbar.
Richtig, aber die paar MFC-spezifischen Sachen kann man leicht ersetzen.
Es ging mir eher ums Prinzip, damit dem TE klar wird, die man die DCB
anwendet, die commstates setzt usw. und in welcher Reihenfolge das
passiert.
Christian R. schrieb:
> Hmm....stimmt, er gab sich sehr lernresistent. Naja, man soll die> Hoffnung nie aufgeben.
Danke für das Beispiel. Jetzt funktioniert mein Programm auch.
Ich das Programm getestet, da ichso eine Datenübertragung sehr
interessant finde.
Ich habe sogar ein paar SAchen ergänzt. Bei mir hat alles klapp, außer
dass ich von der Schleife nicht rauskomme. Weiß vielleicht wie man das
programmiert??
> Ich habe sogar ein paar SAchen ergänzt. Bei mir hat alles klapp, außer> dass ich von der Schleife nicht rauskomme. Weiß vielleicht wie man das> programmiert??
dafür musst du aber erstmal sagen, wann das programm aus der schleife
rauskommen soll. Bei Testendruck, bei einem zeichen was empfangen wird
order evnetuell nach 5min.
Das öffnen und schliesen der Datei würde ich nicht in der Schleife
machen.
Na ja.
Was stellst du dir den vor, wann hPort jemals NULL werden soll?
hPort wird nie von alleine NULL! Du hast den Port in Beschlag und
solange dein Programm läuft und du den seriellen Port nicht schliesst,
ist er deinem Programm zugeordnet.
Wenn deine Schleife laufen soll, solange ein Sender sendet, musst du mit
dem sendenden Programm etwas vereinbaren, woraus der Empfänger erkennen
kann: Das wars, ab jetzt kommen keine Daten mehr.
Wie du das machst: lass deine Phantasie spielen. Das kann sein, dass die
Gegenstelle ein bestimmtes Zeichen sendet. Das kann sein, dass die
Übertragung überhaupt nach einem Protokoll abgewickelt wird, das kann
sein, dass dein Programm in einen Timeout läuft. Irgendwas. Denk dir was
aus.
Karl heinz Buchegger schrieb:
> Wie du das machst: lass deine Phantasie spielen. Das kann sein, dass die> Gegenstelle ein bestimmtes Zeichen sendet. Das kann sein, dass die> Übertragung überhaupt nach einem Protokoll abgewickelt wird, das kann> sein, dass dein Programm in einen Timeout läuft. Irgendwas. Denk dir was> aus.
Danke für deine Hilfe, ich habe es geschafft ;). Gibts eventuell
Verbesserungsvorschläge???
Ich poste mein Programm, falls es vielleicht jemand interessiert.
Peter schrieb:
> Gibts eventuell Verbesserungsvorschläge???
Naja, da du sämtliche Fehler-Behandlung einfach mal weggelassen hast,
würde ich da mal ansetzen....
Peter schrieb:
> Gibts eventuell Verbesserungsvorschläge???
ja der gleiche wie oben schon einmal, nicht ständig die Datei
"Messung.txt" öffenen und schließen.
Den Schwachsinn
while (hPort!=0)
{
hast du immer noch drinnen
hPort ist ein Handle! Das ist eine Art Kennung, die dir vom
Betriebssystem gegeben wird und der dir exklusiven Zugang zum Gerät
'serielle Schnittstelle' gewährt. Mit dem Handle hast du das Gerät in
Beschlag, solange bis du CloseHandle aufrufst.
hPort KANN in deinem Programm niemals 0 werden!
Damit suggeriert diese Schleife etwas, was einfach nicht stimmt, weil
der Fall gar nicht eintreten kann!
> ja der gleiche wie oben schon einmal, nicht ständig die Datei> "Messung.txt" öffenen und schließen.
Das kann sogar sinnvoll sein. Wenn von der seriellen die Daten nur
tröpfchenweise kommen und man sicher gehen möchte, dass jedes
einkommende Datum sofort tatsächlich am File landet und nicht erst
vorher noch in einem Cache rumlungert. Sicher ein flush hätte es
wahrscheinlich auch getan aber im Falle eines Absturzes möchte ich mich
nicht unbedint darauf verlassen, das das Filesystem hinter mir
zusammenräumt.
Das komplette Fehlen jeglicher Fehlerbehandlung wiegt da sehr viel
schwerer. Und natürlich, dass der Code vor der Veröffentlichung erst mal
aufgeräumt werden sollte. Was da Includes und Variablen rumlungern, die
kein Mensch braucht ....
Karl heinz Buchegger schrieb:
> Sicher ein flush hätte es> wahrscheinlich auch getan aber im Falle eines Absturzes möchte ich mich> nicht unbedint darauf verlassen, das das Filesystem hinter mir> zusammenräumt.
aber beim öffnen und schliesen müssen mehr Änderrungen am Dateisystem
gemacht werden als beim flush, damit ist das risiko sogar höher das bei
einem Abstuzt etwas verloren geht.
Außerdem sollte man heute davon ausgehen das die Hardware und das
Betriebsystem richtig arbeiten. Wenn nur die Anwendung abstützt bleibt
das Dateisystem auf jeden fall ganz. Man müsste ja auch sonst eventuell
beachten das der Speicher defekt ist und eine Variable den Inhalt ändert
ohne das man etaws dafür kann.
Peter schrieb:
> Karl heinz Buchegger schrieb:>> Sicher ein flush hätte es>> wahrscheinlich auch getan aber im Falle eines Absturzes möchte ich mich>> nicht unbedint darauf verlassen, das das Filesystem hinter mir>> zusammenräumt.>> aber beim öffnen und schliesen müssen mehr Änderrungen am Dateisystem> gemacht werden als beim flush, damit ist das risiko sogar höher das bei> einem Abstuzt etwas verloren geht.> Außerdem sollte man heute davon ausgehen das die Hardware und das> Betriebsystem richtig arbeiten. Wenn nur die Anwendung abstützt bleibt> das Dateisystem auf jeden fall ganz. Man müsste ja auch sonst eventuell> beachten das der Speicher defekt ist und eine Variable den Inhalt ändert> ohne das man etaws dafür kann.
ICh hab's schon lang nicht mehr ausprobiert. Aber wie ist das mit
heutigen Windows-en. Früher war es so, das man eine Datei, die ein
Programm zu schreiben offen hatte, nicht auch noch gleichzeitig lesend
öffnen konnte. Existiert diese Restriktion noch?
(Von daher unter anderem auch die Angewohnheit eine Datei nur solange
wie unbedingt notwendig offen halten)
> Früher war es so, das man eine Datei, die ein> Programm zu schreiben offen hatte, nicht auch noch gleichzeitig lesend> öffnen konnte. Existiert diese Restriktion noch?
Unter den 32-Bit-Versionen von Windows war das noch nie so, da konnte
das Verhalten durch die Flags gesteuert werden, die der Funktion
CreateFile übergeben werden.
Vielen dank für eure Vorschläge,
Karl heinz Buchegger schrieb:
> Den Schwachsinn>> while (hPort!=0)> {>> hast du immer noch drinnen
ich hab jetzt ein boolsches Wert
while(schalter==true)
Christian R. schrieb:
> Naja, da du sämtliche Fehler-Behandlung einfach mal weggelassen hast,> würde ich da mal ansetzen....
Die Fehler-Behandlung habe ich gerade hinzugefügt
Vielen Dank nochmal für eure Hilfe