Archive for December, 2013

Home Cockpit Baubericht (Teil 4)

Sunday, December 29th, 2013

Todo Liste vom 26.12.

* Entprellen der Taster – DONE
* Abfrage aller Inkrementalgeber – DONE
* serielle USB Kommunikation mit dem PC, – serial out:DONE
* bidirektional – not yet
* “Treiber” Software auf dem PC – DONE

Zwischendurch hatte ich etwas Stress mit meinen usbisp Programmieren. Plötzlich konnte ich nicht mehr flashen. Nachdem ich die ISP Anschlüsse von dem 20cm Kabel welches zu 2 Rotary Encodern geht, befreit habe, ging’s wieder.
Etwas später wurde der bei hobbyking gekaufte usbisp sehr warm und wollte auch nicht mehr flashen?!
Mein selbst gebauter usbisp funktioniert wieder – auch nachdem ich PB4(SS) und PB5(MOSI) wieder als Eingang für einen Rotary Encoder benutze.

Gestern habe ich ein python script geschrieben welches Werte vom Panel via serial USB empfängt, interpretiert und per telnet an Flightgear weiterleitet.

Heute fand ich eine schöne Lösung um COM und NAV Frequenzen einzustellen.

Home Cockpit Baubericht (Teil 3)

Thursday, December 26th, 2013

Am 23.12. kamen endlich die Inkrementalgeber(rotary encoder). Seit dem weiß ich, wie groß ich die Löcher dafür bohren muss. Am gleichen Tag habe ich alle Taster und Schalter eingebaut und 2 von den insgesamt 6 Inkrementalgebern mit meinen C-Testprogramm auf den Atmega32 ausprobiert.

Am 24.12. habe ich mit der Tastaturmatrix angefangen. Zunächst nur 3×3 verkabelt und dann dafür ein Testprogramm geschrieben. 3 der Schalter hatte ich aus alten Walkera Sendern ausgeschlachtet – sie sehen schön aus – sind aber alle defekt. Ich musste alle wieder ausbauen. 🙁

Den 25.12. habe ich damit verbracht, den Rest der 8×7 Matrix und die LEDs zu verkabeln. Die Taster von Rafi haben eine rote 3mm LED in der Ecke – ich hätte aber lieber eine flächige Beleuchtung in grün. Kurz vor dem verkabeln der LEDs habe ich mich entschlossen die roten LEDs nicht zu verwenden und stattdessen superhelle grüne LEDs von hinten an die Taster zu kleben. Mit einem 460 Ohm Vorwiederstand sind es nur 6mA pro LED – Das schafft der 74HC595 ohne zusätzlichen Treiber.

Bis auf Kleinigkeiten (Deckel, Rückwand, ..) ist die Hardware nun fertig. In der Software folgt demnächst:

* Entprellen der Taster
* Abfrage aller Inkrementalgeber
* serielle USB Kommunikation mit dem PC, bidirektional
* “Treiber” Software auf dem PC

pic

p2

p3

74HC595

p5

CNC Fräse im Unperfekthaus

Tuesday, December 17th, 2013

Für mein “home-cockpit” Projekt möchte ich eine bedruckte Frontplatte mit diversen Löchern und Ausschnitten für Displays, Schalter und Taster herstellen. Das ist genug Motivation, um mich mal intensiver mit der CNC-Fräse im Unperfekthaus zu beschäftigen.

Die Fräse wird momentan von einen DOS PC mit der DOS-Software “PCNC” gesteuert. PCNC kann HPGL und G-Code Dateien öffnen.

Ein reines, klassisches MS-DOS oder PC-DOS hat kein Netzwerk und auch keine USB-Sticks lesen und unsere heutigen Rechner haben kein Disketten-Laufwerk. Also wie kommt die Datei in den Rechner ?
Der umständliche Weg war: Erst Kanotix Linux booten, die Datei vom USB-Stick auf die “C:” Partition kopieren und dann DOS booten. Sind Änderungen an der Datei nötig, dann geht diese Spiel wieder von vorne los – sehr umständlich!

Das haben wir heute geändert. Ich habe gelernt, dass auf C: nicht nur DOS sondern auch Windows98 installiert ist – Das gibt Hoffnung auf Netzwerk-Konnektivität. Also schnell eine Netzwerkkarte eingebaut und den nötigen Treiber per Linux auf die C:-Platte kopiert. Treiber installiert, obligatorischer Reboot, … Hurra! ping funktioniert! 😉
und jetzt ? smb(samba) klappte nicht auf Anhieb, und wo ist der IE ? – jedenfalls nicht im Startmenu oder Startleiste. Damals waren “Windows-Explorer” und “Internet Explorer” das gleiche Programm. Mir gelang es irgendwie diesen “Internet Explorer” zu starten und konnte dann vom meinem Apache http Server weitere Programme installieren: WinSCP und Firefox 2.0 damit wir ab sofort unsere Fräs-Dateien per scp oder http auf den Fräsrechner kopieren können.

Der Fräs-Rechner hat momentan noch keine feste IP. Er verrät seine IP per “command” (cmd geht nicht!) und dann “ipconfig”

Meine Frontplatte habe ich mit Inkscape gestaltet. Sie ist 480mm breit. Der maximale Arbeitsbereich der Fräse ist:
X: 240mm
Y: 350mm
Ich habe also zunächst mal die Elemente entfernt, die nicht in der Arbeitsbereich passen. Und ich habe die Platte um 90° gedreht, schließlich ist Arbeitsbereich in diese Richtung 10cm größer.
Das war keine gute Idee, denn so “quer” passt das Werkstück nicht mehr durch das Portal der Fräse. Das Maximum ist hier 430mm
Also in Inkscape wieder 90° zurück gedreht. PCNC kann so etwas (Achsen X und Y tauschen) offenbar nicht.
Was PCNC auch nicht macht: die Dicke des Fräskopfes beachten. Also musste ich in Inkscape alle Ausschnitte 0,75mm (Fräskopfdurchmesser/2) kleiner machen, damit sie korrekt gefräst wurden.
Meine Version von Inkscape bot 2 Varianten von HPGL an:
* HPGL Plot File (*.plt)
und
* HPGL (.hpgl)
Beim ersten gab es diverse uniconverter-Fehlermeldungen. Das zweite bietet ein paar Optionen und speichert dann eine Datei, die PCNC öffen kann. Falls Objekte in der PCNC Vorschau nicht erscheinen hat man in Inkscape vermutlich “Object to Path” vergessen.

Nach dem wir das Werkstück eingespannt und in PCNC den Arbeitsbereich und den Nullpunkt definiert haben, begannen die Probe-Läufe 1-3. Erster Testlauf 10cm über den Werkstück, zweiter Testlauf 2cm über dem Werkstück, dritter Testlauf 1mm über dem Werkstück. So konnten wir uns versichern, dass nicht in die Werkstück-Halterungen gefräst wird und schon mal abschätzen, ob die Dimensionen auch stimmen. Den Skalierungsfaktor 2,54 (in PCNC) hatten wir anhand der Vorschau (richtig) geschätzt/erraten. Beim speichern in inkscape habe ich den default-Wert 1016 dpi unverändert gelassen.

Soweit so gut. Mit 0,33mm Zustellkorrektur konnten wir dann endlich “richtig” fräsen – aber leider nur bis max 1,5mm Tiefe. Bei HPGL Dateien bewegt sich die Z Achse zwischen den einzelnen Ausschnitten nur minimal auf und ab. Das kann man in PCNC scheinbar auch nicht ändern 🙁 Hätten wir weiter gemacht, wäre die Frontplatte zerkratzt worden. Übrigens war die HPGL Datei aus Inkscape spiegelverkehrt, das konnte man schon in der PCNC Vorschau sehen. Wir haben also die Rückseite der Platte gefräst.

Möchte man auf Z-Achse mehr Einfluss, dann muss man statt HPGL G-Code verwenden. Diverse Programme haben es leider nicht geschafft aus unserer HPGL Datei brauchbaren G-Code zu erzeugen – Eigentlich keine schwere Aufgabe. Auch mit der Inkscape Extension “Gcodetools” kamen wir zunächst nicht klar. Diese Extension hat Inkscape mehrfach zum Absturz gebracht. Sonst läuft Inkscape völlig stabil.
Später abends zu hause hat die Gcodetools Extension das erste Mal eine G-Code Datei erzeugt, die ganz brauchbar aussieht. Möglicherweise muss ich in inkscape alle Ebenen, die ich nicht fräsen möchte, vor dem G-Code Export löschen.

Das war ein interessanter Fräs-Tag. Beim nächsten Mal werde ich G-Code probieren. Falls das nicht klappt, könnte man vielleicht statt der kompletten Frontplatte einzelne Ausschnitte in einzelne Dateien speichern und dann 1x das Werkstück und mehrmals den Nullpunkt manuell verschieben um die Ausschnitte an den gewünschten Stellen zu fräsen(“pen down”) ohne dass der Fräskopf zwischen mehreren Objekten wandern muss (“pen up”)

Langfristig werden wir versuchen, DOS & PCNC durch die freie Linux-Software http://www.linuxcnc.org/ (“EMC”) zu ersetzten.

Home Cockpit Pt.2: many IOs

Thursday, December 12th, 2013

I counted the number of IO Pins that I need for all the display,LEDs, buttons and switches. Without additional chips it would be: 57 input and 32 output. That’s too much, even for a Mega2560. So I was thinking about various options like…

* master-slave 2 or more Atmega controllers
* separate controllers for in and out, each with it’s own USB
* shift registers (74LS164 or 74HC595) for output
* matrix for in & out
* MAX7219 for up to 64 LEDs in a matrix

Here’s my plan:
OUTPUT:
I use 2 shift-register ICs for all the Data & CE lines of the alphanumeric display
and connect A0, A1 and WR of the display direct to the controller.
I use a MAX7219 for all LEDs.
Result: a total of 8 output pins of the microcontroller.

INPUT:
I want to connect all 6 rotaray encoders directly to the microcontroller to get the best
timing, so 12 input lines for that.
For the remaining buttons & switches I use a 8×6 matrix (with 45 diodes)
To scan the 8 rows I want to use a 1-out-of-8 (3bit) binary decoder chip
Result: a total of 21 pins used for input.

With 4 additional chips I reduced the amount of needed IO pins from 89 to 29.
With the MAX7219 I have the option of adding many more LEDs If I want and on the input side I can still add 3 more switches or buttons to the matrix.

When using only one microcontoller (the Atmega32 has 30 IO + TX & RX) then I can update the display quickly when I turn the rotaries without communicating with Flightgear immediately.
I hope that USB serial is enough for everything that I want and there is no need for USB HID for this device.

UPDATE:
Yesterday I had the good(?) idea to use 4 shift registers instead of
2 shift registers + MAX7219. So I started to build a board with 4 x 74HC595 with all 32 outputs going to a 34-pin connector where I’ll plug in a ribbon cable. After finishig my board it came to my mind again what knew already but did forget:

* the max. output current of the 74HC595 is very limited (75mA per chip, 35mA per output)
* I’ll need a resistor for every LED – (which is not the case with the MAX7219)

I might get away with it because I tried a red LED with 475 ohms to 5V: It is not very bright, but needs only 6,5mA this way.
I can’t use low current LEDs because they are all integrated in the buttons.

Home Cockpit (aka Simpit)

Wednesday, December 11th, 2013

Winterzeit – Bastelzeit. Seit fast einem Jahr fliege ich nun im Flightgear Flugsimulator. Es macht sehr viel Spaß, aber manche Tastenkombinationen sind nicht so toll, z.B. ctrl-B für Speedbrakes oder AltGr-9 für Flaps. Ich könnte eine alternative keyboard.xml verwenden oder machen, allerdings sind schon fast alle Tasten mit irgendwas belegt und manche Fluggeräte haben zusätzlich noch eigene Hotkeys. Besser währen “richtige” Cockpit Instrumente, Taster, Schalter, Displays, LEDs zum anfassen, die immer im Blickfeld sind, egal wohin die virtuelle Kamera gerade schaut. Genau das baue ich gerade. EFIS, FCU und Radio Bedien- und Anzeige-Elemente in einem 19″ 3 HE Gehäuse.

Das Frontplatten-Layout mit Inkscape ist fast fertig. Es war das erste Mal dass ich produktiv mit Inkscape gearbeitet habe – Ein sehr schönes Programm. Sehr intuitiv.

Der Atmega32 steuert inzwischen zuverlässig das LED Display. Hier muss ich noch versuchen die Ports anders zu nutzen, so dass ich D0 und D1 wieder für RX und TX frei habe.


TODO

* Frontplatte Ausschnitte fräsen und Löcher bohren
* Folie farbig bedrucken und aufkleben
* Rotary Encoder mit arduino testen
* USB HID/serial mit Leonardo Pro Micro ATmega32U4 ausprobieren
* Display, Schalter, Taster, … montieren und verkabeln
* Microcontroller programmieren
* Gehäuse: Kabeldurchführung, Reset-Taste

* Throttle Quadrant mit Spoilers, Reverse und Flaps
* Analoger Flightstick ohne Zentrierung
* Toe-breakes mit Hall-Sensor ?

panel

PL2303 USB-TTL Adapter an Arduino Pro Mini:
(“null-modem-kabel”)

Adapter–Arduino
5V–Vcc
GND–GND
RXD–TXO
TXD–RXI