Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
ich versuche mit meiner Schaltung Kontakt aufzunehmen. Die Schaltung kommuniziert per RS232. Übertragen werden 5 Bytes Daten. Als Endezeichen kommt 0xC0 (=192). Soll Allerdings C0 selbst als Zahlenwert übertragen werden so wird anstatt eines C0 ein 0xDB und ein 0xDC Übertragen. Soll ein Zahlenwert 0xDB übertragen werden, so wird 0xDB und 0xDD.
Z.B. für 2 Datenpakete
sieht Data1= 0x05, Data2 0x10 dann 0x05 0x10 0xC0 aus
sieht Data1= 0x05, Data2 0xC0 dann 0x05 0xDB 0XDC 0xC0 aus
sieht Data1= 0x05, Data2 0xDB dann 0x05 0xDB 0XDD 0xC0 aus
Softwaremässig auf dem µC ist das für mich kein Problem, aber das jetzt in die LabVIEW Sprache zu übersetzen...
' schrieb:Als Endezeichen kommt 0xC0 (=192). Soll Allerdings C0 selbst als Zahlenwert übertragen werden so wird anstatt eines C0 ein 0xDB und ein 0xDC Übertragen. Soll ein Zahlenwert 0xDB übertragen werden, so wird 0xDB und 0xDD.
Probiers mal so:
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
25.12.2007, 16:13 (Dieser Beitrag wurde zuletzt bearbeitet: 25.12.2007 16:15 von maltejahn.)
Nur, wie funktioniert das "Rückwärts"?
Problem wo ich sehe ist, das die Länge dessen was über die Schnittstelle kommt nicht konstant ist. Das einzige was ich weiß ist, es sollen z.B. immer 2 Werte übertragen werden.
Es kommt also am PC an:
0x50 x060 0xC0
Sind aber beide Wertepakete 0xC0, so erhalte ich
0xDB 0xDC 0xDB 0xDC 0xC0
In dem Fall würden also 5 Hexwerte übertragen bei eigentlich nur 2 Werten + Endezeichen.
Zitat:Problem wo ich sehe ist, das die Länge dessen was über die Schnittstelle kommt nicht konstant ist.
Das ist aber kein Problem. (Wenn dann höchstens eine Aufgabe).
Es gibt zwei grundsätzliche Möglichkeiten.
Du arbeitest nach dem Frage/Antwort-Verfahren: zuerst sendest du eine quasi Anfrage, daraufhin sendet die Gegenseite eine Antwort. Dazwischen vergeht eine bestimmte Zeit, die sei z.B. 200ms. Du machst jetzt folgendes: Anfrage senden - 250(!)ms warten - VISA lesen: Ließ zuerst mittels des Propertys die Anzahl der Zeichen aus, die sich im Eingangspuffer befinden. Diese Anzahl gibst du auf das VISA-Read-VI. Den gelesenen String wandelst du in ein U8-Array (wegen der übersichticheren Weiterverarbeitung). Dieses Array verarbeitest du wie "vorwärts" - halt nur rückwärts.
Die zweite Möglichkeit ist ein kontinuierlicher Datenstrom von der Gegenseite in den PC. Das geht auch, ist aber etwas komplizierter. Das sag ich dir erst, wenn dem auch so ist.
Zitat:Ein Problem wareum ich momentan nicht weiterkomme ist u.a. weil LabVIEW beim Einlesen vom Rs232 abbricht:
Kannst du mal das VI, in dem dieser Fehler eintritt hier posten (oder ein Bild ebendieses Eigenschaftsknotens)?
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
ich versuche mit meiner Schaltung Kontakt aufzunehmen. Die Schaltung kommuniziert per RS232. Übertragen werden 5 Bytes Daten. Als Endezeichen kommt 0xC0 (=192). Soll Allerdings C0 selbst als Zahlenwert übertragen werden so wird anstatt eines C0 ein 0xDB und ein 0xDC Übertragen. Soll ein Zahlenwert 0xDB übertragen werden, so wird 0xDB und 0xDD.
Das ganze nennt sich SLIP protocoll: http://de.wikipedia.org/wiki/Serial_Line...t_Protocol
Z.B. für 2 Datenpakete
sieht Data1= 0x05, Data2 0x10 dann 0x05 0x10 0xC0 aus
sieht Data1= 0x05, Data2 0xC0 dann 0x05 0xDB 0XDC 0xC0 aus
sieht Data1= 0x05, Data2 0xDB dann 0x05 0xDB 0XDD 0xC0 aus
Softwaremässig auf dem µC ist das für mich kein Problem, aber das jetzt in die LabVIEW Sprache zu übersetzen...
(Code mal ausm Zitat entfernt..)
Als Anwender des Instrument Assistent bin ich jetzt etwas überfordert
Was mich bei Deiner Frage etwas wundert, ist das Du wohl zwar das SLIP nutzt, aber wohl dann kein TCP/IP darüber fährst.
Denn dann wäre eigentlich das Betriebsystem für den Aufbau der SLIP-Verbindung zuständig (slattach unter Linux, unter Windows keine Ahnung) und Du würdest unter LV nur mit den TCP/IP-VIs arbeiten und damit wäre man unabhängig ob der µC nu per RSR232+SLIP oder Ethernet angebunden wäre..
Du scheins vom SLIP also nur die Codierung zunutzen.
Gruß,
Robert
PS: im Wiki-Artikel steht explizit drinne, das SLIP keine Fehlererkennung/-korrektur macht. Dafür sind die Protokoller in den höheren Schichten zuständig..
Bitte Beachten:
Die obenstehenden Texteile können unter Umständen Sarkasmus und Ironie enthalten, für nicht erkannten Sarkasmus oder nicht erkannte Ironie wird keine Haftung übernommen.
N.B.: "Multiple exclamation marks, " he went on, shaking his head, "are a sure sign of a deseased mind." - Terry Pratchett
dann hole ich ein bisschen weiter aus.
Bei mir geht es nur um die Kommunikation zwischen PC <-> µC 1 <-> µC2. Die Hauptarbeit besteht zwischen der Kommunikation µC1 und µC2. µC 2 ist für die Ansteuerung eines Motors zuständig (und Erfassung der Daten wie Motorstrom etc. und ist selber nicht in der Lage noch die Regelung aufzunehmen) und µC 1 ist für die Regelung des µC2 und zur Kommunikation zur Aussenwelt (LabVIEW).
Natürlich könnte man alles in den µCs Mit ASCII erschlagen, das dürfte aber zu langsam gehen.
Momentan bin ich an dem Stand das die µCs untereinander per SLIP kommunizieren können. µC1 kommuniziert per SLIP mit dem PC und kann auch Befehle vom PC entgegennehmen - halt momentan nur per Hyperterminal.
Einen CRC Check zu implementieren wäre sicherlich wünschenswert, aber um sowas zu machen sollte ich es er hinbekommen das SLIP Protopoll zu "programmieren".
Vielleicht nochmal so
PC <-> RS232 <-> µC Regelung <-> RS232 <-> µC Motor
Sicher wäre es sinnvoller µC 1 und 2 durch einen einzelnen µC zu ersetzen, doch leider bin ich an diese Hardware gebunden
Für mich ist auch wichtig, das der Regler schnell arbeiten kann und die Daten schnell zum µC2 bekommt, deshalb ein möglichst schlankes Protokoll.
eigentlich wollte ich gerne, das es auch für einen kontinuierlichen Datenstrom geeignet ist
- endlos while(1) schleife immer ein Byte abholen vom RS232
- falls kein Endezeichen (0xC0) dann ab damit zum Daten Array
- falls ein 0xDB dann noch nichts ins Datenarray und erstmal auf das nächste Zeichen warten
- falls nun ein 0xDC, dann ein 0xCO zum Datenarray, falls es ein DD war dann ein 0xDB zum Datenarray
- solange bis ein 0xC0 Endezeichen kommt
- falls das Datenarray weniger Breit ist als gefordert, dann verwerfen
So würde ich das beschreiben. Werde mich nochmal morgen dranmachen.
Bzgl. meinem Problem mit der RS232 Schnittstelle, leider ist das Programm auf dem anderen Rechner. Kurz: Habe ein VISA Config aufgemacht, dem ganzen den Namen meiner seriellen Schnittstelle zugewiesen und eingestellt. Und dann ein Visa Read den gleichen Namen gegeben und das Ergebnis in ein Anzeigefeld geschrieben. Das komische war, das es prinzipiell zu gehen scheint (klick auf Play und es zeigt was aus meinem Datenstream an, bricht dann aber nach Empfang des ersten Bytes mit der Fehlermeldung ab)
' schrieb:eigentlich wollte ich gerne, das es auch für einen kontinuierlichen Datenstrom geeignet ist
Für alle, die's interessiert, hab ich erst mal die andere Methode angehängt.
Zitat:- endlos while(1) schleife immer ein Byte abholen vom RS232
- falls kein Endezeichen (0xC0) dann ab damit zum Daten Array
- falls ein 0xDB dann noch nichts ins Datenarray und erstmal auf das nächste Zeichen warten
- falls nun ein 0xDC, dann ein 0xCO zum Datenarray, falls es ein DD war dann ein 0xDB zum Datenarray
- solange bis ein 0xC0 Endezeichen kommt
Ja, so ungefähr.
Zitat:- falls das Datenarray weniger Breit ist als gefordert, dann verwerfen
Genau. Mist wird verworfen.
Zitat:Bzgl. meinem Problem mit der RS232 Schnittstelle,
Kannst du wenigstens sagen, was im Propertynode steht?
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
Ja, die RS232 Schnittstelle. Hab da etwas länger gesucht bis ich gemerkt habe das dieser blöde RS232 Adapter bei jedem einstecken eine neuen Comport belegt (zwischenzeitlich COm21)
/
RS232 Übertragung mit SLIP protokoll
