Erfolg der Woche

[Searcher]

Jetzt hab ich doch einen verloren geglaubten alten Flachbettscanner MD-42666 wieder zum Scannen gebracht. Die Scaneinheit fuhr beim Vorschauscannen aus der Ruhestellung bis zum anderen Ende, machte unschöne Geräusche und fuhr nicht wieder zurück. Befand sich die Scaneinheit beim Einschalten nicht in Ruhestellung, fuhr sie auch nicht dorthin. Machte ein paar Geräusche und blieb nach kleinen Bewegungen stehen.

Ursache war die Gabellichtschranke, die in Ruhestellung des Scanschlittens unterbrochen wird. Nur hier gaukelte sie der Elektronik dauernd eine Unterbrechung, was Scanschlitten in Ruhestellung bedeutet, vor. Beim Messen mit dem DMM reagierte sie zwar auf unterbrechen und freigeben des Lichtstrahls aber nicht stark genug. Sie zog den Ausgang bei nicht unterbrochenem Lichtstrahl nicht stark genug nach GND. IR-LED und Fototransistor sind durch eine schwarze Abdeckung mit schmalen Schlitzen abgedeckt.

Durch ein wenig Aufweiten der Schlitze kam dann genug Licht durch, meldet wieder wenn der Scanschlitten nicht in Ruhestellung ist und nun funktioniert und scannt er wieder normal

Das Teil lag schon Jahre in der Ecke und sollte eigentlich als Bauteilspender dienen.

Gruß
Searcher

[Holomino]

Eine Hürde auf dem Weg zur Implementierung eines SLAMS auf dem ESP32 genommen:

Das Problem: Der ESP hat ja nicht unbedingt endlos RAM. Entsprechend der Plan, nur den Teil der Map zu laden, der sich von der aktuellen Position ausgehend in Sensorreichweite befindet. Wie aber animiert man den Pathfinder dazu, ohne größeres Speichergerödel Wege zu nicht geladenen Kartenteilen zu generieren?

Meine Lösung: Unterteile ich die Karte in Kacheln (z.B. hier 8x8 Rasterpunkte), kann ich recht einfach die Ports (blaue Punkte = Überschneidung freier Rasterpunkte an der Kante zweier benachbarter Kacheln) zu den Nachbarkacheln finden und auch innerhalb einer Kachel die Portverbindungen (blaue Linien, zu finden über einen auf eine Kachel begrenzten Dijksta) erzeugen. Letztlich der Plan dahinter, nur noch einige hundert Objekte (das Portnetz) statt zigtausende von Rasterpunkten zur Wegsuche im Speicher zu halten.

[Holomino]

Neue Woche, neuer Erfolg.

Nun das Portnet auf den inneren Bereich beschränkt und am realen Roboter getestet.

[oberallgeier]

Erfolg der Woche wäre schon übertrieben - aber ne andere Spalte passt noch weniger. Und die Suche bringt bei "vorher, nachher" diesen Thread an zweiter Stelle . . .

Vorher: seit etwa dreissig Jahren liegt in der Krimskramsschublade ne "Notfalltaschenlampe" - MINI MAGLITE, also sehr schickes, sehr griffiges Design im Format eines dicken Füllhalters: L 130 mm, D 19 mm, 49 g, 2xAAA (129,27/18,67/48,87). Leuchtmittel ist ne Miniglühlampe Ø3mm, L 10 mm(Glaskörper) + 6mm(Kontaktstifte). Stromaufnahme siehe unten.

Aufbau aus Langeweile und Neugier mit einer LED, farblos - später testweise rt, Ø3 mm, 20mA 3-3,2V, Chinateilchen, die beiden AAA liefern zusammen aktuell (fast neu) 2,90 V. Gefühlt ist die Leuchtstärke von Glühbirnchen und LEDwt gleich (sowohl mit AAA als auch NT), Leuchtfarbe mit LED kaltweiß gegenüber warmweiß beim Glühlämpchen. Messung der Leuchtstärke mit einem alten Belichtungsmesser (gleiche Messergebnisse beim Test mit ner alten NIKON D80 digital) der auf 50 mm Abstand vor dem Leuchtmittel lag. Stromquelle für die Tests war mein Labornetztel KORAD 3005D.

Testergebnis bei: 2,90 V ..... EV^*) ... 2,20 V
Glühlmp: ..... ... 0,320 A .... 11
LED wt: ...... ....0,009 A ....10/11
LED rt:......................... .. 10+ .... 0,049

*) EV ist ne alte, vermutl. amerik. Größe. EV entspricht bei 100 ASA:
10 =>> . 1/60 sec bei f 4
11 =>> 1/125 sec bei f 4

Fazit:
- Leuchtdauer mit 2 Stk AAA und Glühbirne ca. 2..3 Stunden, mit LEDwt ca. 2..3 Tage. An sich - nicht überraschend.
- Leider kann die rote LED bei 2xAAA nicht ohne Vorwiderstand benutzt werden - aber der deutlich höhere Stromverbrauch, fast 5 mal, für vergleichbare Helligkeit überrascht schon. Da ist auch ein Ausweichen auf AAA-Akkus nicht sinnvoll.

[021aet04]

Anscheinend hat schon lange keiner mehr einen Erfolg gehabt

Mein Erfolg der Woche ist, ich habe ein Metrix OX710C repariert.

Ein Bekannter hat in der Firma, in der er arbeitet ein Oszilloskop beim Elektroschrott gefunden. Ich habe gesagt das er es mitnehmen soll.
Frei nach dem Motto "Wegwerfen kann man es immer noch".

Ich habe es getestet und leider hat es nicht funktioniert, als ob es keine Versorgung gibt.
Nach ein paar Messungen habe ich festgestellt das die +12V nicht vorhanden waren.

Im Endeffekt hatte der Elko der +12V Versorgung (Eingangsseite) einen Kurzschluss. Zum Test habe ich einen 2200uF/35V Elko genommen (Original 1000uF/35V), da ich den hier hatte. Jetzt muss ich schauen ob ich den richtigen habe und diesen auswechseln. Die anderen werde ich aber auch noch tauschen.

Ergebnis:


Das Oszilloskop läuft wieder.

MfG Hannes

[Searcher]

... Das Oszilloskop läuft wieder.

Bild hier   (Daumen hoch!)

Gruß
Searcher

[Searcher]

Aufgrund von PC HW ohne nativen Parallelport und wegen zickiger Windows Betriebssysteme, die die Parallelport Erweiterungskarten nicht so ohne Weiteres mit BASCOM-Avr nutzen lassen, verabschiede ich mich so langsam von meinem, seit "ewigen Zeiten" genutzten Parallelport Programmer. Deshalb habe ich den Thomas Fischl USBasp mit einem ATMega88A nachgebaut. Der Erfolg liegt aber nicht in dem erfolgreichen Nachbau sondern in der schweißerzeugenden erfolgreichen Inbetriebnahme desselben.

Irgendwo hatte sich beim Bau oder Treiberinstallation ein Bug eingeschlichen, der nicht sporadische Aussetzer sondern sporadisches Funktionieren zur Folge hatte. Kein Verdrahtungsfehler und auch der verwendete ATMega88A war OK. Der Programmer lief mal an einer WINXP Installation, mal nicht und mal lieferte er falsche Daten zB falsche µC ID. Mal wurde er von WINXP als fehlerhaftes USB Device gemeldet, das nächste Mal erkannte der USBasp den angeschlossen µC nicht. Dann lief auch wieder, wenn auch selten, alles. Getestet an WINXP SP3 32Bit und Bascom Demo Version.

Verdrahtung war OK. Alles nachlöten, Unterbrechungen in der Lochrasterplatte nacharbeiten, Programmierung des µC überprüfen, externen Takt mit Lastkondensatoren am Resonator möglichst nah an die vorgegebenen 12MHz bringen, Platine mechanisch verwunden um Wackler aufzuspüren, mit Fuses für die Taktquelle experimentieren, Serienwiderstände zur Programmierschnittstelle aus- und einlöten, USB Kabel tauschen, verschiedene WIN-Treiber probiert. Nix half.

Am Ende von Tag Eins der Fehlersuche lief es dann plötzlich und auch an Tag Zwei scheint das Ding stabil zu laufen. Bei der vielen Rumprobiererei macht man auch mal Fehler, die einen auf eine falsche Färte führen und nun kann ich nicht mal sagen, wo sich der Bug versteckt hatte.

Aber ich hab jetzt einen Programmer für Bascom der über USB Port betrieben wird . (Allerdings steht Test an WIN11 64Bit und WIN7 64Bit noch aus ).


Gruß
Searcher