Plenz

Na, hat's jemand gesehen? Ich sage nur: Pleiten, Pech und Pannen! Bei der Probe hatte noch alles funkioniert, aber da hatte ich ja auch Vorbereitungszeit. Aber wenn die Sendeleitung meint, man könnte alle Stecker ziehen, die Sachen auf die Bühne stellen, in drei Minuten zusammenstöpseln und dann geht alles, dann tut's mir leid. Selbst mein Hinweis "ich muss noch die Maschine einschalten und das Programm starten" half nichts - ich hatte umgehend die Bühne zu verlassen und meine Startposition hinter dem Eingang einzunehmen. Also ohne Einschalten, ohne Testen. Als es dann ernst wurde, reagierte das Notebook nicht auf das USB-Kabel. Ich bin sicher, es hätte funktioniert, wenn ich das Notebook noch mal neu gebootet hätte. Aber das geht in einer Livesendung leider nicht. Es besteht aber Hoffnung: in einer der nächsten Sendungen soll meine Maschine noch mal eine Chance bekommen.

Korrekt erkannt. Man kennt ja den Trick: ein Ei auf dem Tisch drehen lassen, und wenn es sich hoch stellt, ist es gekocht. Ich hatte damals zwei Tage lang gegrübelt, wie ich ein Ei zum Drehen bringen kann, aber dann kam mir buchstäblich die Erleuchtung

Nicht ganz... den MZ-80K hätte ich auch gern vorgeführt... Schaut mal Kinder, früher gab's Computer, da war noch gar kein Facebook drin! Aber du hast insoweit recht, weil das Messer durch einen Scheibenwischermotor aus einem 6-Volt-Käfer bewegt wird.

Im Jahr 1982 konstruierte ich eine Eieraufschneidemaschine für die Sendung "Mit Schraubstock und Geige" ( ), damals noch von meinem Sharp MZ-80K gesteuert. Nun ist das Fernsehen wieder auf diese Maschine gekommen. Der MZ-80K will nicht mehr so recht, und ich dachte mir, bevor ich da eventuell nutzlose Zeit in Reparaturversuche stecke, baue ich lieber eine neue Steuerung - natürlich mit TF-Bausteinen. Genauer gesagt ein IO16, den ich mit einem Decoder (4028) noch um ein paar Ausgänge "erweitert" habe. Am kommenden Sonntag (9.6.) sieht man mich mit der Maschine in der Sendung "Immer wieder sonntags".

Hatte ich ja auch so verstanden und ausprobiert (VB.NET). Aber der Code Dim cs As Short cs = ipcon.GetConnectionState() : Console.WriteLine(cs) ipcon.Connect(HOST, PORT) cs = ipcon.GetConnectionState() : Console.WriteLine(cs) ergibt 0 1 auch bei abgezogenem USB-Kabel. Sollte ich etwa einen Bug entdeckt haben?

Ich mache das ähnlich unter VB.NET mit dem IO16: ich frage die Eingänge ab und wenn das nicht klappt, gebe ich eine Meldung aus "USB-Kabel nicht angeschlossen". Ich finde das aber reichlich unbefriedigend. Eine Abfragefunktion ipcon.isConnected() as boolean fände ich weitaus eleganter.

Die Callback-Routine prüft nur, ob der Interrupt durch High oder Low ausgelöst wurde, und bei High wird eine globale Variable auf True gesetzt, die regelmäßig vom Hauptprogramm abgefragt wird. Die Debounce-Zeit hatte ich schon auf 1 gesetzt, das sollte aber nicht das Problem sein, denn der Eingang ist lange genug auf Low, nur nach dem High kann sehr schnell wieder ein Low kommen. Nun gut, ich danke erst mal für die Antworten. Die Software-Seite ist also offensichtlich nicht das Problem. Dann muss ich wohl erst mal mit einem Oszilloskop testen, ob der Schalter bei sehr kurzen Betätigungen überhaupt schaltet. Notfalls muss ich ihn halt durch eine Gabel- oder Reflexlichtschranke ersetzen.

OK, danke! Dann habe ich vielleicht ein anderes Problem, jedenfalls werden manche Schalterwechsel nicht registriert. Ich muss dazu sagen, dass es sich um einen Microschalter handelt, der teilweise nur sehr kurz betätigt wird. In den Datenblättern von Microschaltern habe ich noch nirgendwo eine Angabe über eine minimale Betätigungsdauer gefunden, aber ich gehe davon aus, das der Schalter tatsächlich betätigt wird. Die Frage wäre also, wie der IO16 intern funktioniert. Kann es vielleicht sein, dass die Eingänge mit einer gewissen Frequenz regelmäßig abgefragt werden, und wenn ein Eingang kürzer auf "1" liegt als die Zeit zwischen zwei Abfragen, dann wird das nicht registriert? Falls dem so ist, sollte ich vielleicht mal versuchen, den Schaltimpuls mit Hilfe eines Kondensators zu verlängern? Ich weiß "Versuch macht kluch", aber für die nächsten 2 Tage bin ich zu weit weg von der Bastelei und möchte die Sache schon mal im voraus klären.

Allgemeine Frage: bekommen Callbacks einen eigenen Thread, oder kann es vorkommen, dass Callbacks verzögert verarbeitet werden, wenn das Hauptprogramm gerade voll beschäftigt ist? Ich baue gerade eine Motorsteuerung mit dem IO16. Während der Motor läuft, kann ein Schalter betätigt werden, was zeitkritisch erkannt werden muss, egal womit der Computer gerade beschäftigt ist. Ist das Beispiel mit dem Callback für den IO16 in der Docu dafür geeignet, oder sind irgendwelche zusätzlichen Maßnahmen erforderlich? Ich bin leider weit davon entfernt, ein VB.NET-Spezialist zu sein, und mit solchen Themen wie Threads und dergleichen tue ich mich echt schwer.

Die Idee gefällt mir sehr gut. Aber ich möchte mal zwei Beispiele bringen, die ich gern realisieren würde, aber mit den jetzigen Möglichkeiten nicht kann: 1.) Kleine Zusatzroutine zur Firmware. Das Steuerprogramm in meinem PC ruft einen userdefinierbaren Befehl auf Function BrickletIO4.Userdefined(Integer) As Integer und dort kann ich eine Routine unterbringen, die Ein- und/oder Ausgänge steuert und ein Ergebnis zurück gibt, z.B. die erkannte Folge von Nullen und Einsen aus dem Signal einer IR-Fernbedienung 2.) Eine Stand-Alone-Anwendung ohne PC, tragbar mit geringem Stromverbrauch. An einem Schrittmotor ist ein Zeiger befestigt, der mir in meinem Segelboot die Richtung zum nächsten Koordinatenpunkt meiner geplanten Route anzeigt, gesteuert vom GPS-Bricklet. Sinn der Sache: eine Orientierungshilfe, die man auch erkennen kann, wenn die Sonne blendet und/oder die Schutzhülle des Navi durch zu viele Salzwasserspritzer quasi undurchsichtig geworden ist. OK, das hat jetzt weniger mit der Frage "C vs Python" zu tun, aber mich interessiert, wie weit TF diese beiden Fälle überhaupt für realisierbar und in die Firmware integrierbar hält.

Das juckt mich am allerwenigsten, denn je weiter das Motiv entfernt ist, desto weniger hat das eine Auswirkung aufs Bild. Eine Korrektur würde einen gigantischen Aufwand bedeuten, denn diese Apparatur soll hintem am Boot an einem ca. 2 m langen Arm befestigt werden, und wenn es ordentlich Wellen gibt, dann kann sich die Kamera schon um einen halben Meter auf und ab bewegen. Außerdem würde eine Korrktur der Bewegung erst dann wirklich eine Verbesserung des Bildes bringen, wenn Roll und Pitch restlos ausgeglichen wären - was ich inzwischen für illusorisch halte, zumindest für den Aufwand, den ich bereit bin zu treiben.

Kommt drauf an. Wenn ich den Quellcode für die Firmware des IO4 sehe, wird mir schwindelig. All die verschiedenen Arten von Variablen, die direkt oder referenziert an Subroutinen übergeben werden usw., das ist bestimmt etwas für Gurus. Aber ich habe selbst schon DLLs in C geschrieben, dabei ging es um Manipulationen von Grafikbitmaps, und dafür reichten Bytes, Integer, Arrayzugriffe und die vier Grundrechenarten, das war wirklich nicht schwer. Ich habe weiter oben die Geschwindigkeit erwähnt. Ein Wunsch von mir wäre es, mit dem IO4 ein Infrarot-Fernsteuersignal zu decodieren, dazu braucht man einige 10000 Abtastungen pro Sekunde. Ein Programm dafür wäre simpel, nur ein paar Schleifen und Zähler. So etwas habe ich auch schon mal in Z80 Assembler programmiert, und mit C kann das auch nicht schwieriger sein. Ich vermute, je maschinennäher der Compiler arbeitet, desto niedriger ist der Level der notwendigen C-Kenntnisse, oder?

Danke für die Blumen Ich finde allerdings, dass einem beim Zuschauen immer noch reichlich schwindelig wird, aber das wird vielleicht besser, wenn das Motiv (Boot und Landschaft) weiter weg von der Kamera ist. Jetzt muss erst mal ein Praxistest gemacht werden. Das kann aber noch dauern, bis ich eine Halterung für mein Boot gebaut habe und bis draußen Segelwetter ist...

Unbedingt. Es gibt Anwendungen, wo USB zu langsam ist. Ich habe auch eine Idee für den GPS-Brick, aber dabei kann ich kein Notebook gebrauchen. Usw usf.

Ich sehe mich selbst dazwischen, zumal ich mit nichts von dem beiden beruflich mache und als Autodidakt immer sehr viel "Mut zur Lücke" habe. Von Hardware genug Ahnung, um selbst Schaltungen zu entwerfen, würde mir aber nie zutrauen, eine Verbindung zwischen meiner Hardware und einer USB-Schnittstelle selbst zu basteln. Programmiere ewig mit BASIC-Dialekten, kann bei einer Zeile wie io4.SetConfiguration(1 << 1, "o"C, false) aber nur "das soll BASIC sein???" denken. An sich hast du recht, aber welche Vorstellungen sind realistisch? Tinkerforge kann doch nicht den Software-Freaks das Löten beibringen und den Hardware-Bastlern das Programmieren. Starter-Kits - ich weiß nicht so recht. Das mag natürlich individuell sein, aber ich bin halt ein Bastler, und mich haben auch immer nur Legosteine interessiert. Was soll ich mit einem Lego-Feuerwehrauto? Damit kann man doch nichts machen, außer ein Feuerwehrauto, wie langweilig. Genauso die Wetterstation. Wenn ich meine, dass ich eine Wetterstation brauche, dann kaufe ich mir eine. Fertig. Tinkerforge brauche ich für Dinge, die es noch nicht gibt. Nicht, um irgend etwas nachzubauen, sondern um kreativ zu sein und eigene Ideen zu realisieren. Aber ich habe hier im Forum auch schon andere Leute gesehen, die erst Bricks kaufen und dann überlegen, was sie damit anstellen könnten. Für die wären Starterkits vielleicht wirklich interessant. Vielleicht sollte man auch mal Lehrer fragen, was für den Unterricht (hineinriechen in Informatik und/oder Elektronik) geeignet sein könnte.

Oha, schwierige Frage. Ich will mich doch nicht mit Profis um Terminologien prügeln Wir sprechen doch eigentlich vor allem über eine Datei namens Tinkerforge.dll. Das ich für mich einfach eine Bibliothek, kurz einfach DLL genannt, die Spezialroutinen enthält, über die die TF-Hardware angesprochen werden kann. Zusätzlich haben wir allerdings auch noch den brickd, der vermutlich dafür da ist, um die Hardware interruptfähig zu machen - ein Feature, das mir zugegebenermaßen bisher auch noch nicht untergekommen war. Unter einem SDK verstehe ich ein Gesamtpaket zum Erstellen einer Software. Das heißt: Editor, Compiler, Testumgebung und Bibliothek. Der Brickv hat nach meinem Verständnis überhaupt nichts damit zu tun, er ist ein separates Zusatztool zum Testen, ID auslesen und Flashen. Hier nur mal ein Beispiel für eine ähnliche Situation (allerdings ohne Interruptfähigkeit) ohne den Begriff "binding": The IO-Warrior Kit Dynamic Library provides a simple API to access all IO-Warrior products from Code Mercenaries. It is intended to be used with any programming language available on Windows or Linux. Sample programs are included for Microsoft VC++ 6, MS Visual Basic 6 and Borland Delphi 6 for Windows and C for Linux. The name of the library is iowkit.dll for Windows and libiowkit.so for Linux.

Ich habe hier mal ein Demo-Video verlinkt.

Bessere Verständlichkeit kann ich nur befürworten. Es wird m.E. einfach zu viel Wissen vorausgesetzt. Ich programmiere schon seit Jahrzehnten in den verschiedensten Sprachen, aber beispielsweise der Begriff "Binding" ist mir hier zum ersten Mal untergekommen. Und dann die Rechtschreibung, z.B. "lies Sensoren aus"

Der letze Stand der Entwicklung: stärkere Servos eingebaut, neu programmiert mit VB .Net statt Python. Hier eine ohne großen Aufwand.

Vielen Dank für den Hinweis. Das alles hatte ich auch schon gelesen, aber vor langer Zeit, und damals hatte ich auch nicht den Eindruck, dass das etwas wäre, was für mich von Belang ist. Ist es aber Eine Konvergenz von 1 beseitigt die oben genannten Phänomene tatsächlich. (0 scheint mir nicht praxistauglich zu sein, da "vergisst" er sehr schnell, was waagerecht ist.) Allerdings muss man in der 10-sekündigen Ruhephase zu Beginn eine Konvergenz von 10 oder mehr haben, anderenfalls speichert der IMU-Brick eine Ausgangslage, die nicht waagerecht ist. Wahrscheinlich muss man auch während des Betriebs in gewissen Abständen die Konvergenz hoch setzen, die Beschreibung deutet darauf hin.

Vom Boot bin ich noch weit entfernt, das Ding liegt auf dem Tisch im Wohnzimmer. Mir geht es jetzt erst einmal um ein Phänomen, das jeder IMU-Besitzer einfach mit dem Brick Viewer nachvollziehen kann. Mit Hilfe einer Schiene kann ich den Brick genau linear bewegen. Bei jeder Beschleunigung zeigt das Bild ein kurzes Kippen des Bricks, aber die "Angular Velocity"-Kurven zeigen (wie erwartet) keine Ausschläge, da ich den Brick ja tatsächlich nicht gekippt habe.

Auch rein interessehalber, da ich mich mit dem Thema "Kamerastabilisierung" beschäftige: hast du irgend etwas entwickelt, das die Schwankung der Kamera am Seil registriert und durch eine Gegenbewegung ausgleicht?

Ich versuche mich schon seit geraumer Zeit an einem Gerät, das bei schwankendem Untergrund meine Videokamera immer genau waagerecht hält. IMU, zwei Servos, Ansteuerung, fertig - hatte ich gedacht, aber der Teufel steckt wie immer in Detail. Der IMU-Brick kann zwar wunderbar seine Lage im Raum feststellen, aber offensichtlich nur bei Ruhe. Sobald Bewegung (d.h. beschleunigen - bewegen - abbremsen) auftritt, entwickelt er ein Eigenleben, das deutliche Ähnlichkeit mit einem echt mechanischen Kreisel hat: eine Seitwärtsbewegung erzeugt einen Roll-Ausschlag eine Bewegung nach vorn/hinten erzeugt einen Pitch-Ausschlag eine Drehung um die Yaw-Achse erzeugt beide Ausschläge gleichzeitig Tinkerforge hat ja dankenswerterweise die Formeln geliefert, mit deren Hilfe man die Neigungswinkel unabhängig voneinander ausrechnen kann. Aber zusätzlich scheint es erforderlich zu sein, die Neigungswinkel auch noch unabhängig von Beschleunigungen zu machen. Sehe ich das richtig? Ich verfolge übrigens zwei Ansätze: 1.) IMU auf der Grundplatte stellt fest, dass es um x Grad verdreht ist, und steuert die Servos so, dass sie die Kamera um x Grad in Gegenrichtung drehen. 2.) IMU bei der Kamera stellt fest, dass es verdreht ist, und stellt sich über die Servos wieder selbst waagerecht und somit auch die Kamera. Ursprünglich hatte ich den zweiten Ansatz im Auge, weil er einen geschlossenen Regelkreis bildet und sich deshalb selbst justiert. Ich vermute auch, dass ein solches System auch die oben genannten Phantomverdrehungen mit Hilfe realer Verdrehungen kompensiert. Aber diese Bauweise vibriert stark und schaukelt sich gern selbst auf, es sei denn, ich verringere die Wirkung der Messwerte auf die Servos, dann aber reagiert das Gerät zu langsam auf Verdrehungen. Der erste Ansatz ergibt ein relativ ruhiges System, das aber justiert werden muss und eben die genannten Phantomdrehungen ausführt.

So, alles klar, jetzt hat's geklappt Und nun ran an die heiß ersehnten Visual Basic .NET Bindings!

Danke für die Antwort, ich glaube, ich habe das Problem erkannt. Ursache ist, dass das Wort "hier" in dem Satz "der Aktualisierungsprozess ist hier beschrieben" sich farblich kaum vom anderen Text unterscheidet, und erst wenn man zufällig mit der Maus drüber fährt, wird das Wort wirklich als Link deutlich. Außerdem war mir entgangen, dass dort einmal von Bricks und einmal von Bricklets die Rede ist. Infolgedessen hatte ich den Eindruck, dass das Aktualisieren der Firmware aller Teile mit Hilfe des BrickViewers nach erfolgreicher Verbindung geschehen würde. Nun gut, ich gehe jetzt mal die verlinkte Doku durch und melde mich dann wieder.