Plenz

Mit Rapid-Q sieht das so aus: DECLARE SUB Geklickt CREATE MYFORM AS QFORM CREATE MyLabel AS QLABEL Caption = "vorher" END CREATE CREATE MyButton AS QBUTTON Caption = "Klick mich!" OnClick = Geklickt END CREATE END CREATE SUB Geklickt MyLabel.Caption = "nachher" END SUB Ist wohl selbsterklärend

Hatte ich oben schon erwähnt: es geht um die simpele Abfrage von Tasten. Einfach eine Schleife, in der pausenlos der Tastaturpuffer abgefragt wird, und wenn das "A" gedrückt wird, dann tu dies, und wenn "B" gedrückt wird, dann tu das. Ich habe mich dumm und dusselig gesucht nach so einem Code, aber nichts gefunden. Dagegen war das Beispiel für eine winzige Form mit einem Button, der per Klick eine Subroutine startet, völlig simpel und kurz. Das Problem war nur, die zwei Beispiele zusammenzubasteln. Dein Code ist schon fast perfekt, nur zwei Sachen habe ich jetzt herausgefunden: die Zeile "app = None" ist überflüssig, und ein Label textet man um mit label.config(text="abcde") Jedenfalls danke für deine Hilfe.

Wem sagt du das. Meine Lieblingssprache ist immer noch der BASIC-Dialekt "Rapid-Q", zwar veraltet und ungepflegt, läuft aber auch unter Win7, was will man mehr. Rapid-Q ist super für kleine Projekte, weil man die Form mit allen Elementen sowie den Programmcode in eine einzige Datei packen kann. Es ist nur nicht so extrem objektorientiert, und man kann wahrscheinlich keine Callbacks programmieren, aber mir würde das genügen, alles in einer einzigen Endlosschleife abzufragen. Ich bräuchte nur eine dafür geeignete DLL, dann wäre Python für mich gestorben.

Ich weiß nicht, ob das eine Endlosschleife ist, aber in dem Tutorial, wo ich das her habe, stand das so drin. Und der Rest ist bloß gesunder Menschenverstand. Aber jetzt wo du's sagst... in dem Beispiel von Tinkerforge gibt es keine Endlosschleife... das verstehe wer will...

Was ist denn das für eine geile Mechanik? Das ist ja genau das, was ich für meine Kamerastabilisierung brauchen würde, wenn ich mir nicht schon eine solche mühsam gebastelt hätte (die natürlich viel klobiger und unprofessioneller aussieht). Was für Motoren stecken da drin?

Herzlichen Dank erst mal, ich werde das heute abend ausprobieren. Mir ist das alles ein Rätsel (von wegen "Python ist soooo einfach"), insbesondere denke ich, root.mainloop() soll m.W. eine Endlosschleife sein, in der das Programm quasi "gefangen" ist und nur noch auf Ereignisse (Interrupts) warten kann... wie zum Geier kann danach noch weiterer Code stehen und ausgeführt werden?

Ich bin ein ziemlicher Python-Neuling und versuche mich jetzt mit Tkinter, weil es mir scheint, dass eine grafische Oberfläche mit Buttons deutlich weniger Code braucht als eine simple Tastendruck-Abfrage per Konsole. Leider habe ich mich im Dschungel der Objekte, Klassen und Instanzen verirrt. Insbesondere ist mir schleierhaft, was man in welcher Reihenfolge definieren bzw. programmieren muss. Als erster Gehversuch soll ein IO4-Eingang den Text eines Labels verändern, aber ich schaffe es nicht. Hier mal ein ganz grober Ablauf: from Tkinter import * ... UID_IO4 = "7Qo" # IO-4 Bricklet io4 = IO4(UID_IO4) # Create device object ipcon = IPConnection(HOST, PORT) # Create IP conn. to brick ipcon.add_device(io4) # Add device to IP conn. # Callback function for interrupts # Ja, etwas blöd so mitten drin, aber das gab die wenigesten Fehler def cb_interrupt(interrupt_mask, value_mask): if ((interrupt_mask == 4) & ((value_mask & 4) == 0)): print "EIN" # das funktioniert noch! App.anschlo("EIN") # das ist fehlerhaft # Enable interrupt io4.set_interrupt((1 << 2)|(1 << 3)) # Register callback for interrupts io4.register_callback(io4.CALLBACK_INTERRUPT, cb_interrupt) class App: def __init__(self, master): frame = Frame(master) frame.pack() self.anschl1 = Label(frame, text="x") self.anschl1.pack(side=LEFT) self.button = Button(frame, text="QUIT", command=self.ende) self.button.pack(side=LEFT) def anschlo(tx): self.anschl1.text = tx def ende(self): ipcon.destroy() print "IP destroyed." root.destroy() root = Tk() app = App(root) root.mainloop() Die Interrupt-Routine scheint das Label nicht zu kennen oder falsch anzusprechen oder... Ich würde mich freuen, wenn jemand dieses Programm ein wenig aufräumen würde.

Richtig, das war mir kürzlich auch aufgefallen: bei den IO-Bricklets ist kein maximal zulässiger Strom angegeben. Einziger Anhaltspunkt bis jetzt: ein Foto mit einer LED und einem 1-kOhm-Widerstand.

http://www.google.de/search?q=Singleton+Pattern

Ich darf mal in aller Bescheidenheit damit prahlen, dass ich etwas ähnliches schon vor ein paar Jahren gemacht habe, das Ergebnis kann man bei anschauen. Dass das alles jetzt einigermaßen "glatt" aussieht, ist das Ergebnis intensiver Nachbearbeitung; in Wirklichkeit haben einige Bewegungen deutlich geruckelt, weil meine Mechanik nicht präzise genug war. Aber das sieht man dummerweise erst, wenn die Sache gelaufen ist. Auch das Beschleunigen und Abbremsen der Bewegungen ist ziemlich knifflig. Also: Präzision ist wichtig, der Schlitten darf kein Spiel in den Schienen haben, und er darf beim Übergang zwischen zwei Schienen auch nicht ruckeln.

Mal eine dumme oder vielleicht gar nicht so dumme Frage: wie sieht es mit der Legalität aus? Laut Beschreibung sendet das Ding auf 868 MHZ, und laut Wikipedia darf man bei dieser Frequenz nur maximal 1% der Zeit ein Signal absenden, anschließend muss man 99% der Zeit Funkstille einhalten. Sicherlich halten auch die im Blog erwähnten Funkthermometer diese Regel ein, schon allein um die Batterie zu schonen. Dass sie pausenlos "spammen", ist bestimmt nicht der Fall. Möglicherweise lassen sich die Chibis ja auch zwischen 869,65 und 870 MHz betreiben, dann dürfen sie wirklich pausenlos senden. Wenn nicht, dann muss die im Blog gestellte Frage eindeutig mit "nein" beantwortet werden.

Wie sieht es denn mit den IMUs aus? Laut Blog seid ihr am Kalibrieren, am Wochenende wolltet ihr ein Video gemacht haben... Ist schon ein Versandtermin abzusehen? Ich fände es super, wenn ich meinen IMU-Brick noch vor dem Wochenende in den Händen hätte!

Wozu ein Modul, man braucht doch nur das Analog-In und bastelt einen Spannungsteiler mit Gleichrichter dazu. Dabei muss man den Faktor 1,414 als Unterschied zwischen Spitzen- und Effektivspannung berücksichtigen. Das hier dargestellte Beispiel (nur so aus dem Handgelenk, ohne Gewähr und auf eigene Gefahr!) teilt die Eingangsspannung durch 14,1 und erzeugt eine Gleichspannung von 1/10 der Eingangsspannung. Das gemessene Ergebnis muss man dann nur noch mit 10 multiplizieren.

Man könnte sich noch so einiges an Montagematerial wünschen, z.B. eine Adapterplatte "Bricklett auf Brick". Tinkerforge schrieb mir dazu, dass ihnen momentan schlichtweg die Zeit fehlt, angedacht wäre da eine Menge bis hin zu einem Gehäuse. Was mir aktuell missfällt: dass die bestellbaren Abstandsbolzen 1/2 mm kürzer sind als der Abstand zwischen zwei Bricks. Ich habe mich beholfen, indem ich Kunststoff-Unterlegscheiben dazwischen gesetzt habe.

:'(

Das IMU nicht, denn dann ist ja auch das Erdmagnetfeld weg Die Motoren könnte man mit MU-Metall abschirmen, aber einfach ist das nicht, weil MU-Metall nach einer Bearbeitung (Verformung) durchgeglüht werden muss. Letztendlich interessiert mich das auch gar nicht, weil für meine Zwecke nur die Lageänderung (Verdrehung gegenüber der Horizontalen) maßgebend ist.

Hört sich alles viel komplizierter an, als ich dachte Dann dauert es wohl noch ein Weilchen? Der IMU-Brick wird nahe bei einem Motor sitzen und dabei aber auch relativ zu diesem Motor hin und her bewegt werden. Kalibrieren wird zwecklos sein. Eine spezifische Temperatur habe ich nicht, im Gegenteil: ich will mein Gerät draußen im Freien benutzen. Sollte ich eventuell über ein beheizbares Gehäuse nachdenken?

Ich sehe gerade, der IMU-Brick gibt auch noch die Temperatur in 1/100 Grad aus. Temperatursensoren haben immer eine gewisse Fertigungstoleranz, aber auf dessen Kalibrierung könnte ich auch gut verzichten bzw. bei Bedarf selbst machen.

Laut Docu (schon gelesen?) kann man mit IMU.get_all_data() sämtliche Messwerte unabhängig voneinander auslesen.

Während ich auf meinen bestellten IMU-Brick warte, der von Tinkerforge noch kalibiert werden muss, würde mich mal interessieren, was dahinter steckt. Vor allem: was genau muss da gemacht werden, was hat der Hersteller dem Anwender überlassen? In der Doku steht einerseits, das Rekalibrieren wäre einfach, andererseits wird davor gewarnt, die Gyros zu rekalibrieren, weil dazu eine zusätzliche Mechanik erforderlich ist. Und: müssen alle Sensoren (Magnetfeld, Lage, Beschleunigung) kalibriert werden? Welche Kalibrierung ist einfach, welche ist schwierig? Wenn ich jetzt schon weiß, dass ich das Magnetfeld wegen naher Elektromotoren sowieso nicht auswerten kann, kann ich dann auf die Kalibrierung der Magnetfeldsensoren verzichten und meinen IMU-Brick schneller bekommen?

Nun, wie auch immer - es gibt ein neues (?) Problem. Und zwar möchte ich mir regelmäßig die Stromstärke anzeigen lassen. Ich habe die Zeile cs = dco.get_current_consumption() in die Interrupt-Routine eingefügt, soweit funktioniert das Programm noch, aber wenn ich dann noch print cs hinzufüge, wird die Subroutine nicht mehr beendet. Ich drücke dann die Enter-Taste, um das Programm abzubrechen, und es erscheint: Exception in thread Thread-2: Traceback (most recent call last): File "C:\Programme\Python\lib\threading.py", line 551, in __bootstrap_inner self.run() File "C:\Programme\Python\lib\threading.py", line 504, in run self.__target(*self.__args, **self.__kwargs) File "build/bdist.linux-x86_64/egg/tinkerforge/ip_connection.py", line 212, in callback_loop device.callbacks[function_id](*self.data_to_return(data[4:], form)) File "C:\Programme\Python\CamStab.py", line 29, in cb_interrupt velo = dco.get_velocity() File "build/bdist.linux-x86_64/egg/tinkerforge/ip_connection.py", line 76, in func return f(self, *args, **kwargs) File "build/bdist.linux-x86_64/egg/tinkerforge/brick_dc.py", line 84, in get_velocity return self.ipcon.write(self, DC.FUNCTION_GET_VELOCITY, (), '', 'h') File "build/bdist.linux-x86_64/egg/tinkerforge/ip_connection.py", line 291, in write raise Error(Error.TIMEOUT, msg) Error: -1: Did not receive answer for message()in time Noch ein Bug in den Bindings?

Es hat nicht gesagt, er spricht kein englisch, sondern er hat gesagt, sein Englisch wäre nicht sehr gut. Und damit steht er etwa da, wo ich auch stand, als ich mit der Schule fertig war. Ich war immer froh gewesen, wenn ich eine 4 bekam und keine 5. Dass mein Englisch heute viel besser ist, verdanke ich vor allem englischen Manuals und englischen Computerspielen. Und einem gewissen Durchbeißvermögen, ohne das man im Leben nicht weit kommt.

1.) "Irgendwie" ist keine besonders nützliche Problembeschreibung. 2.) Lies die Beschreibungen und Anleitungen. Benutze ein Wörterbuch. Dein Englisch wird dadurch besser, das weiß ich aus eigener Erfahrung.

Danke, ich werde heute abend die Bindings noch mal runterladen. Wegen des Callbacks mache ich mir keine Sorgen. Das wird doch nur ausgelöst, wenn der Schalter betätigt wird, und das geschieht erst dann, wenn der Motor sich dreht, und der dreht sich erst, wenn die Hauptroutine so weit durchgelaufen ist. Oder irre ich mich? Für mich als Python-Anfänger ist das alles ziemlich verwirrend. Ich versuche immer, diese neuen Begriffe in etwas Bekanntes zu übersetzen: Bindings = Treiber, Callback = Interrupt-Subroutine - kommt das in etwa hin?

Der DC-Brick polt nur die Spannung um, er vertauscht Plus und Minus. Bei einem Motor bedeutet das, er dreht sich z.B. 55% der Zeit vorwärts und 45% der Zeit rückwärts, das Resultat ist eine langsame Drehung vorwärts. Für den Hubmagnet ist die Polung aber egal, er hat die gesamte Zeit volle Kraft. Das ließe sich lösen, indem man noch eine Diode zwischenschaltet.