Suchergebnisse
Suchergebnisse 1-29 von insgesamt 29.
Hier erfahren Sie, wie einfach Sie Ihren Browser aktualisieren können.
-
Hallo, hab gesehen ein SerialPort hat eine BaseStream-Eigenschaft, jetzt hört sich das für mich so an als würden da die 0en und 1en drin stehen, die so ein SerialPort empfängt. Wie kann man da reingucken? Die Eigenschaft ist ein Stream, im Tutorial zu Streams steht man kann nur mit davon abgeleiteten Klassen arbeiten. Sammeln sich dadrin die Daten oder wann wird der aktualisiert? Viele Grüße
-
Ja das habe ich schon festgestellt. Aber Verständnis kommt bei mir da nicht auf. Deswegen sehr wackelig Habe zum Beispiel das hier, das funktioniert: (Versteckter Text) Wollte auch mal ohne DataReceived schauen, weil da läuft ja schon einiges. Und dann auch mal die Bits anschauen, ich weiß nicht was das StopBit ist, oder die Baudrate, oder der Handshake oder oder oder
-
Ok wenn BytesToRead > 0 und ReadExisting gibt mir den String aus. Ist ein Zeichen ein Byte? So kams bei mir jetzt zumindest hin. Bisher alles ohne DataReceived-Event. Aber was ist mit den anderer Methoden Read ReadToEnd. Was muss ich bei denen machen damit sie funktionieren? Liegt das am Zeilenende-Zeichen? Wird in den BaseStream nur etwas gefüllt, wenn ein Zeilenende erkannt wird? Das Zeilenende läuft doch bestimmt selbst auch in den BaseStream?
-
Also wenn ich per Button-Klick jetzt meinen Serialport abfrage mit BytesToRead, sagt er 0. Ok das verstehe ich. Jetzt schicke ich ihm ein Signal (das kann von der Gegenstelle ausgehend schon ein String sein?), dann ist BytesToRead nicht mehr 0. ReadExisting gibt mir dieses Signal und ChrW(26) das Eof Zeichen. Aber das Eof-Zeichen hat die Gegenstelle auch geschickt. Ist das soweit korrekt? Was ist wenn der Port kein ChrW(26) bekommt? Bleibt BytesToRead dann 0? Oder wird da endlos weitergelesen? D…
-
Mit "ihm" meinte ich den Serialport. Das Gerät ist nur passiv im Ablauf. Das kann meinetwegen sein was will. Hauptsache es gibt seriell lesbaren Strom aufs Kabel. Das sind aber immer Bytes hätte ich gedacht, gut wenn die Bytes als String konvertierbar sind dann sind das Strings, so meint ihr das oder? Also ich weiß nicht wie das EoF repräsentiert wird, aber sagen wir das ist ein volles Byte "11111111" Dann schickt die Gegenstelle etwas das mir BytesToRead = 1 gibt, dann wäre das bsp. "0101101011…
-
Tatsächlich wurde ja bereits die ReadToEnd und CopyTo Methode vorgeschlagen gleich zu Anfang, hab ich probiert, hat sich aufgehangen. Das hab ich soweit geschrieben .Read Methode hatte ich selbst auch probiert, hat sich auch aufgehangen. Dachte das wird das gleiche Problem sein, daher nicht mehr erwähnt. Dadurch sind wir hier gelandet. Weil ich gefragt hab was da wohl passieren mag. Also ReadExisting geht ja, kann es sein, dass man mit den Parameter bei .Read noch bestimmte Fälle abdecken muss? …
-
1. Ich mach nen ComPort ready, mit Baudrate etc. 2. Button.Click mal reingucken; prüft erst BytesToRead. Die sind 0 also nix da, super 3. Jetzt sendet die Gegenstelle 4. Button.Click wieder gucken, BytesToRead nicht 0 also geht er weiter, -mit ReadExisting, krieg ich genau das raus was ich soweit hier verstanden habe -mit allen anderen Methoden steppt der Debugger da rein und verschwindet. Das Programm reagiert nicht mehr. VB.NET-Quellcode (5 Zeilen) VB.NET-Quellcode (6 Zeilen)
-
Naja .Read sagte man mir ja sind die Bytes. Post 34 Dass die Methode die Anzahl der Bytes wiedergibt, macht für mich wenig Sinn, da Takafusa ja sagt die Anzahl der Bytes muss ich als Argument übergeben. Die Text-Eigenschaft ist ein String habs nur deswegen umgewandelt. Ich dachte der Integer wäre der Byte-Wert im Dezimalsystem Meinetwegen auch so, wo ichs mir angucke ist in diesem Fall ja egal. Ich geh mal schwer davon aus der Buffer darf ruhig größer sein? Angenommen da kommen ne ganze Menge an…
-
Zitat von Naifu: „die stehen eben in deinem Buffer b()“ Das hier wusste ich zum Beispiel nicht. Dann macht das auch Sinn mit dem Offset. Und die Read-Methode füllt den Buffer dann. Ich dachte der Buffer hilft nur beim Auslesen Dann hätte ich noch eine Frage zum ReadExisting. Da steht in der Doku "liest alle Bytes im Stream und im Eingabepuffer des SerialPort". Wann stehen denn die Daten im Eingabepuffer und wann im Stream?
-
@Naifu Mich interessierts, weil ich nicht weiß was der Eingabepuffers eines Serialports ist und was der BaseStream. Da mindestens eins von diesen Wörtern in jeder Beschreibung vorkommt in der Microsoft Doku des Serialports, die du auch verlinkt hast, wäre das schon relevant denke ich sonst kann ich da doch nichts mit anfangen.
-
SerialPort Jede Methode benutzt diese Begriffe in der Erklärung. ReadExisting benutzt beide wie oben zitiert Post 47 Dort ist folgender Hinweis zu finden: "The SerialPort class buffers data, but the stream object contained in the SerialPort.BaseStream property does not. Therefore, the SerialPort object and the stream object might differ on the number of bytes that are available to read. When bytes are buffered to the SerialPort object, the BytesToRead property includes these bytes in its value; …
-
Habe hier einen Beispielcode der etwas tut was ich nicht verstehe. Ich versuche so stumpf wie möglich den Input(gescannter Barcode) zu lesen. VB.NET-Quellcode (8 Zeilen) Nach zweimal den gleichen Barcode scannen steht in der Ausgabe: Quellcode (4 Zeilen) Also BytesToRead wird weniger beim zweiten Mal, aber im Array b steht weiterhin dasselbe und vor allem mehr Bytes als BytesToRead sagt.
-
Danke euch, ich kann noch nicht ganz aufdröseln was genau der Unterschied zwischen den Scans ist. Nach dem ersten Event macht er da denn irgendwas mit dem ReceivedBytesThreshold? Was heißt mein Array ist zu groß, macht das Probleme? Oder meinst du nur das sollte b(SP1.BytesToRead - 1) sein? Ich denke daher kommt die 0 dann am Ende. Ich hab es so verstanden die Puffergröße ist nicht so relevant, solange sie klein ist. Kann das auch dieses Problem verursachen? Ich werde es nochmal versuchen morgen…
-
Also nochmal bitte zum Verständnis, ReadExisting funktioniert bedingt. VB.NET-Quellcode (13 Zeilen) Aber ohne BytesToRead Abfrage wieder Käse (entspricht Post 55 und das meinte ich das hätte ich versucht, nur komisch dass es mit BytesToRead funktioniert): VB.NET-Quellcode (12 Zeilen) Der liest da einfach den Code in zwei getrennten Abschnitten beim zweiten Scan. In der Exe macht er natürlich nur den Murks, da gibts ja keine Debugger-Ausgabe Das hier funktioniert in der exe da gibt es ein zeitlic…
-
Na am liebsten würde ich natürlich beides nicht benutzen. Aber ich weiß halt nicht was da abgeht. Task.Wait benötigt einen expliziten Task, den ich warten lassen kann, ich weiß nicht recht was ich da basteln soll. Ich hab es mit Async Await probiert aber das verträgt sich nicht, da liest er nichts mehr aus. Also nochmal vielleicht habe ich das etwas missverständlich formuliert: Wenn ich den zweiten Scan mache, dann spuckt er das Ergebnis in zwei Teilen aus. Wenn ich Debug.Writeline(BytesToRead) …
-
Ich kann ein beliebiges Prefix und Suffix (Das ist dann das Zeilenende, wenn man möchte oder ein beliebiger Zusatz im Scan) anfügen, ja (sogar mehrere). Naja beliebig mag ich nicht ganz sagen, ich bin auch noch nicht ganz durchgestiegen, da scheinen manche Zeichen zu fehlen oder die Formatierung der Tabelle ist einfach kaputt. Mit dem Hex Wert wirds eingestellt. (Versteckter Text) aus der Honeywell Anleitung.