Kommunikation über serial port - Problem mit fprintf
Gast
Beiträge: ---
Anmeldedatum: ---
Wohnort: ---
Version: ---
Verfasst am: 29.04.2009, 22:16
Titel: Kommunikation über serial port - Problem mit fprintf
Hallo + schöne Grüße,
ich habe folgendes Problem:
Ich möchte ein externes Gerät (Tachymeter TCA2003) mittels Matlab von einem Laptop aus steuern.
Dazu schließe ich das Gerät mit einem RS232-USB-Kabel an den Laptop an und führe die folgenden Befehle in Matlab aus:
s = serial('COM3');
fopen(s);
s.Baudrate=9600;
s.DataBits=7;
s.StopBits=1;
s.Parity='even';
s.Terminator='CR/LF';
fprintf(s,'%GET/M/WI21/WI22');
data = fscanf(s)
fclose(s)
delete(s)
clear s
Öffnen (und Schließen) des Ports klappt gut, nur beim Senden der Daten ist Matlab einfach "busy" und nichts passiert. Entfernt man das Kabel vom Port, erscheint folgenden Fehlermeldung:
??? Error using ==> serial.fprintf at 144
An error occured during writing.
Ich weiß, dass die gesendeten Befehle und die Serial Port-Einstellungen korrekt sind, da ich sie mit Hyperterminal getestet habe (Einstellungen angehängt) und das Tachymeter wie erwartet reagierte.
Kann es sein, dass bei fprintf irgendein Fehler mit dem Terminator auftritt? (obwohl am Gerät eigentlich auch CR/LF eingestellt ist...)
Wäre für Hinweise dankbar!
settings hyper terminal.png
Beschreibung:
Einstellungen Hyperterminal: entsprechen denen in Matlab
Wird durch das Senden Deines fprintf- Befehls überhaupt der lineterminator erreicht?
Möglicherweise solltest Du an Deinen Befehl ein " \r\n " anhängen?
Nähers siehe Matlabhilfe zu fprintf.
lg
Martin
Gast
Beiträge: ---
Anmeldedatum: ---
Wohnort: ---
Version: ---
Verfasst am: 01.05.2009, 15:23
Titel:
laut Matlab-Hilfe wird bei fprintf default-mäßig ein \n an den zu sendenden String angehängt:
"Rules for Writing the Terminator
All occurrences of \n in cmd are replaced with the Terminator property value. Therefore, when using the default format %s\n, all commands written to the device will end with this property value. The terminator required by your device will be described in its documentation."
(Matlab-Hilfe zu serial.fprintf)
ich werd aber beide Vorschläge mal ausprobieren (Gerät ist leider erst ab montag wieder verfügbar), irgendworan muss es ja liegen, dass es nicht funktioniert
All occurrences of \n in cmd are replaced with the Terminator property value.
Alle "\n" werden durch den Wert in Terminator ersetzt.
Zitat:
Therefore, when using the default format %s\n, all commands written to the device will end with this property value.
Darum werden alle Kommandos, die im Standardformat ("%s\n" = string + "\n") gesendet werden, mit dem eingestellten Terminator-Zeichen enden.
So wie ich das lese, muss man den Terminator selbst senden und zwar durch "\n". Nur wird dann nicht "\n" gesendet, sondern der eingestellte Terminator. Wenn man kein "\n" sendet, wird auch der Teminator nicht gesetzt.
wenn du meinst, das Problem würde bei fprintf liegen, dann würde ich das mal alternativ mit fwrite probieren. Vermutlich liegt das doch am Öffnen der Schnittstelle - oder warum nimmst du an, dass dies funktioniert ? Bei mit geht die serielle prima, allerdings sieht mein Code auch ein klein wenig anders aus (Linux). Mit einem Fragezeichen werden vom Gerät 4000 Byte binäre Daten angefordert.
Bist du sicher dass es COM3 auf deinem System überhaupt gibt ? Ist die Einstellung von Hardware Handshake (RTS/CTS) korrekt bzw. in Benutzung? Kommt überhaupt ein Zeichen aus der Schnittselle raus? (mit Hyperterminal abhören) Fall nein, ist das ein zeichen dass fopen nicht funzt.
Gast
Beiträge: ---
Anmeldedatum: ---
Wohnort: ---
Version: ---
Verfasst am: 06.05.2009, 15:27
Titel:
Hallo Leute,
ich hab eure Vorschläge mal ausprobiert - hat leider wieder nicht geklappt.
@ janvi:
deinen Code hab (mit zusätzlichen Einstellungen wie z.B. DataBits für mein Gerät) auch erfolglos ausprobiert. Den ComPort gibt, er wird im Gerätemanager angezeigt.
Was Hyperterminal betrifft:
Ich kann die Kommandos mit Hyperterminal senden und es funktioniert. Was bei der Benutzung von Matlab gesendet wird, hab ich noch nicht getestet (brauch erst noch ein Null-Modem).
Also mein Code läuft hier genau so - allerdings unter Ubuntu. D.h. dev/tty müsste vermutlich gegen comxx ausgetauscht werden. Soviel ich gesehen habe, funktioniert der Schnittstellenzugriff über die JRE. Vielleicht wäre es eine gute Idee, mal die Java Version neu zu installieren.
Bei Matlab gibt es offensichtlich bezüglich der Schnittstellen öfters Ungereimtheiten. An meinem Ubuntu kann ich z. Bsp. vom Matlab Editor aus nicht drucken. Installierte Drucker werden angezeigt, aber mit Status: Es werden keine Jobs angenommen. Mit allen anderen Programmen auf dem gleichen System funktioniert da Drucken (TCP/IP) aber problemlos.
Du kannst mal folgenden Versuch starten: Die Schnittstelle mit Hyperterminal belegen und dann dein matlab Script starten. Da müsste dann eine Fehlermeldung kommen wenn dein matlab irgendwas mit der Schnittstelle schnallt.
Gast
Beiträge: ---
Anmeldedatum: ---
Wohnort: ---
Version: ---
Verfasst am: 07.05.2009, 19:12
Titel:
Ja, es erscheint (gar nicht mal unlogisch) folgende Fehlermeldung:
??? Error using ==> serial.fopen at 72
Cannot connect to the COM4 port. Possible reasons are another
application is connected to the port or the port does not exist.
Error in ==> openSerialPort at 7
fopen(s);
Hab heute auch mal ausprobiert, mit Matlab Daten über eine echte serielle Schnittstelle zu schicken:
Laptop mit seriellem Kabel und Null-Modem mit PC verbunden, am Laptop Matlab und am PC Hyperterminal benutzt.
Senden und Empfangen funktioniert in beiden Richtungen.
Ich denke, Matlab hat Probleme mit diesem speziellen USB-RS232 Adapter. Könnte die Verwendung eines anderen Kabels helfen?
also scheint der Zugriff mal prinzipiell schon zu gehen. Wenn du einen USB Adapter hast, brauchst du dich nicht wundern das nix geht. Die Teile sind ein ziemlicher Chinesen Sch....
Es gibt prinzipiell 2 Hersteller: Prolific aus Taiwan und die englische FTDI (Future Technology Device Inc). Prolific war insbesondere in der Anfangszeit ein absolutes Chaos das nur in idealen Sonderfällen überhaupt getan hat. Zwischenzeitlich hat Glyn den Support in D und wahrscheinlich haben die jetzt auch schon ein paar Hausaufgaben gemacht. FTDI war am Anfang auch kein Zuckerschlecken, hat sich aber seit USB2.0 verdammt gemausert. Einen solchen eigenen Treiber für USB Chip zu schreiben, ist eine mittlere Aufgabe wo man als Einzelperson nicht gewachsen ist. Die Referenz auf diesem Gebiet (um den Updates von Microsoft hinterherzuhecheln) ist Walter Oney. Vom Registrierungszwang bei Vista mal ganz abzusehen und Firmen wie etwa Logitech habe ganze Abteilungen damit beschäftigt was auch an den hohen Versionsnummern der Mäuse direkt abzulesen ist.
Also: Finde mal heraus, welchen Chip dein Kabel hat (aufschrauben oder im Gerätemanager im Treiber gucken) und installiere dir dann den neuesten Treiber von der Herstellerseite. Die mitgelieferten sind meistens uralt bzw. auch in der Funktion abgespeckt. Gemeint ist nicht der Hersteller des Kabels sonder der Hersteller des Chips welcher im Kabel verbaut ist. Nur das garantiert die Aktualität. Die Herstellerseiten haben auch Tools und FAQ um speziellen Problemen nachzugehen, was aber eher für Leute gedacht ist, die eigene Kabel mit den Chips entwickeln wollen. Nichtdestotrotz hilft das natürlich auch als Anwender bei einem möglichen Problem weil das Kabel ist fast immer genau das Standardapplikationsbeispiel im Datenblatt. Nur wenige Chinesen machen sich irgendwie was an Mühe etwas eigenes zu denken...
Gast
Beiträge: ---
Anmeldedatum: ---
Wohnort: ---
Version: ---
Verfasst am: 07.05.2009, 22:44
Titel:
also:
ist ein Chip von Prolific. Treiber ist vom 20.11.2007. Werd also neue Treiber laden und morgen ausprobieren (brauch ja auch Zugang zum Gerät)
Prolific au weia - das sind die ganz billigen Teile. Wenn ich mich recht erinnere, habe ich damit die DTR/DSR und CTS Hardware Handshake Leitungen nicht hingekriegt. Prüfe mal ob dein Gerät eine HW Handshake Leitung benutzt. Dies ist nicht der Fall, wenn es mit einem Kabel funktioniert, das nur die pins 2,3 und 5 angeschlossen hat. Falls HW Handshake benutzt, unbedingt mit einer Brücke befriedigen weil das über USB nicht gut geht.
Der Originale UART vom PC hat einen 10 Byte FIFO Puffer welcher über USB simuliert wird. Beim Prolific Treiber war damals zu beobachten, daß mehr Bytes gesammelt wurden bevor diese auf dem USB erschienen. Mit dem FTDI ging das, wurde aber bei häufigem Richtungswechsel arschlangsam bis immer der Timeout für einen Flush gekommen ist, so daß die Teile niemand wollte. Unter USB 2.0 dürfte sich das aber zwischenzeitlich gebessert haben.
Summa Summarum liegt das Problem nicht an printf und auch nicht an Matlab sondern du hast offensichtlich ein Problem mit Prolific.
Gast
Beiträge: ---
Anmeldedatum: ---
Wohnort: ---
Version: ---
Verfasst am: 08.05.2009, 20:44
Titel:
Hallo und danke erst mal für die kompetente Hilfe
hab mal neue Treiber von Prolific geladen und kann jetzt zumindest gut Befehle an das Gerät senden.
Die Antworten empfangen klappt nicht so ganz ... kann aber auch daran liegen, dass zwischen dem Messbefehl und der Abfrage der Messwerte zu wenig Zeit liegt. Leider ist das Gerät jetzt auch bis donnerstag erst mal anderweitig in Gebrauch.
Was deinen letzten Post angeht:
Da hast du mich jetzt abgehängt, wenn ich dich richtig verstehe, geht es dir darum, ob und wie die Kontrolle des Datenflusses passiert?!
Ich versuch trotzdem mal zu antworten:
Flußkontrolle müsste eigentlich völlig ausgeschaltet sein. Ist auch nicht nötig, weil sich die ganze Kommunikation folgendermaßen abspielt:
PC sendet Kommando an Gerät (entweder Steuerungskommando, Befehl zum Messen oder Abfrage von internen Einstellungen)
Gerät antwortet mit entsprechender ASCII-Zeichenkette
von sich aus sendet das Gerät nichts
Wie krieg ich denn raus, welche PIN's angeschlossen sind?
Du kannst Beiträge in dieses Forum schreiben. Du kannst auf Beiträge in diesem Forum antworten. Du kannst deine Beiträge in diesem Forum nicht bearbeiten. Du kannst deine Beiträge in diesem Forum nicht löschen. Du kannst an Umfragen in diesem Forum nicht mitmachen. Du kannst Dateien in diesem Forum posten Du kannst Dateien in diesem Forum herunterladen
MATLAB, Simulink, Stateflow, Handle Graphics, Real-Time Workshop, SimBiology, SimHydraulics, SimEvents, and xPC TargetBox are registered trademarks and The MathWorks, the L-shaped membrane logo, and Embedded MATLAB are trademarks of The MathWorks, Inc.
RSS