Important announcement: there is an English version of this forum on
Datum:
Hallo und guten Abend, wie der Titel schon sagt suche ich nach einer Möglichkeit via Octave (QTOctave unter Windows, da es der Matlabumgebung recht ähnlich ist) auf die serielle Schnittstelle oder auch auf eine USB-Schnittstelle zuzugreifen. Für Matlab steht da die serial.m zur Verfügung, nicht jedoch in Octave. Das Internet habe ich schon durchsucht, bin bei einer Lösung bisher jedoch nicht fündig geworden. Einziger Hinweis bisher war dieser hier: https://www-old.cae.wisc.edu/pipermail/help-octave... jedoch ist dieses ominöse Programm net2com nirgends zu finden. Die Projektseiten sind leer gefegt, im Download-Bereich steht nichts mehr zur Verfügung. Hat da jemand eine Idee wie man das angehen kann? Für Hinweise wäre ich euch sehr dankbar. Vielleicht hat ja jemand eine Implementierung für Windows? branadic
Datum:
Hallo, ich hab die letzten Tage weiter das Netz durchforstet, bin aber bisher noch immer nicht fündig geworden. Hat niemand eine Idee oder nutzt Octave schlichtweg niemand? brandic
Datum:
> Hat niemand eine Idee oder nutzt > Octave schlichtweg niemand? Ich benutze Octave eigentlich sogar ziemlich häufig, aber für dein spezielles Problem habe ich leider auch noch keine Lösung gefunden. Einige Male habe ich genau diese Funktion aber auch schon vermisst. :( Hast du mal probiert, auf "COMx" per Dateizugriff zu lesen/zu schreiben?
Datum:
Hallo Ronny, Ronny schrieb: > Hast du mal probiert, auf "COMx" per Dateizugriff zu lesen/zu schreiben? Um genau zu sein wüsst ich nicht mal wie ich das veranstalten sollte. Für Linux habe ich folgenden Ansatz gefunden: f = fopen ("/dev/ttySL0", "r+") f = { id = 3 name = /dev/ttySL0 mode = r+b arch = ieee_little_endian status = open } fcntl (f, F_SETFL, O_NONBLOCK) ans = 0 fputs (f, "AT\n") ans = 0 fgetl (f) ans = AT fgetl (f) ans = fgetl (f) ans = OK fgetl (f) ans = -1 fputs (f, "AT\r") ans = -1 fclear (f) fputs (f, "AT\r") ans = 0 fgetl (f) ans = AT fgetl (f) ans = OK fgetl (f) ans = -1 fclose (f) ans = 0 Quelle: http://octave.1599824.n4.nabble.com/fgetl-hangs-re... Ich nutze jedoch Windows, also müsste man den Zugriff auf den COM-Port irgendwie anders gestalten. Der direkte Zugriff auf die serielle Schnittstelle soll aber nicht so trivial sein wie unter Linux. Da ich nicht gerade mit übermäßigen Programmierkenntnissen ausgestattet bin tu ich mich da zugegebenermaßen schwer. Hast du eine Idee? Ich lade mir gerade die letzte Octave Version herunter, das QT-Interface habe ich schon. Die graphische Umgebung ist dann doch irgendwie gewohnter, wenn man Matlab auf Arbeit nutzen kann. branadic
Datum:
So, ich hab jetzt mal den ersten Versuch vorgenommen auf eine meiner vorhandenen COM-Schnittstellen zuzugreifen. Dazu habe ich an einen meiner USB-Anschlüsse das FT232-Board von Sparkfun.com und an einen anderen einen Seriell-USB-Umsetzer von Vivanco gehängt. Der Gerätemanager verrät die COM-Port-Bezeichnung. Nun wähle ich entsprechend der Vorgabe: [fid, msg] = fopen (name, mode, arch) mit 'r' zum Lesen und 'native' als arch und bekomme beim ersten Senden des Befehls: >>> [FID, MSG] = fopen ("COM5","r") FID = 3 MSG = und beim zweiten mal Senden: >>> [FID, MSG] = fopen ("COM5","r") FID = -1 MSG = Permission denied (Octave-Hilfe: If an error occurs, FID is set to -1 and MSG contains the corresponding system error message.) Will ich nun auf den anderen Anschluss zugreifen schreibe ich: >>> [FID, MSG] = fopen ("COM7","r") FID = 4 MSG = >>> FID_LIST = fopen ("all") liefert nun den Wert: FID_LIST = 3 4 Wie ich diesen Rückgabewert interpretieren soll ist mir noch nicht ganz klar. War klar, dass ein einfacher Zugriff nicht möglich ist. Aber was nun? branadic
Autor:
Ernestus Pastell
(malzeit)
Datum:
Warum öffnest du die serielle Schnittstelle mehrmals? Folglich nach dem Senden mit fclose() den Port wieder schließen, beziehungsweise einmal am Porgrammanfang öffnen und am Ende schließen.
Datum:
Hallo Ernestus, zu dieser Frage ein Auszug aus der Octave-Hilfe zu diesen Build-in Functions: "...Opening a file that is already open simply opens it again and returns a separate file id. It is not an error to open a file several times, though writing to the same file through several different file ids may produce unexpected results..." Und das wollte ich schlichtweg testen. branadic
Datum:
Vielleicht dazu noch meine Quellenangabe, auf die sich meine beiden letzten Postings stützen: http://www.network-theory.co.uk/docs/octave3/octave_137.html branadic
Autor:
Ernestus Pastell
(malzeit)
Datum:
Dachte auch, dass das mehrmals öffnen kein Problem sein sollte. Aber nach deinen vorangegangenen Postings war das ja nicht die Fragestellung. Vielleicht hat das mit der Implementierung zu tun und in Windows ist es API-mäßig nicht möglich, das ein COM-Port mehrmals geöffnet wird. Da kenn ich mich jetzt nicht so aus.
Datum:
Ernestus Pastell schrieb: > und in Windows ist es > API-mäßig nicht möglich, das ein COM-Port mehrmals geöffnet wird Das kann natürlich der Grund sein. Worauf ich eigentlich hinziele ist eine Möglichkeit der Datenerfassung in Octave, doch leider scheint es in der Richtung noch nichts als Pendant zur Data Aquisition Toolbox von Matlab zu geben. Hier: http://www.mail-archive.com/octave-dev@lists.sourc... scheint jemand zumindest eine Implementierung begonnen zu haben und die Post sind mit Juni/2010 noch vergleichsweise jung. Es ist wirklich schade, dass es da noch kein Modul zu geben scheint. Matlab oder LabView sind für den privaten Geldbeutel doch eine echte Belastung. branadic
Datum:
Noch ein Nachtrag. Während meiner Suche im Netz bin ich auch über das "BioSig for Octave and Matlab"-Projekt gestolpert. Grundsätzlich sehr interessant, doch leider ist auch hier der für mich interessante Teil biosig/t100/*: Data acquisition noch vollständig leer. branadic
Datum:
Hallo mittlerweile gab es Post vom Octave-Projekt: "...Unfortunately at the moment, the serial com port have not been supported octave on windows. Some volunteer persons need to write serial device functions using the win32 api libraries..." Vielleicht findet sich ja doch noch eine Möglichkeit?! branadic
Autor:
Ernestus Pastell
(malzeit)
Datum:
Tut octave denn zeichen senden und empfangen? Der Workaround wäre dann halt nur einmal öffnen bzw. jedesmal schließen.
Datum:
Mir ist momentan noch nicht klar, wie ich Zeichen senden muss. Da bin ich noch auf der Suche nach Verständnis. Zumindest gab es Antwort vom Octave-Forum. Hier die Mailantwort, vielleicht hilft es ja jemand anderem weiter: "Another option involve(s) using the ser2net library. Octave already has a sockets package and the ser2net server allows you to connect over a socket and then send and receive over the serial port. I know that this package used to be available on Cygwin (I haven't used cygwin in 5-6 years so don't know whether it is still available). I also know of one lab that had a very old PC that they put a tiny Linux distribution on whose sole purpose was to run ser2net and connect to their device over serial. Then they could control the device from any networked machine." branadic
Autor:
Ernestus Pastell
(malzeit)
Datum:
Neben ser2net gibts noch das com0com-Projekt. http://com0com.sourceforge.net/ Aber wenn COMx öffnen möglich ist, dann begutachte doch einfach nochmal das obige Beispiel. Meine Vermutung ist nach wie vor, das die Windows-API den COM-Port nur einmal öffnen lässt. Zum Code falls der dir nicht voll klar ist: fcntl (f, F_SETFL, O_NONBLOCK) // eine Initialisierung; auch mal ohne probieren status = fputs (f, "AT\n") // Zeug senden aw = fgetl (f) // Zeile empfangen und in aw speichern bzw. bei einem Fehler oder Timeout den numerischen Wert -1. (EOL-Zeichen/Terminator könnte kritisch sein kenn ich mich aber nicht aus) Der hier hatte ja trotzdem probleme: https://www-old.cae.wisc.edu/pipermail/help-octave... Wenn du Zugang zu einer Matlab-Installation hast dann schau dir mal an was der Rückgabewert von serial() ist. Letztlich muss das ja auch nur ein String sein, der an fopen() geht. s = serial('COM1'); s fopen(s);
Datum:
Ich habe mal in Matlab versucht eine Kommunikation mit einem Gerät herzustellen. Dabei handelt es sich um ein Multimeter (ein anderes Gerät hab ich gerade nicht da, das mit mir kommunizieren könnte), dem ich in hex 89 (bin 10001001) schicken muss, um ein Datenpaket mit dem aktuellen Messwert zu empfangen. Dazu verwende ich die Funktion serial.m in Matlab. Ich meine die Konfiguration korrekt durchgeführt zu haben, jedoch bekomme ich in Matlab keinen Wert zurück. Mit get(s) kann man ja die Port-Einstellungen anzeigen lassen und die scheinen zumindest mit denen in Hterm überein zu stimmen. Und unter Hterm empfange ich auch den aktuell auf dem Display dargestellten Wert. Anbei noch mein Code. Wenn ich es schon in Matlab nicht hinbekomme, dann seh ich schwarz für Octave.
>> delete(instrfindall);
s = serial('COM3', 'BaudRate', 9600, 'Parity', 'none', 'DataBits', 8,...
'StopBits', 1);
get(s) %Port-Einstellungen abrufen
fopen(s); %Connect serial port object to device
get(s, 'Status')
ByteOrder = littleEndian
BytesAvailable = 0
BytesAvailableFcn =
BytesAvailableFcnCount = 48
BytesAvailableFcnMode = terminator
BytesToOutput = 0
ErrorFcn =
InputBufferSize = 512
Name = Serial-COM3
ObjectVisibility = on
OutputBufferSize = 512
OutputEmptyFcn =
RecordDetail = compact
RecordMode = overwrite
RecordName = record.txt
RecordStatus = off
Status = closed
Tag =
Timeout = 10
TimerFcn =
TimerPeriod = 1
TransferStatus = idle
Type = serial
UserData = []
ValuesReceived = 0
ValuesSent = 0
SERIAL specific properties:
BaudRate = 9600
BreakInterruptFcn =
DataBits = 8
DataTerminalReady = on
FlowControl = none
Parity = none
PinStatus = [1x1 struct]
PinStatusFcn =
Port = COM3
ReadAsyncMode = continuous
RequestToSend = off
StopBits = 1
Terminator = LF
ans =
open
>> send = 10001001; %Write HEX:89 to DMM for receiving data package
fwrite(s, send) %Write binary data to device
s.BytesAvailable
value = fscanf(s)
ans =
0
Warning: A timeout occurred before the Terminator was reached.
value =
''
|
Ich gebe aber noch nicht auf. Leider habe ich bisher noch zu wenig Code-Beispiele gefunden, in denen jemand sauber mit einem Gerät aus Matlab heraus kommuniziert. branadic
Datum:
branadic schrieb: > send = 10001001; %Write HEX:89 to DMM for receiving data package > fwrite(s, send) %Write binary data to device damit schickst du aber afaik den String "10001001" und nicht den ASCII-Wert 0x89...
Autor:
Ernestus Pastell
(malzeit)
Datum:
fscanf arbeitet Zeilenbasiert, braucht also ein EOL-Zeichen bzw. einen Terminator ala '\r' oder '\n'. Das muss dein Multimeter dann auch senden. Ansonsten müsste es noch Low-Level-Funktionen (bspw. fread()) geben. send = 0x89; fänd ich auch eleganter
Datum:
Justus Skorps schrieb: > damit schickst du aber afaik den String "10001001" und nicht den > ASCII-Wert 0x89... Gut, aber auch die andere Variante funktioniert nicht:
fprintf(s,'%X','89','async') |
'%X' steht hier für das Format HEX Ernestus Pastell schrieb: > fscanf arbeitet Zeilenbasiert, braucht also ein EOL-Zeichen bzw. einen > Terminator ala '\r' oder '\n'. Das muss dein Multimeter dann auch > senden. Das tut es, wenn ich mit Hterm 0x89 sende, kommt als Antwort: Ascii: ??????0137[<\n> bzw. HEX: 89 F8 82 80 80 3F 30 31 33 37 5B 0A Irgendwo hab ich noch einen Fehler, entweder gedanklicher Seite oder auf der Umsetzungsseite. branadic
Autor:
Ernestus Pastell
(malzeit)
Datum:
Nach den obigen Angaben wartet s.BytesAvailable bis der Terminator LF kommt. Also muss es irgendwie an fscanf() liegen, denn erst danach scheitert das Script. Da könnte man jetzt noch das ausprobieren: line = fgetl(s) line Ein bisschen komisch kommt mir dein fscanf() noch vor. Probiers bei Erfolg noch mit: a = fscanf(s, "%s") a Oder mal nur s.BytesAvailable damit der Ort des Fehler enger eingekreist wird.
Datum:
So, man ist ein Stück weiter, dem Admin sei Dank. Man nehme zwei USB-RS232-Umsetzer, schicke über Hterm -1 den HEX-Wert 89 und schaue an HTERM -2 was dort ankommt, nämlich HEX: 89 0A oder ASCII: □ <\n> Danach versuche man zu verstehen, was Matlab sendet und ändere entsprechend den zu sendenden Wert, bis in HTerm -2 das gleiche von Matlab empfangen wird.
close all; clear all;
delete(instrfindall);
s = serial('COM3');
s.BaudRate = 9600;
s.DataBits = 8;
s.DataTerminalReady = 'on';
s.FlowControl = 'none';
s.Parity = 'none';
s.ReadAsyncMode = 'continuous'; %continuous/manual
s.RequestToSend = 'off';
s.StopBits = 1;
s.Terminator = 'LF';
get(s) %Port-Einstellungen abfragen
fopen(s); %Connect serial port object to device
get(s, 'Status') %Port-Status abfragen: closed/open
fwrite(s,137) %Write binary data to device dec:137 = hex:89
fwrite(s,10) %LF dec:10 = ascii: \n
s.BytesAvailable
fclose (s)
delete(s)
clear s
|
Wenn ich nun jedoch das Multimeter anspreche kommt nichts zurück:
ByteOrder = littleEndian
BytesAvailable = 0
BytesAvailableFcn =
BytesAvailableFcnCount = 48
BytesAvailableFcnMode = terminator
BytesToOutput = 0
ErrorFcn =
InputBufferSize = 512
Name = Serial-COM3
ObjectVisibility = on
OutputBufferSize = 512
OutputEmptyFcn =
RecordDetail = compact
RecordMode = overwrite
RecordName = record.txt
RecordStatus = off
Status = closed
Tag =
Timeout = 10
TimerFcn =
TimerPeriod = 1
TransferStatus = idle
Type = serial
UserData = []
ValuesReceived = 0
ValuesSent = 0
SERIAL specific properties:
BaudRate = 9600
BreakInterruptFcn =
DataBits = 8
DataTerminalReady = on
FlowControl = none
Parity = none
PinStatus = [1x1 struct]
PinStatusFcn =
Port = COM3
ReadAsyncMode = continuous
RequestToSend = off
StopBits = 1
Terminator = LF
ans =
open
ans =
0
Verstehe ich s.BytesAvailable richtig, dass mir hier angezeigt wird
wieviele Bytes als Antwort zurück gekommen sind? Das Format wäre ja
grundsätzlich erst einmal egal, aber das gar nichts zurück kommen soll
ist doch seltsam.
entsprechend liefert:
line = fgetl(s)
dann auch die Meldung:
Warning: A timeout occurred before the Terminator was reached.
line =
''
branadic
Datum:
Was den Betrieb unter Octave angeht habe ich weiter das Netz durchforstet und bin über diese Seite gestolpert: http://libertadhack.blogspot.com/2010/08/puerto-se... Ist zwar nicht für den Betrieb unter Windows gedacht, müsste doch aber generell portierbar sein? Immerhin ist es vollständig OpenSource. branadic
Autor:
Ernestus Pastell
(malzeit)
Datum:
Drahtbrücke zwischen Pin2 und Pin3 am COM-Port, dann kommt alles zu Matlab zurück. Dann hast du garantiert Daten. Der Timeout dauert 10 Sekunden. Braucht fgetl&co auch solange bis ein Fehler kommt? s.BytesAvailable liefert die Zahl der Bytes im Puffer. Laut Online-Referenz¹ könnte readasync(g) aber noch erforderlich sein. Jedoch dauert es seine Zeit bis Seriell etwas übertragen ist. Besser vor der Abfrage noch ne Sekunde warten mit pause()&co. So wirklich kann ich dir jetzt nicht mehr weiterhelfen, da ich nur gelegentlich was mit octave mache. ¹http://www.mathworks.com/help/toolbox/instrument/f...
Datum:
Hallo Ernestus, Drahtbrücke könnte ich mal machen, probier ich morgen mal aus. Daheim hab ich kein Matlab. readasync(g) werde ich dann ebenfalls mal probieren. Ernestus Pastell schrieb: > So wirklich kann ich dir jetzt nicht mehr weiterhelfen, da ich nur > gelegentlich was mit octave mache. Immerhin hast du dafür gesorgt das ich keinen Monolog führe und unter Umständen kommen wir ja doch noch zu einer Lösung? Es ist immer wieder schade, wenn man nicht die richtigen Leute erreicht. Octave ist ein wirklich starkes Tool, auch wenn es langsamer als Matlab sein soll. Dennoch kann ich mir nicht vorstellen, dass sich viele Matlab leisten wollen. Es könnte daher der Eindruck entstehen, dass es hauptsächlich die Linux User sind die Octave verwenden, weiterentwickeln und sich mit Signalverarbeitung beschäftigen. Das kann so natürlich nicht der Realität entsprechen. Programmieren sich alle Leute alles selbst neu obwohl ein Tool wie Octave zur Verfügung steht und man nur eine Möglichkeit schaffen müsste die Daten in Octave hinein zu bekommen? Auch schade, dass eine GUI-Toolbox wie guide nicht unter Octave zur Verfügung steht, könnte doch QT grundsätzlich ein vielversprechender Ansatz sein. branadic
Datum:
Linux hat eine sehr gute Console, von der aus kann man mühelos auch Texteditor und Grafik(nach)bearbeitung starten. Von der Seite denke ich ist der Drang nach einer GUI bei den Entwicklern nicht all zu groß. Linux ist eben die Heimat von Opensource und passt sich halt nicht immer an Windows an. BTW: Serielle Schnittstelle unter Linux funktioniert bestens. (Baudrate verstellen ginge noch irgendwie mit stty)
printf("hello octave\n\n"); f = fopen("COM1") fcntl (f, F_SETFL, O_NONBLOCK) fputs(f, "hello serial port\n") printf("Press any key to continue"); pause() fgetl(f) fclose(f) printf("end\n"); |
Datum:
Ernestus on XP schrieb: > Serielle Schnittstelle unter Linux funktioniert bestens. Das glaub ich schnell, aber wenn man nun mehrere Jahre mit einem OS gearbeitet hat, mag man sich einfach nicht umstellen. Die Software sollte sich immer an den User anpassen, nicht umgekehrt. Zugleich unterstütze ich aber den OpenSource-Gedanken und nutze soweit irgendmöglich OpenSource Softwrae, wenn ich mit Windows auch nicht gerade die optimale Plattform habe. Daher muss es unter Octave und Windows einfach einen Weg geben ;) Gerade schaue ich mir die Sourcen von oben genanntem Link an und überlege, wie sich das an Windows anpassen lässt. branadic
Autor:
Ernestus Pastell
(malzeit)
Datum:
Kleine Korrektur. Es heißt:
f = fopen ("/dev/ttyUSB1", "r+"); % read and write
Das andere war schon an Experimente für Windows angepasst.
Datum:
Guten Morgen, ich habe jetzt wie empfohlen eine Brücke zwischen Pin 2 und 3 und noch einmal meinen Code geprüft. Da ich weiß was ich durch die Brücke zwischen Pin 2 und 3 empfangen werde kann ich den fread-Befehl auch gleich richtig schreiben:
close all; clear all;
delete(instrfindall);
s = serial('COM3');
s.BaudRate = 9600;
s.DataBits = 8;
s.DataTerminalReady = 'on';
s.FlowControl = 'none';
s.Parity = 'none';
s.ReadAsyncMode = 'continuous'; %continuous/manual
s.RequestToSend = 'off';
s.StopBits = 1;
s.Terminator = 'LF';
get(s) %Port-Einstellungen abfragen
fopen(s); %Connect serial port object to device
get(s, 'Status') %Port-Status abfragen: closed/open
fwrite(s,137) %Write binary data to device dec:137 = hex:89
fwrite(s,10) %LF dec:10 = ascii: \n
%pause(2) %Pause zwischen Senden und Statusabfrage
get(s)
s.BytesAvailable
line = fread(s,[2,1])
fclose (s)
delete(s)
clear s
|
Zumindest mit dieser Methode kommen die Daten wieder in Matlab rein. Mit dem Multimeter klappt das jedoch nicht. Selbst nicht, wenn ich ein pause(2) oder mehr zwischen Senden und Statusabfrage einfüge. Woran das liegt kann ich nicht sagen. Immerhin schon mal ein kleiner Teilerfolg. branadic
Datum:
Angehängte Dateien:Hallo, weiter oben hatte ich ja den nachfolgenden Link schon mal gepostet: http://libertadhack.blogspot.com/2010/08/puerto-se... Ich hatte mit dem Programmierer Kontakt aufgenommen und er hat in der Zwischenzeit das Skript geändert und nun läuft es unter Windows. Die Vorgehensweise ist recht einfach: 1. Octave-3.2.4_i686-pc-mingw32_gcc-4.4.0_setup.exe installieren: http://sourceforge.net/projects/octave/files/Octav... 1a. Bei Bedarf noch die aktuelle Qt-Oberfläche, ähnlich Matlab, downloaden: http://www.outsch.org/wp-content/uploads/2010/04/q... und in das Octave Installationsverzeichnis entpacken. Dabei werden der \bin und \share -Ordner überschrieben. Nun müsst ihr noch den Pfad der Verknüpfung ändern, schließlich muss nun die qtoctave.exe gestartet werden. 2. Python downloaden und installieren http://www.python.org/ftp/python/2.7/python-2.7.msi 3. PySerial downloaden und installieren http://pypi.python.org/packages/any/p/pyserial/pys... 4. Die oben angehängte sockets.tar.gz abspeichern 5. Octave bzw. QtOctave starten und dort in das Verzeichnis wechseln, in das ihr die sockets.tar.gz abgespeichert habt cd "Verzeichnis" z.B. cd C: 6. nun das Socket-Paket installieren > pkg install sockets.tar.gz 7. octave-serialport-windows.zip abspeichern und im Octave-Verzeichnis bei den m-Files entpacken C:\Programme\Octave\share\octave\3.2.4\m\octave-serialport-windows\ 8. Octave neustarten Nun sollte es euch möglich sein einen Test durchführen zu können.
close all;
clear all;
% In das Verzeichnis wechseln, wo die Datei sport_client.py liegt
cd "C:/Programme/Octave/share/octave/3.2.4/m/octave-serialport-windows"
s=serial('COM1');
data_out='test'; %sendet das Wort test als binäre Zeichenfolge
spwrite(s,data_out);
bytesAvailable(s)
data_in=spread(s,4)
spclose(s);
|
Ich hab es mit einem FT232 erfolgreich ausprobiert. Brücke zwischen Rx und Tx rein, dann sollten nach dem Sendevorgang Daten in data_in liegen, bzw. bytesAvailable sollte ans = 4 liefern. Schönen Sonntag, branadic
Datum:
Hi! ich bin gerade auch auf Suche nach einer Möglichkeit mittels Octave über die COM-Schnittstelle Daten einzulesen. Bin auf euren sehr lobenswerten Austausch gestoßen (vielen Dank schonmal nur dafür ;) Ich bin der "Anleitung" aus dem letzten Post gefolgt. Nur bekomme ich beim Punkt 6. ---6. nun das Socket-Paket installieren --- ---> pkg install sockets.tar.gz die folgende Meldung im Qtoctave Terminal:
sockets.cc: In member function 'bool octave_socket::is_data_available()': sockets.cc:136: warning: no return statement in function returning non-void sockets.cc: In function 'octave_value_list Fsend(const octave_value_list&, int)': sockets.cc:524: warning: comparison between signed and unsigned integer expressions sockets.cc: In function 'octave_value_list Faccept(const octave_value_list&, int)': sockets.cc:688: warning: unused variable 'retval' |
Ist das i.O., oder läuft da was schief? Kann ich irgendwie verfolgen, ob der COM-Port geöffnet wurde? Oder ist die generelle Funktionsprüfung über die Brücke zw. Tx und Rx die "einfachste" Methode? ML
Datum:
Okay, hab meinen Fehler gefunden. Habe aus dem Testcode in der "Anleitung" die "" in der Pfadangabe gelöscht:
close all;
clear all;
% In das Verzeichnis wechseln, wo die Datei sport_client.py liegt
cd C:/Programme/Octave/share/octave/3.2.4/m/octave-serialport-windows
s=serial('COM1');
data_out='test'; %sendet das Wort test als binäre Zeichenfolge
spwrite(s,data_out);
bytesAvailable(s)
data_in=spread(s,4)
spclose(s); |
Werde mal weiter damit "rumprobieren" mal sehen, was dabei raus kommt! ML
Datum:
Moin, ich möchte mit Freemat die serielle Schnittstelle (RS232) ansprechen. Unter http://markmail.org/message/a4hagyd534t6fxqt#query... habe ich gefunden, wie das gehen soll. Mein Testcode:
system ('MODE COM1: BAUD=115200 PARITY=n DATA=8 STOP=1') f = fopen('COM1','w+b'); in = fread(f) fwrite(f, 111); fclose(f) |
Wenn ich diesen Code unter Octave einsetze, so funktioniert das Senden
und Empfangen, wobei das Senden nur beim Schließen (fclose) erfolgt.
Unter Freemat produziert "f = fopen('COM3','w+b')" jedoch den Fehler:
"Error: Die Syntax für den Dateinamen, Verzeichnisnamen oder die
Datenträgerbezeichnung ist falsch. for fopen argument COM3"
Also ergeben sich für mich zwei Fragen:
-Ich kann mir denken, dass fopen immer nur Daten speichert/sendet, wenn
"fclose" ausgeführt wird. Ist dies richtig? Bzw. wie kann man dies
ändern?
-Warum funktioniert der Befehl unter Freemat nicht? Bzw. was muss ich
abändern?
Gruß
Ben
(Win 7 Pro 64bit, ATmega32, STK 500, AVRISP mkII)
Autor:
Ernestus Pastell
(malzeit)
Datum:
Warum "f = fopen('COM3','w+b')" unter FreeMat einen Fehler porduziert
weiß ich nicht.
Damit GNU Octave Daten nicht unmittelbar nach fwrite sendet liegt
wahrscheinlich daran, das die Funktion asynchron arbeitet. Sofern die
ganze POSIX-"API" vorhanden ist sollte "fflush()" den Puffer unmittelbar
(synchron) leeren.
Datum:
Um direct zu senden und nicht auf fclose zu warten muss noch ein null
angehängt werden ('fwrite(f, [111 0])') damit der 'string' terminiert
ist.
Datum:
Die Installation des Packages sockets.tar.gz funktioniert bei mir nicht. Immerhin werden es weniger Fehler, wenn ich das sockets.1.0.8.tar.gz verwende aber sockets bleibt nach wie vor uninstalliert. Habe Python 3.3, PySerial 2.5 und Octave 3.6.1 in GUIoctave 1.7 verwendet. Kann das an Versionskonflikten liegen? In Octave.sourceforge.net steht überhaupt nichts davon, daß man Python braucht um Packages zu installieren. vor 1.0.8 Fehler: sockets.cc: In function 'octave_value_list FAF_UNIX(const octave_value_list&, int)': sockets.cc:209:1: error: 'AF_UNIX' was not declared in this scope usw... bei 1.0.8 sockets.o: In function `ZN13octave_socket14remove_sock_fdEv': ...\AppData\Local\Temp\oct-14\sockets\src/sockets.cc:332: undefined reference to `closesocket@4' Kann jemand helfen und sagen, ob die Fehler von Octave oder von Python herrühren? Danke! Alex
Datum:
Beide Fheler rühren wahrscheinlich von sockets her. Der erste Fehler sieht nach einem Konfigurationsfehler aus. Wenn die Konstante bzw. das Makro AF_UNIX unbekannt ist, fehlt wahrscheinlich die Angabe für welche Maschine sockets übersetzt wird. Der zweite Fehler sieht ebenfalls nach einer falschen Maschinendefinition aus. Schaut man in sockets.cc rein, sieht man eine Stelle an der closesocket aufgerufen wird.
void octave_socket::remove_sock_fd(void) { #ifndef __WIN32__ ::close( sock_fd ); #else ::closesocket( sock_fd ); #endif socket_map.erase( sock_fd ); sock_fd = -1; } |
Es handelt sich um den Fall wenn _WIN32_ definiert ist, d.h. dieses File wird für eine Windows-Maschine übersetzt. Die Funktion closesocket kommt dann über Winsock (#1) von Windows rein, vorausgesetzt die Toolchain linkt Winsock dazu. Check mal ab, ob du für WIN32 übersetzen willst und wenn nicht schau nach wer oder was dir _WIN32_ definiert. Es wäre schlauer gewesen, wenn du einen eigenen Thread gestartet hättest, statt dich hier anzuhängen. #1: http://msdn.microsoft.com/en-us/library/windows/de...
Datum:
Also danke für die Mühe! Jetzt gehts wenn ich Octave 3.4.3 verwende. Selbst mit dem alten Python 2.7 gings unter Octave 3.6.1 nicht. sport_client.py muss halt noch ins Verzeichnis des m-Files. Der USB-Serial Adapter blinkt zumindest schon mal. Octave macht hin und wieder mit neuen Versionen Zicken, GUI Octave ebenso. Ich schreibe lieber hier, dann finden die 'Abo'-Leute, also die sich damit eher auskennen, gleich die Frage.
Datum:
Warum ist der Thread eigentlich verschoben worden? Octave gehört doch eher in den DSP-Bereich. Stimmt, im aktuellen Octave bekomme ich das auch alles nicht mehr zum Laufen. Das ist wieder ein echter Rückschritt. Schön wäre, wenn das mal richtig in Octave implementiert würde (für alle Betriebssysteme) und man nicht über Krücken Zugriff auf so etwas simples wie die COM-Schnittstelle realisieren müsste. So macht das keinen Spaß. branadic
Datum:
Ich kenne ocatave nicht, aber kann man das nicht in ein Terminal schreiben? Mit einer Art stdout gelangt man doch mit anderen Programmen auch immer auf eine Console, die man dann auf einen Port umleiten kann. Oder man tut sich zusammen und setzt den octace Proggern das Ding auf die todo-List :-)
Datum:
ING-O schrieb: > Oder man tut sich zusammen und setzt den octace Proggern das Ding auf > die todo-List :-) Druck ausüben dürfte hier nicht viel bringen, da die Programmierer in aller Regel zugleich Linux-User sind. Zudem führt massiver Druck bekanntermaßen eher zu Resignation. Leider fehlen mir die Fertigkeiten mich der Sache selbst anzunehmen. branadic
E-Mail-Benachrichtigung einschalten
Neu: Seitenaufteilung einschalten