ubuntuusers.de

Welches Programm liefert diese Fehlermeldung?

Status: Gelöst | Ubuntu-Version: Ubuntu 9.10 (Karmic Koala)
Antworten |

Arluen

Anmeldungsdatum:
2. März 2010

Beiträge: Zähle...

Hallo,

bin mir nicht so sicher ob das Thema hier richtig ist aber habe auch leider keine passendere Kategorie finden können.

Erst einmal liste ich hier die eventuell verantwortlichen Hard- und Softwarecomponents auf: Ich habe einen Standard-Bahnhof-Snackautomat (ja so ein riesen Gerät mit Spiralen usw für Schokoriegel) mit seriellem I/O via USB Converter an einen Desktop-PC (Ubuntu 9.10) angeschlossen. Dann benutze ich das Programm interceptty (http://www.suspectclass.com/sgifford/interceptty/) um einen UNIX Port auf mein Gerät /dev/ttyUSB0 zu linken. Dadurch vereinfache ich die Kommunikation mit diesem Automatenzeugs, da meine rechnerseitig steuernde Programmiersprache PHP ist. Ich stelle den Link mit folgendem Befehl her:

1
sudo -u www-data interceptty -v -s 9600 /dev/ttyUSB0 @/tmp/vendingsock

Da durch, dass ich www-data als Executer verwende, kann PHP ganz gewöhnliche Kommunikation mit diesem Automat betreiben.

Leider kriege ich bei statusabfragenden Kommandos an den Automaten nicht immer aber zu 95% folgende Fehlermeldung:

1
2
Error writing to frontend device: Broken pipe
closing down everything

Seltsam hierbei ist, dass Kommandos die zb eine Spirale drehen lassen um einen Snack auszuwerfen, wunderbar funktionieren. Sobald ich aber den Automaten nach seinem Zustand frage (egal ob das Thales Payment Modul, die Lichtschranke oder den Generalprozess) kommt die oben genannte Fehlermeldung.

Nun habe ich als Linux Anfänger erst einmal rumgesucht was Broken Pipe bedeutet. Ich habe ermittelt, dass dies bei der Verwendung der | geschieht, sobald das auf Resultate wartende Programm aus irgend einem Grund beendet wird bevor das Subprogramm beendet wurde. Hier ein Beispiel mit dem Aufruf

1
tar -xxxx | gzip -xxx

A broken pipe means one process finished before another. In this case, it sounds like gzip aborted before tar could complete.

Nur wer liefert mir nun Broken Pipe?

Mein Ubuntu 9.10? Oder die libusb? Oder ist es das interceptty Tool? Vielleicht auch der Automat und der meint das wörtlich als Kabelbruch? Meine Frage ist nun, wie kriege ich heraus welches Programm diese Fehlermeldung geliefert hat?

Ich freue mich auf eure Unterstützung

Grüße Dennis

Hello_World

Anmeldungsdatum:
13. Juni 2006

Beiträge: 3620

Wo kommt denn diese Fehlermeldung? Auf dem Terminal, auf dem interceptty läuft? In diesem Fall würde ich die Fehlermeldung so interpretieren, dass das Programm per send- oder write-Systemaufruf Daten nach /dev/ttyUSB0 schreibt, was mit dem Fehlercode EPIPE fehlschlägt. In der glibc-Dokumentation heißt es:

EPIPE: This socket was connected but the connection is now broken. In this case, send generates a SIGPIPE signal first; if that signal is ignored or blocked, or if its handler returns, then send fails with EPIPE.

Aufgrund des miesen Systems zur Fehlerbehandlung in UNIX kann man mit dieser Fehlermeldung also nichts anfangen. Du könntest höchstens mal mit dmesg nachschauen, ob sich irgendwelche Indizien dafür finden lassen, dass die Verbindung mit dem tty abreißt.

track

Avatar von track

Anmeldungsdatum:
26. Juni 2008

Beiträge: 7174

Wohnort: Wolfen (S-A)

Hi Dennis,

willkommen auf dem Forum !

Ist schon lustig, was man alles mit Linux betreiben kann ...

Bei Deiner Fehlermeldung hätte ich als erstes irgend ein Skrikpt im System in Verdacht.
Ist z.B. vielleicht interceptty ein Skript, in dem dann irgend eine wüste Pipe steckt ?

Vielleicht findest Du auch in den log's unter /var/log/* schon irgend welche Hinweise ... ?
Ansonsten heißt es, die beteiligten Komponenten mal näher anzuschauen, wo da ein Skript
mit einer Pipe versteckt sein könnte. (Und wer da was alles aufruft)

Am Ende ist es womöglich nur ein Timeout, den man etwas länger einstellen muss ...
(nur, man muss ihn finden)

track

Arluen

(Themenstarter)

Anmeldungsdatum:
2. März 2010

Beiträge: 17

Hey ho vielen Dank für die Begrüßung und für eure Hilfestellungen,

interessantes Programm dieses dmesg ☺

Hier wurde glaube ich der Automat erstmals von mir eingesteckt, oder gibts sonst noch Geräte die USB Serial Interfaces benutzen? (Maus, Tastatur, TouchScreen)

1
[   13.167212] usbcore: registered new interface driver usbserial_generic

Also generell liefern mir die Informationen zum ttyUSB0 folgende Ergebnisse

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
dennis@amarium:~$ dmesg | grep ttyUSB
[   13.316593] usb 2-2: MCT U232 converter now attached to ttyUSB0
[ 1462.606287] mct_u232 ttyUSB0: MCT U232 converter now disconnected from ttyUSB0
[ 1565.466927] usb 3-1: MCT U232 converter now attached to ttyUSB0

dennis@amarium:~$ dmesg | grep tty
[    0.001196] console [tty0] enabled
[    0.761097] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[    0.761513] 00:09: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[   13.316593] usb 2-2: MCT U232 converter now attached to ttyUSB0
[ 1462.606287] mct_u232 ttyUSB0: MCT U232 converter now disconnected from ttyUSB0
[ 1565.466927] usb 3-1: MCT U232 converter now attached to ttyUSB0

Da fand ein Disconnect statt, was aber auch ein manuelles ziehen des USB Steckers sein kann.

Wo kommt denn diese Fehlermeldung? Auf dem Terminal, auf dem interceptty läuft?

Ja genau, ich kriege life Ausgaben der Verbindung, einen Befehl abschicken der zum Absturz des Systems führt sieht etwa so aus:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
< 0x53 (S)
< 0x54 (T)
< 0x41 (A)
< 0x54 (T)
< 0x56 (V)
< 0x45 (E)
< 0x4e (N)
< 0x44 (D)
< 0x0d
> 	0x0d
> 	0x56 (V)
Error writing to frontend device: Broken pipe
closing down everything

Eine Info hab ich zur der späten Stunde gestern vergessen und ich glaube diese ist ausschlaggebend: Auf meinem USB 232 Converter (Seriell to USB) sind 3 Lämpchen: Link, TX, RX.

Link leuchtet dauerhaft, was vmtl auf bestehende Hardware Verbindung hindeutet. TX leuchtet beim Übertragen eines Befehls einmalig auf. RX blinkt 2x auf sobald die Verbindung abschmiert. Nun sind meine Hardwarekenntnisse echt rare und das Datenblatt des Konverters (http://www.targus.com/de/product_details.asp?sku=PA088E) gibt mir mal gar keine Informationen. Kann sich da wer einen Reim drauf bilden?

Im Syslog bin ich grad auf die Logmeldungen die ich im PHP Script generiere gestoßen, was als Treiber oder Proxy dient:

Mar  3 18:19:14 localhost vendingproxy[1620]: Cmd(VEND0011) port(unix:///tmp/vendingsock) emu() verbose() debug() address 127.0.0.1
Mar  3 18:19:15 localhost vendingproxy[1620]: got (àà
Mar  3 18:19:16 localhost vendingproxy[1620]: Result: PROGRESS

Dieses àà also Ascii Zeichen 224 das sehe ich in letzter Zeit öfters im Puffer des Automaten. Vielleicht liegt das da dran, dass er auf die Zeichen nicht klar kommt?

@ track Ich schaue mir den Source von interceptty mal genauer an ob ich da hinweise finde und ich werde das Kabel mal von einem Elektriker messen lassen.

So long, Dennis

//Edit: Tx steht für Transmitter und Rx für Receiver

So ganz verrostet bin ich doch scheinbar noch nicht ☺ Also neue Erkenntnis: Das Abschmieren der Verbindung passiert immer in Zusammenhang mit dem Aufblinken von der Receive LED.

//Edit 2: Das Kabel wurde gecheckt und kein Fehler entdeckt. Ich weis nicht ob mich das freut oder ärgert ^^

track

Avatar von track

Anmeldungsdatum:
26. Juni 2008

Beiträge: 7174

Wohnort: Wolfen (S-A)

Also, den Elektriker kannst Du Dir da sparen, würde ich sagen, denn das sieht ja eher nach einem Softwareproblem aus,
nicht nach eienm Wackelkontakt im Kabel ...

Aber die Fehlermeldung sagt ja deutlich:

Error writing to frontend device: Broken pipe

Das weist deutlich auf das Skript (denke ich) das diese Life-Anzeige erzeugt, die Anzeige des Datenverkehrs.
Guck Dir doch das Skript mal genau an, oder setze es hier her, als Anhang.
(dan gucke ich es mir mal an)

Daraus lässt sich bestimmt ein Hinweis ableiten.

Es kann natürlich auch sein, dass das Verbindungs-Gerät abschmiert und dadurch dann das Anzeigeskript nichts mehr zum zugreifen hat.

track


p.s.: schau Dir bitte auch nochmal das Ende von /var/log/messages an, direkt nachdem die Verbindung abgeschmiert ist:

tail -n 50  /var/log/messages

und setze das Ergebnis ggf. in einem Codeblock

Ungültiges Makro

Dieses Makro ist nicht verfügbar

auch hierher.

Arluen

(Themenstarter)

Anmeldungsdatum:
2. März 2010

Beiträge: 17

Ich wurde angewiesen den alten Kommunikationsrechner wieder einzubinden. Dieser hat ebenfalls interceptty drauf und beinhaltet das Proxyscript. Das seltsame ist nun, dass dort alles einwandfrei funktioniert. Das ist nun leider keine dauerhafte Lösung sondern nur eine zeitliche Verschiebung des Problems. Aber dennoch kann man hier ja parallel weiter schauen ☺

Ich habe auf dem neuen PC (wo es nicht funktioniert) noch einmal einen Absturz provoziert und poste mal interceptty und system Logs:

Hier dreht sich wunderbar Spirale 11 und wirft meinen Nachtisch heraus:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
< 0x56 (V)
< 0x45 (E)
< 0x4e (N)
< 0x44 (D)
< 0x30 (0)
< 0x30 (0)
< 0x31 (1)
< 0x31 (1)
< 0x0d
> 	0x0d

Zum Abfragen des Automaten Status sende ich STATVEND und der Automat hat grade keinerlei Informationen im Puffer und liefert gar nichts. Das ist soweit ok, das passiert und ist ein definierter Zustand. Dafür hab ich Routinen die das Abfangen und erneut fragen.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
< 0x53 (S)
< 0x54 (T)
< 0x41 (A)
< 0x54 (T)
< 0x56 (V)
< 0x45 (E)
< 0x4e (N)
< 0x44 (D)
< 0x0d
> 	0x0d

Beim erneuten Abfragen liefert er nun seinen Pufferinhalt. (Oder Evtl Teile?) Kann ich nicht genau bestimmen ob er am Ende seines Transfers abbricht oder mitten drin. Gültige Antworten auf STATVEND wären ACK, VNDHSxxx (true) oder VNDERxxx (false). Wie man hier sieht bricht er ab nachdem VN übertragen wurde.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
< 0x53 (S)
< 0x54 (T)
< 0x41 (A)
< 0x54 (T)
< 0x56 (V)
< 0x45 (E)
< 0x4e (N)
< 0x44 (D)
< 0x0d
> 	0x0d
> 	0x56 (V)
> 	0x4e (N)
Error writing to frontend device: Broken pipe
closing down everything

Das Systemlog hat leider keine aktuellen Nachrichten. Mein Test ist 5 Minuten her und die letzten Logeinträge 40 Minuten. Die letzten Infos ist das erneute Einstecken das Automaten in den neuen PC:

Mar  4 15:57:42 localhost kernel: [78874.236043] usb 3-1: new full speed USB device using ohci_hcd and address 4
Mar  4 15:57:43 localhost kernel: [78874.455090] usb 3-1: configuration #1 chosen from 1 choice
Mar  4 15:57:43 localhost kernel: [78874.458046] mct_u232 3-1:1.0: MCT U232 converter detected
Mar  4 15:57:43 localhost kernel: [78874.458158] usb 3-1: MCT U232 converter now attached to ttyUSB0

Hier noch mein Zugriffsscript auf das UNIX Socket, eine kleine Klasse die die Kommunikation steuert und via send() Kommandos versendet: ( Die Mehrfachabfragen des Ports stammen von jemand anderem, und die Stream Timeouts auch. Bin mir selbst noch nicht sicher wieso er das tut. Leider steht diese Person derzeit für Rückfragen nicht zur Verfügung.

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
<?php

class VMC_RPC
{
	private $m_socket = null;
	private $m_port = null;
	private $m_ack = null;
	
	public function VMC_RPC( )
	{
	}
	
	public function init( $port, $ack )
	{
		$this->m_port = $port;
		$this->m_ack = $ack;
	}
	
	public function open( )
	{
		$port_path = str_replace( "unix://", "", $this->m_port );
		if( file_exists( $port_path ) )
		{
		    	$this->m_socket = @fsockopen( $this->m_port, 0, $errnum, $errstr );
		    		
		    	if( $errnum <> 0 )
		    	{
		    		echo "Error occurs while binding at port '" . $this->m_port . "': " . $errnum . " => " . $errstr;
		    		$this->m_socket = null;
		    		return false;
			}
			return true;
		}
		else
		{
			echo "Could not find port '" . $this->m_port . "'";
			return false;
		}

	}
	
	public function close( )
	{
		fclose( $this->m_socket );
	}
	
	public function send( $cmd )
	{
		//open port if closed
		if( $this->open( ) )
		{
			
			fwrite( $this->m_socket, $cmd . $this->m_ack );
			stream_set_timeout( $this->m_socket, 1);
		
	    		$result = fgets( $this->m_socket, 1024 );

			//if no answer received
			if ( !$result ) 
				return "NIX";

			//if answer = NAK return "NACK" and submit ACK
			if( substr( $result, 0, 1) == chr( 0x15 ) ) 
			{
				$result = "NACK";
				fwrite( $this->m_socket, $this->m_ack );
			}
		
			//read next message and overwrite if isset
			stream_set_timeout( $this->m_socket, 1 );
	    		$result2 = fread( $this->m_socket, 1024 );
	    		if ( $result2 && ( strlen( $result2 ) > 1 ) ) 
	      			$result = $result2;
	      			
	    		$info = stream_get_meta_data( $this->m_socket );
	    		if( strlen( $result ) > 6 ) 
	    		{

	      			fwrite( $this->m_socket, $this->m_ack);
	      			usleep(50000);

	      			stream_set_timeout( $this->m_socket, 1 );
	      			$result2 .= fread( $this->m_socket, 1024 );

	      			if( $result2 && ( strlen( $result2 ) > 1) ) 
	      			{
					$result = $result2;
	      			}
	    		}
	    		
	    		if( trim( $result, "\x00..\x1F" ) == "" ) 
	    		{
	      			$result = "PROGRESS";
	    		}

			//close port
			$this->close( );
		
			//read socket data and form into string
			$result = sscanf( $result, "%[^\r\n ]" );
			$result = implode( "", $result );
		
			//remove leading and behind chars trim( $read, "\x00..\x1F" );
			$result = trim( $result, "\x00..\x1F" );
			return $result;
		}
		else
		{
			return false;
		}

	}

}
 
 
if ( !ini_get( "auto_detect_line_endings" ) )
	ini_set( "auto_detect_line_endings", true );
 
$vmc = new VMC_RPC( );
$vmc->init( "unix:///tmp/vendingsock", chr(0x0D) );
$result = $vmc->send( $_GET["cmd"] );
var_dump( $result );
?>

Im Anhang findest du den Sourcecode von interceptty (Autor: Scrott W. Gifford - http://www.suspectclass.com/sgifford/interceptty/)

Nochmal zu den beiden Maschinen: Es ist ja möglich, dass sich diverse Änderungen in der usblib oder anderen verwendeten Komponenten ergeben haben, weshalb das nicht mehr funktioniert. Leider bin ich als Anfänger nicht tief genug in der Materie drin um das herauszufinden. ☹

Auf diesem Rechner funktioniert die Kommunikation:

1
2
3
4
user@vend-eval:~$ echo -e $(cat /etc/issue) | head -1
Ubuntu 8.04.3 LTS 
user@vend-eval:~$ uname -r
2.6.24-24-server

Auf diesem Rechner funktioniert die Kommunikation leider nicht:

1
2
3
4
dennis@amarium:~$ echo -e $(cat /etc/issue) | head -1
Ubuntu 9.10 
dennis@amarium:~$ uname -r
2.6.31-19-generic

Ich hoffe durch die weiteren Informationen kommen wir der Abbruchursache näher.

Vielen Dank für die Hilfe!

Dennis

interceptty-0.6.tar.gz (93.7 KiB)
Sourcecode interceptty
Download interceptty-0.6.tar.gz

track

Avatar von track

Anmeldungsdatum:
26. Juni 2008

Beiträge: 7174

Wohnort: Wolfen (S-A)

Dem tty-Log nach antwortet er ja sowieso mit einem einsamen [LF] statt mit "ACK" oder so ...
(das alleine schon könnte außerplanmäßig sein, wenn auch ohne Auswirkung)

Dann wäre es natürlich die Frage, was macht der neue Rechner, wenn Du ihn probehalber (und sei es von der live-CD aus)
unter Hardy fährst ? - es könnte ja auch eine Frage der Hardware sein ...

Und in den Quelltext von interceptty hatte ich vorher schon mal kurz rein geguckt, aber da sehe ich wenig Ansatz.
Der loggt ist ja sowieso nur den tty- Verkehr ...

Und um es zu analysieren wären da eigentlich 2 Fragen:
- Ist das Handshaking so wie es sein sollte ? und
- Spielt ein Timeout eine Rolle ?

track

Arluen

(Themenstarter)

Anmeldungsdatum:
2. März 2010

Beiträge: 17

track schrieb:

Dem tty-Log nach antwortet er ja sowieso mit einem einsamen [LF] statt mit "ACK" oder so ...

Das ist meines Wissens im Protokoll so vereinbart und das hab ich auch nie hinterfragt. Aber das lässt sich herausfinden, melde mich diesbezüglich.

track schrieb:

Dann wäre es natürlich die Frage, was macht der neue Rechner, wenn Du ihn probehalber (und sei es von der live-CD aus) unter Hardy fährst ? - es könnte ja auch eine Frage der Hardware sein ...

Bin mir nicht so sicher was ich unter Hardy verstehen soll, habe kaum Informationen im Netz finden können. Habe mir dann gedacht, dass ich mal Ubuntu 8.0.3 als Live CD runterlade (Resultate folgen), das wird uns ja auch die Hardwareprobleme ausschliessen oder bestätigen können.

track schrieb:

- Ist das Handshaking so wie es sein sollte ?

Das werde ich mir in der Doku ansehen.

track schrieb:

- Spielt ein Timeout eine Rolle ?

Mal überlegen, wer könnte für einen timeout verantwortlich sein? a) Der Automat? b) Ubuntu tty Einstellungen? c) Den PHP Code während der Streamkommunikation kann ich ausschliessen, da

1
stream_set_timeout( $this->m_socket, 1);

bei jeder Anfrage, auch bei welchen die die Verbindung nicht beenden, durchgeführt wird. d) Welche Komponenten spielen da noch eine Rolle und wie kann ich da die Timeouteinstellungen listen / ändern?

adun Team-Icon

Avatar von adun

Anmeldungsdatum:
29. März 2005

Beiträge: 8606

Ja 8.04.X hat den Spitznamen Hardy Heron. 9.10 heißt Karmic Koala, nur um Verwirrung vorzubeugen. 😉 (vielleicht kann man bei Gelegenheit dem Strang mal einen aussagekräftigen Titel geben, danke)

track

Avatar von track

Anmeldungsdatum:
26. Juni 2008

Beiträge: 7174

Wohnort: Wolfen (S-A)

Dem tty-Log nach antwortet er ja sowieso mit einem einsamen [LF] statt mit "ACK" oder so ...

Wenn das bei dem anderen Rechner funktioniert, kannst Du das rein praktisch wohl auf sich beruhen lassen, ja.

unter Hardy ..

☺ Ja sicher, damit meine ich Ubuntu 8.04 LTS, sorry für den Insiderslang ...

- Ist das Handshaking so wie es sein sollte ?

Das werde ich mir in der Doku ansehen.

Vielleicht ist das rein praktisch gesehen OK, genau wie oben.

- Spielt ein Timeout eine Rolle ?

Mal überlegen, wer könnte für einen timeout verantwortlich sein? a) Der Automat?
b) Ubuntu tty Einstellungen?
c) Den PHP Code während der Streamkommunikation kann ich ausschliessen, da

1
stream_set_timeout( $this->m_socket, 1);

bei jeder Anfrage, auch bei welchen die die Verbindung nicht beenden, durchgeführt wird.
d) Welche Komponenten spielen da noch eine Rolle und wie kann ich da die Timeouteinstellungen listen / ändern?

a) fällt wohl weg, denn es geht ja zuerst um die Kommunikation selbst. Und das Timeout entsteht ja in Deinem Rechner, nicht im Automaten.

Aber ein heißer Kandidat für ein unerwartetes timeout könnte auch der USB- Treiber sein, weil normalerweise die Antwortzeiten
unter USB wesentlich kürzer sind als unter Seriell tty !
(und tty wird ja bei Dir über USB geschickt ...) - dann wird man da die passende Einstellung u.U. etwas verlängern müssen.

track

Arluen

(Themenstarter)

Anmeldungsdatum:
2. März 2010

Beiträge: 17

adun schrieb:

Ja 8.04.X hat den Spitznamen Hardy Heron. 9.10 heißt Karmic Koala, nur um Verwirrung vorzubeugen. 😉

Ah nice to know ☺ Gefällt mir btw immer mehr dieses Ubuntu weil auch die Gemeinde viel offener ist als bei Debian, dass ich bisher noch im Serverbetrieb verwende. Vielleicht stelle ich das auch mal um ☺

adun schrieb:

vielleicht kann man bei Gelegenheit dem Strang mal einen aussagekräftigen Titel geben, danke

Hm schon recht, der Name ist nicht mehr so treffend. Wie änder ich das? Die Edit Funktion beim ersten Beitrag ist ja nicht mehr da, da nur die aktuellsten Beiträge verändert werden können.

So ich hab die Doku (eigentlich eher der E-Mail-Verkehr zwischen unserem Mann, der früher für das Projekt verantwortlich war und einem Programmierer der Automatenproduzenten) nochmals auf die beiden Aspekte Handshake und Timeout durchsucht und habe folgende Informationen entnommen:

Maximum Timeout answer from the VMC (Vending Machine) to report: 60 seconds

Dieser Wert ist für uns uninteressant.

Maximum Timeout to acknowledge command: 100ms (ACK 13H)

Aha, das könnte man evtl mal nachmessen. Ist nur die Frage wie, PHP seitig wohl kaum, das müsste glaube ich schon hardware näher passieren. Vielleicht werden die 100ms wegen anderer Hardware, weniger Arbeitsspeicher erreicht?

No CRC

Auch das ist ja erschütternd. Aber hier nicht relevant, da die Kommunikation mit dem Hardy Rechner funktioniert ja auch mitm dem identischen Kabel.

Dann habe ich hier noch basic Transfer Informationen gefunden:

Command String (Master PC) ---> Slave VMC
Master PC <--- ACK (13H)
Master PC <--- Report String
Master PC ---> ACK (13H)

Da ich selbst hier länger überlegen musste wie das gemeint ist beschreib ich das nochmal: Controll PC sendet Command (zb STATVEND) an VMC (Automat) und dieser bestätigt Empfang mit dem ACK (13H). Erst dann liefert der Automat einen Report String (VNDHS000 oder VNDOK000) Am Ende liefert der PC nochmal ein ACK um dem Automaten den Empfang zu bestätigen.

Kurzer Vergleich mit Lifeausgabe:

< 0x53 (S)
< 0x54 (T)
< 0x41 (A)
< 0x54 (T)
< 0x56 (V)
< 0x45 (E)
< 0x4e (N)
< 0x44 (D)
< 0x0d
> 	0x0d
> 	0x56 (V)
> 	0x4e (N)
Error writing to frontend device: Broken pipe
closing down everything

PC schickt STATVEND und quittiert mit ACK. Automat bestätigt Empfang mit ACK und sendet Antwort. Von der Antwort kommt nur ein Teil an bis die Verbindung abschmiert. Also läuft es bis hier hin wie in der Doku beschrieben.

Gibt es config Files für die Einstellungen von den Timeouts der USB und TTY Schnittstelle? Oder muss man das dem Datenblatt des Motherboards entnehmen?

So meine Hardy CD ist fertig, ich teste den Spass nun mal aus.

Dennis

track

Avatar von track

Anmeldungsdatum:
26. Juni 2008

Beiträge: 7174

Wohnort: Wolfen (S-A)

Dieses "Maximum Timeout to acknowledge command: 100ms (ACK 13H)" könnte interessant sein,
falls sich daran eine Einstellung für den tty-Port (oder USB) des Rechners orientiert.
(konkret: im Rechner den Timeout für diese Schnittstelle durchweg auf 200 ms setzen ?)

Überhaupt ist der Timeout für tty und auch USB eine reine Softeware-Angelegenheit.
(also irgendwo einzustellen, in irgendwelchen configs bei Linux. ... aber frag mich jetzt nicht wo genau ! )

Das wäre jetzt die Frage, wo stellt man diese Parameter ein ?
- und das wäre ja wohl auch der nächste sinnvolle Schritt.

track

Arluen

(Themenstarter)

Anmeldungsdatum:
2. März 2010

Beiträge: 17

Endlich mal gute Nachrichten!

Mit der Ubuntu 8.04.4 Life CD funktioniert es auf dem Rechner einwandfrei.

Das heist, die Fehlerquelle kann auf Änderungen zwischen 8.04.4 und 9.10 eingegrenzt werden. Natürlich sind diverse Timeout Einstellungen immer noch eine Option. Hier habe ich viel gegooglet und auch mein komplettes System nach tty und usb Files via find durchsucht. Ich habe alle Dateien betrachtet und keine Config gefunden.

Aber ich habe folgendes gemacht: http://forums.reprap.org/read.php?12,4546

Ich habe vermutet, dass der Treiber vielleicht

a) inkorrekt / veraltet oder so eine Art Mini Standardtreiber ist b) Bei richtigem Treiber eine Möglichkeit bietet die Timeouts einzustellen

Leider liefert dmesg mir nach der modprobe Anweisung keinen neuen Eintrag. Erwartet habe ich aber:

usbcore: registered new interface driver usbserial_generic 

Diesen Eintrag habe ich in älteren Logs gefunden. Möglich, dass Ubuntu den nicht automatisch ersetzt wenn ich den erneut einfüge? Wenn ja, wie kann ich den alten Treiber rausschmeissen bevor ich den neuen lade?

Auch wenn das Problem nun erledigt ist, da ich nun als Systemrequirements Ubuntu 8.04.4 LTS angebe, ist es dennoch wichtig und auch interessant zu erfahren, wieso das nicht funktioniert. Ich werde mir einen weiteren Testrechner mit 9.10 installieren um weiter zu lokalisieren was da los ist. Es wird nur etwas dauern, da zeitnah eine Deadline eintritt wo gewisse Meilensteine erreicht sein müssen. Also gebe ich nun Vollgas ☺

Ich danke euch allen für die Hilfe und die Tips und hoffe ihr verfolgt das hier weiter ☺

Grüße Dennis

track

Avatar von track

Anmeldungsdatum:
26. Juni 2008

Beiträge: 7174

Wohnort: Wolfen (S-A)

Na ja, möglicherweise kann man das auch ganz einfach unter "Kinderkrankheiten von Uby 9.10" buchen,
davon gibt es ja eine ganze Menge. (schließlich wurde dort so ziemlich die gesamte Hardware-Erkennung auf udev umgestellt)

Und ansonsten die alte Weisheit: für Produktivumgebungen im Zweifel immer die "LTS-Version" (Long Term Support) nehmen,
und die auch erst ½ Jahr nach ihrem Erscheinen (dann sind die gröbsten bugs raus).
Dann ist man in puncto Stabilität auf der sicheren Seite.

Bei den Treibern gilt die Regel: immer möglichst aus dem Repo nehmen (per synaptic), sonst handelt man sich
durchaus überraschende Konfigurationshürden ein, oder sogar Unverträglichkeiten.

Und was dann die Konfiguration angeht, da gibt es im Gegensatz zu Win.. üblicherweise keinen Vorteil,
wenn man da was aus fremder Quelle holt. Im Gegenteil, die Standard-Treiber sind in der Regel unglaublich weitgehend konfigurierbar.
Man muss nur heraus bekommen, wie das geht ...

Einen falschen Treiber würdest Du normalerweise daran erkennen, dass er entweder gar nicht erst lädt, oder sonst nicht funktioniert.
(also, das trifft bei Dir wohl nicht zu ☺ )

Vielleicht kannst Du mit setserial da was tweaken ? - kannst Du ja mal probieren.
(Info: http://packages.ubuntu.com/de/hardy/setserial und http://linux.die.net/man/8/setserial )
Installation aber wie gewohnt über synaptic !

track

Arluen

(Themenstarter)

Anmeldungsdatum:
2. März 2010

Beiträge: 17

Ah ok hatte es nun erst über aptitude installiert,

nachher aber über Synaptics verglichen und lt. Versionsnummer ist es die gleiche Version. Leider kann er meinen ttyUSB0 nicht auslesen:

1
2
ubuntu@ubuntu:~/Desktop/interceptty-0.6$ setserial -a /dev/ttyUSB0 
Cannot get serial info: Invalid argument

Zum Test habe ich mal meinen S0 ausgelesen:

1
2
3
4
5
ubuntu@ubuntu:~/Desktop/interceptty-0.6$ setserial -a /dev/ttyS0
/dev/ttyS0, Line 0, UART: 16550A, Port: 0x03f8, IRQ: 4
	Baud_base: 115200, close_delay: 50, divisor: 0
	closing_wait: 3000
	Flags: spd_normal skip_test

Also funktionieren tut das Programm, nur den USB Port mag es nicht, auch wenn es nur ein serial2usb Adapter ist ☹

Antworten |