Rote Fehler LED, stehende beams

Forum zum Pojekt: bILDA -
"bil"liger "DA"-Wandler mit ILDA ISP Ausgang

Moderator: afrob

Gesperrt
Benutzeravatar
sanaia
Beiträge: 812
Registriert: So 20 Jun, 2004 5:49 pm

Rote Fehler LED, stehende beams

Beitrag von sanaia » Sa 16 Jul, 2005 7:56 pm

Hallo,

auch wenn hier leider nicht mehr viel los ist bin ich mal so frei zwei weitere bugs zu melden, die mir bei bILDA zusätzlich zu dem EEPROM problem aufgefallen sind:

a) Egal ob ich mit 'bildatest' oder meiner eigenen software etwas über die karte ausgebe, es geht *immer* die rote fehler led an und in /var/log/messages stehen auch jede menge buffer underrun messages. Wie gesagt, der fehler tritt auch mit der originalsoftware auf, egal ob ich nur das testbild (kreis), oder ein ILDA ausgebe.

b) Fehler nummer zwei, der vermutlich damit zusammenhängt ist, daß die ausgabe sporadisch hängt und damit stehende strahlen erzeugt - insbesondere wenn ich versuche fehler (a) zu vermeiden und die frames so schnell wie möglich an die karte sende häuft sich dieser fehler extrem. In der x-t betriebsart des oszis sieht es so aus, als ob die ausgabe stottert. Die frameausgabe wird mehrere male nacheinander gestartet, abgebrochen und neugestartet. Beim zweiten oder dritten versuch klappt es dann und der frame wird ganz ausgegeben.

Anscheinend ist das ganze aber nicht unbekannt:
www.linux-laser.org hat geschrieben:bILDA ist nicht dafür geeignet einen Laserstrahl der Laserklasse III oder höher in das Publikum zu lenken, da dies erforden würde das die bILDA-Software absolut fehlerfrei ist.
Es wäre nur interessant zu wissen, ob dafür ein bugfix geplant ist ?
* godsh # ERROR 406: file corrupt: config.earth --- reboot universe? (Y/N) *

Benutzeravatar
afrob
Beiträge: 995
Registriert: Mo 05 Aug, 2002 12:00 pm
Do you already have Laser-Equipment?: RayComposer NET und RayComposer USB
Wohnort: Frankfurt am Main, Germany
Kontaktdaten:

Re: Rote Fehler LED, stehende beams

Beitrag von afrob » Mo 18 Jul, 2005 9:14 pm

sanaia hat geschrieben:a) Egal ob ich mit 'bildatest' oder meiner eigenen software etwas über die karte ausgebe, es geht *immer* die rote fehler led an und in /var/log/messages stehen auch jede menge buffer underrun messages. Wie gesagt, der fehler tritt auch mit der originalsoftware auf, egal ob ich nur das testbild (kreis), oder ein ILDA ausgebe.
Mir ist schon aufgefallen, dass bILDA sich an speziellen USB-Controllern merkwürdig benimmt. Allerdings nicht in diesem Umfang.
Was steht in /var/log/messages denn genau?
sanaia hat geschrieben:b) Fehler nummer zwei, der vermutlich damit zusammenhängt ist, daß die ausgabe sporadisch hängt und damit stehende strahlen erzeugt - insbesondere wenn ich versuche fehler (a) zu vermeiden und die frames so schnell wie möglich an die karte sende häuft sich dieser fehler extrem. In der x-t betriebsart des oszis sieht es so aus, als ob die ausgabe stottert. Die frameausgabe wird mehrere male nacheinander gestartet, abgebrochen und neugestartet. Beim zweiten oder dritten versuch klappt es dann und der frame wird ganz ausgegeben.
Sehr merkwürdig. Das deutet daruf hin, dass der USB-Controller die Pakete gar nicht / nicht in der richtigen Reihenfolge sendet. Wie schnell die Software die Frames sendet sollte sich nicht in der Ausgabe niederschlagen. Du benutzt das 2.6-Kernelmodul? Wie schnell ist der Rechner?
sanaia hat geschrieben:Anscheinend ist das ganze aber nicht unbekannt:
www.linux-laser.org hat geschrieben:bILDA ist nicht dafür geeignet einen Laserstrahl der Laserklasse III oder höher in das Publikum zu lenken, da dies erforden würde das die bILDA-Software absolut fehlerfrei ist.
Das steht da vor allem aus haftungsrechtlichen Gründen. Ich möchte nicht von jemandem verklagt werden, der etwas von "konstanter Geschwindigkteit" gelesen hat, dann meint Beamshows mit beliebiger Laserleistung machen zu können und sich dabei die Augen 'rausballert. Da wird schnell mal ein Schuldiger gesucht und ich möchte für ein Open-Hardware-Projekt keine Produkthaftplichtversicherung abschliessen.

Grüsse,
afrob

isolux
Beiträge: 4
Registriert: Di 31 Mai, 2005 11:54 pm
Wohnort: 42799 Leichlingen/Germany
Kontaktdaten:

Stehender Strahl / Bug in Firmware

Beitrag von isolux » Mo 25 Jul, 2005 3:59 pm

Hallo zusammen,
ich habe - dank intensiver Hilfe von sanaia - bildatest unter Kernel 2.6 laufen. Bei mir bleibt nach willkürlicher Zeit (mal 10 s, mal über eine Minute lang) der Strahl einfach auf den Koordinaten 0,0 stehen und bildatest "merkt" das nicht. (Sowohl das Testpattern als auch z.B. tux.ild) Ich muß mit Taste q bildatest beenden und Neustarten. Danach laufen die Ausgaben wieder eine Zeit lang.
In "messages" sind folgende Meldungen/Hinweise zu finden:
../bilda.c: num is: 176
../bilda.c: bILDA opened
setting speed to 12000 pps
../bilda.c: bilda error: next frame not ready, repeating frame 1
../bilda.c: bilda error: next frame not ready, repeating frame 1
../bilda.c: bilda error: next frame not ready, repeating frame 1
../bilda.c: bilda error: next frame not ready, repeating frame 1
../bilda.c: bilda error: next frame not ready, repeating frame 1
error: could not submit urb: -32 error: could not submit urb: -32<6>/.../bilda.c: bILDA closed.


Ich hoffe, dass euch das ein wenig weiterhilft.

Grüße
Michael

Benutzeravatar
sanaia
Beiträge: 812
Registriert: So 20 Jun, 2004 5:49 pm

Re: Rote Fehler LED, stehende beams

Beitrag von sanaia » Do 28 Jul, 2005 8:47 pm

afrob hat geschrieben:Sehr merkwürdig. Das deutet daruf hin, dass der USB-Controller die Pakete gar nicht / nicht in der richtigen Reihenfolge sendet. Wie schnell die Software die Frames sendet sollte sich nicht in der Ausgabe niederschlagen. Du benutzt das 2.6-Kernelmodul? Wie schnell ist der Rechner?
kernel v2.6, PIII Coppermine@700MHz, CPU load ~16%.

syslog errors bei verwendung eigener software:

Code: Alles auswählen

Jul 28 20:09:07 proxima kernel: ./devdrv/bilda_usb/bilda.c: num is: 176
Jul 28 20:09:07 proxima kernel: ./devdrv/bilda_usb/bilda.c: bILDA opened.
Jul 28 20:09:07 proxima kernel: ./devdrv/bilda_usb/bilda.c: bILDA closed.
Jul 28 20:09:07 proxima kernel: ./devdrv/bilda_usb/bilda.c: num is: 176
Jul 28 20:09:07 proxima kernel: ./devdrv/bilda_usb/bilda.c: bILDA opened.
Jul 28 20:09:07 proxima kernel: setting speed to 24000 pps
Jul 28 20:09:07 proxima kernel: setting speed to 48000 pps
Jul 28 20:09:09 proxima kernel: ./devdrv/bilda_usb/bilda.c: bilda error: next frame not ready, repeating frame 1
Jul 28 20:09:11 proxima kernel: ./devdrv/bilda_usb/bilda.c: bilda error: next frame not ready, repeating frame 0
Keine weiteren fehler im syslog die auf irgendwelche kernel/treiber/hardwareprobleme hinweisen. Seltsamerweise geht die rote LED aber auch an, ohne daß im syslog irgendein fehler notiert wird (bildatest -s 24k -t).
* godsh # ERROR 406: file corrupt: config.earth --- reboot universe? (Y/N) *

isolux
Beiträge: 4
Registriert: Di 31 Mai, 2005 11:54 pm
Wohnort: 42799 Leichlingen/Germany
Kontaktdaten:

Beitrag von isolux » So 07 Aug, 2005 7:56 pm

Hallo ,
der Rechner ist ein Notebook: HP omnibook xe4500 mit P4/1,6GHz u. 512 MB Ram. Soweit ich weiß, passiert das nur mit dem 2.6er Kernel. Ich hatte das vorher mit der selben Hardware und SuSE 8.2 (2.4er Kernel) problemlos am Laufen. Zu bemerken ist jedoch, dass ich bei der 2.4er Version mit dem Parameter NOPCMCIA=YES installieren musste, da ansonsten das Notebook immer während der Linux-Installation "hängen" blieb. Das SuSE 9.1 habe ich dann mit PCMCIA-Unterstüzung installieren können.
Meinst Du, ich sollte das mal auf einer schnelleren Hardware bzw. NICHT auf einem Notebook installieren?

Übrigens, am Rande zu diesem Thema: Ich bin gerade dabei, die Selbstbau-Scanner - wie unter http://elm-chan.org/works/vlp/report_e.html beschrieben - zu bauen. Falls euch das Ergebnis interessiert, so kann ich gerne ein Feedback geben. In diesem Forum bin ich darauf gestoßen...

sevenofnine
Beiträge: 21
Registriert: Fr 07 Nov, 2003 2:27 pm
Do you already have Laser-Equipment?: LOBO AMP2/3
G120D- Blanking
Lumax
Wohnort: Wewelsburg
Kontaktdaten:

Beitrag von sevenofnine » Mi 01 Feb, 2006 3:56 pm

So...seit heute habe ich auch meine Karte fertig und versuche Sie mit Suse10 zum laufen zu bewegen.....bin jetzt jedoch an einem toten Punkt angekommen.
Vorgehensweise :

1.wie auf linux-laser Website beschrieben bis zum punkt Initialisierung
--soweit ich das verfolgen konnte ohne Fehler--
2.das Suse10 rpm-installliert
3 Initialisierung durchgeführt...ging erst nicht da die Datei bilda.o nicht existierte nur eine Datei bilda.ko ...habs mit der Versucht und es gab keine Fehlermeldung (War das schon mein fataler Fehler??)
4 Programmierung des EEPROM lief super durch....soweit ich das sehen konnte auch ohne Fehler
5 nach der Programmierung blieb die Rote-LED aber IMMER an !!!????
6. Versuch der Ausgabe von Bildern tux.ild (ohne Scanner und Oszi -hab ich leider noch nicht-) ....gab keine Fehlermeldung und die Güne-LED war am leuchten.
7 Im Log habe ich dann folgede Meldungen gefunden:

Feb 1 15:27:19 linux kernel: ll header: ff:ff:ff:ff:ff:ff:00:10:5a:c5:98:10:08:00
Feb 1 15:27:21 linux kernel: martian source 192.168.30.255 from 192.168.30.27, on dev eth1
Feb 1 15:27:21 linux kernel: ll header: ff:ff:ff:ff:ff:ff:00:0e:a6:57:da:cf:08:00
Feb 1 15:27:21 linux kernel: martian source 192.168.30.255 from 192.168.30.27, on dev eth1
Feb 1 15:27:21 linux kernel: ll header: ff:ff:ff:ff:ff:ff:00:0e:a6:57:da:cf:08:00
Feb 1 15:27:22 linux kernel: martian source 192.168.30.255 from 192.168.30.27, on dev eth1
Feb 1 15:27:22 linux kernel: ll header: ff:ff:ff:ff:ff:ff:00:0e:a6:57:da:cf:08:00
Feb 1 15:27:27 linux kernel: error: could not submit urb: -90error: could not submit urb: -90<5>usb_unlink_urb() is d
eprecated for synchronous unlinks. Use usb_kill_urb() instead.
Feb 1 15:27:27 linux kernel: Badness in usb_unlink_urb at drivers/usb/core/urb.c:461
Feb 1 15:27:27 linux kernel: [<e132099e>] usb_unlink_urb+0x4e/0x80 [usbcore]
Feb 1 15:27:27 linux kernel: [<e0fa171a>] bilda_stop_stream+0x5a/0x80 [bilda]
Feb 1 15:27:27 linux kernel: [<e0fa1cab>] bilda_ioctl+0x38b/0x6a0 [bilda]
Feb 1 15:27:27 linux kernel: [<c023e189>] read_chan+0x2c9/0x6e0
Feb 1 15:27:27 linux kernel: [<c0120aba>] current_fs_time+0x4a/0x70
Feb 1 15:27:27 linux kernel: [<c0239712>] tty_read+0x92/0xb0
Feb 1 15:27:27 linux kernel: [<e0fa1920>] bilda_ioctl+0x0/0x6a0 [bilda]
Feb 1 15:27:27 linux kernel: [<c0169a9e>] do_ioctl+0x4e/0x60
Feb 1 15:27:27 linux kernel: [<c0169baf>] vfs_ioctl+0x4f/0x1c0
Feb 1 15:27:27 linux kernel: [<c0169d57>] sys_ioctl+0x37/0x70
Feb 1 15:27:27 linux kernel: [<c0102d1b>] sysenter_past_esp+0x54/0x79
Feb 1 15:27:27 linux kernel: usb_unlink_urb() is deprecated for synchronous unlinks. Use usb_kill_urb() instead.
Feb 1 15:27:27 linux kernel: Badness in usb_unlink_urb at drivers/usb/core/urb.c:461
Feb 1 15:27:27 linux kernel: [<e132099e>] usb_unlink_urb+0x4e/0x80 [usbcore]
Feb 1 15:27:27 linux kernel: [<e0fa171a>] bilda_stop_stream+0x5a/0x80 [bilda]
Feb 1 15:27:27 linux kernel: [<e0fa1cab>] bilda_ioctl+0x38b/0x6a0 [bilda]
Feb 1 15:27:27 linux kernel: [<c023e189>] read_chan+0x2c9/0x6e0
Feb 1 15:27:27 linux kernel: [<c0120aba>] current_fs_time+0x4a/0x70
Feb 1 15:27:27 linux kernel: [<c0239712>] tty_read+0x92/0xb0
Feb 1 15:27:28 linux kernel: [<e0fa1920>] bilda_ioctl+0x0/0x6a0 [bilda]
Feb 1 15:27:28 linux kernel: [<c0169a9e>] do_ioctl+0x4e/0x60
Feb 1 15:27:28 linux kernel: [<c0169baf>] vfs_ioctl+0x4f/0x1c0
Feb 1 15:27:28 linux kernel: [<c0169d57>] sys_ioctl+0x37/0x70
Feb 1 15:27:28 linux kernel: [<c0102d1b>] sysenter_past_esp+0x54/0x79
Feb 1 15:27:28 linux kernel: /usr/src/packages/BUILD/bilda-0.03/kernel/bilda.c: bILDA closed.
Feb 1 15:27:29 linux kernel: martian source 255.255.255.255 from 192.168.30.58, on dev eth1

Was stimmt da nicht im Log und warum brennt wohl die ganze Zeit die rote LED?????

Danke im vorraus für eure Hilfe.

CU

oliver
Gleich reg ich mich auf....!!! :)

Benutzeravatar
afrob
Beiträge: 995
Registriert: Mo 05 Aug, 2002 12:00 pm
Do you already have Laser-Equipment?: RayComposer NET und RayComposer USB
Wohnort: Frankfurt am Main, Germany
Kontaktdaten:

Beitrag von afrob » Sa 04 Feb, 2006 2:01 pm

Hallo Oliver,
SevenOfNine hat geschrieben:3 Initialisierung durchgeführt...ging erst nicht da die Datei bilda.o nicht existierte nur eine Datei bilda.ko ...habs mit der Versucht und es gab keine Fehlermeldung (War das schon mein fataler Fehler??)
das ist schon richtig, seit Kernel 2.6 heissen die Module *.ko anstatt *.o.
SevenOfNine hat geschrieben: 5 nach der Programmierung blieb die Rote-LED aber IMMER an !!!????
6. Versuch der Ausgabe von Bildern tux.ild (ohne Scanner und Oszi -hab ich leider noch nicht-) ....gab keine Fehlermeldung und die Grüne-LED war am leuchten.
Noch mal langsam, das verhalten sollte wie folgt sein:
1. bILDA wird mit der Stromversorgung verbunden, die Power LED (blau) leuchtet.
2. bILDA wird am USB erkannt, die grüne LED leuchtet.
3. Wenn die Ausgabe gestartet wird geht der Shutter auf, das zeigt die gelbe LED an.
4. Sendet der PC dauerhaft zu wenig Daten geht die rote LED an und der Shutter geht zu (gelbe LED aus).

Der status der grünen LED ist also unabhängig davon, ob die Ausgabe läuft oder nicht. Die rote LED kann erst angehen, wenn die Ausgabe gestartet wurde. Wenn du bILDA mit der Stromversorgung, aber nicht dem USB verbindest dürfen weder rote noch grüne noch gelbe LED leuchten. Falls doch ist etwas bei den LEDs (Reihenfolge?) oder den Transistoren / Widerständen zur Ansteuerung der LEDs faul.
SevenOfNine hat geschrieben:7 Im Log habe ich dann folgede Meldungen gefunden:
Feb 1 15:27:27 linux kernel: error: could not submit urb: -90error: could not submit urb: -90<5>usb_unlink_urb() is deprecated for synchronous unlinks. Use usb_kill_urb() instead.
OK, ich sollte im Kernelmodul die Funktion usb_kill_urb() anstatt usb_unlink_urb() benutzen; das isit aber nur eine Warnung, keine Fehlermeldung. "could not submit urb" scheint nur beim Beenden der Ausgabe aufzutreten?

Grüsse,
afrob

Gesperrt

Zurück zu „OpenProject: bILDA“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast