Paul

Es reicht doch wenn auf dem RasPi der brickd läuft, dieser kann von jedem Programm über das Netzwerk angesprochen werden... Einfach die IP des RasPi bei HOST = "localhost" eintragen.

That would be quite nice!

Lötpunkte fände ich auch gut, so kann man sich seine eigene Lösung dort anbringe.

Siehe http://www.tinkerunity.org/forum/index.php/topic,407.0.html

@The_Real_Black: Die Idee eines generischen Menüs finde ich gut!

I don't own a baseplate nor do I know of a baseplate/enclosure for the TF system. But I will make me a baseplate out of chipboard and screw four holders for the TF bricks and one for the LCD bricklet on it. I would love to see enclosures for bricks and bricklets, but I think it will be quite difficult, because the projects vary in size very much, eg. you need multiple tf bricks and bricklets, stepper, servos, batterys or power supply. But a baseplate to mount the bricks and bricklets on it would be awesome!

Grüße aus der schönsten Stadt Deutschlands (wenn nicht der Welt ) Hamburg. Gibt hier doch sicher mehr aus dem Norden, oder?

Den Fehler "tinkerforge.ip_connection.Error" kenne ich, wenn die Bricks/Bricklets nicht gefunden werden. Hast du mal einen reset auf dem Master Brick ausprobiert?

Cool, gefällt mir

Die Firmware habe ich am letzten Wochenende auf allen Bricks und Bricklets aktualisiert und die Bindings auch am Wochenende runtergeladen. Unter Ubuntu Stable läuft auch der Brickviewer und auch mein Code läuft dort. Ich bin mir sicher, dass die Beta Version von Ubuntu an den Problemen Schuld war. Ich werde mir das morgen Abend bzw am kommenden Wochenende noch genauer anschauen, aber ein kurzer Test vorhin sah schon vielversprechender aus. Das einzige Problem, ist jetzt noch unter Windows, dass dort die Interrupts bzw Callbacks nicht richtig zurück gegeben werden. Das werde ich aber auch nochmal genauer mit dem neuen Ubuntu vergleichen und dann nochmal detailliert darüber berichten.

Hab zum Test eine Schleife laufen lassen (nur io.set_port_configuration('a', 0xFF, 'i', True) gesetzt) um die Werte dauerhaft zu überprüfen while True: port=io.get:port('a') print port Unter Windows (7 64bit, Python 2.7.2 32bit) gibt es das erwartete Ergebnis, wenn ich keinen Port kurzschließe, bleibt der Wert auf 255 und verändert sich entsprechend der Schaltung. Unter Linux (Ubuntu 12.04 beta 64bit, Python 2.7.3rc1) verändert sich der Wert willkürlich nach kurzer Zeit auf 0, 128, 1, 32, 96, ... plus Veränderungen durch Port Schaltungen. Ich werde mir mal die letzte Stable von Ubuntu installieren, nicht dass mir da Beta "Features" dazwischen funken. Nachtrag: mit Ubuntu 11.10 32bit gibts keine Probleme mit den geschilderten Symptomen. Komm aber heute leider nicht mehr zum testen, alles weitere werde ich mir morgen anschauen.

Hallo borg, danke für deine Tipps. Leider komme ich auf kein konsistentes Ergebnis. Ich habe mal, um das IO Bricklet zu testen, alle Ports der a Seite als Pullup (io.set_port_configuration('a', 0xFF, 'i', True)) und als Interrupt (io.set_port_interrupt('a', 0xFF)) konfiguriert und lasse mir das Ergebnis per Callback anzeigen (euer example_interrupt.py). Ausgelöst wird der Callback aber nur seeeehr sporadisch, mal am Anfang ein mal und dann erstmal nicht, auch wenn ich andere Ports gegen GND kurzschließe. Von ca 100 Schaltungen werden mir 5-10 angezeigt. Unter Windows funktioniert das gar nicht, da wird mir ein Interrupt ausgegeben, wenn ich das Programm schließe... Wenn ich nur den Example Code laufen lasse, bekomme ich überhaupt keinen Callback zustande... Hast du eine Idee? Der Code: https://pastee.org/gtnxq

Den Wert gespeichert habe ich und ich fahr den Schrittmotor auch mit dem Poti (nur ohne Schalter). Nur wie verarbeite ich dass, was ich vom IO Bricklet gemeldet bekomme (also das der Schalter gedrückt wurde), da stehe ich dezent auf dem Schlauch. Als Rückmeldung habe ich diesen (aus dem Kopf) b110110 bzw b110111 Wert. Muss ich dafür "while wert = b110110: fahr den Motor"-Schleife bauen, oder denke ich da in die komplett falsche Richtung? Oder muss ich da einen Callback auf den Port des IO Bricklets setzen? Mit einem io.register_callback(io.CALLBACK_INTERRUPT, cb_interrupt) werden ja alle interrupts verarbeitet (es wird die Funktion cb_interrupt aufgerufen). So weit ich das verstehe, reagiert dieser Callback aber immer, wenn irgend ein Interrupt auftritt. Bei mehreren Schaltern würde dann immer der selbe interrupt/funktion aufgerufen werden, wie trenne ich das? aka interrupt auf port a2 = func1 und interrupt auf port a4 = func2. Hoffe das war verständlich

Moin, ich versuche gerade mit dem IO Bricklet und einem angeschlossenen Mikroschalter eine Funktion auszulösen. In diesem Fall soll der Wert des Rotary Bricklets ausgelesen werden und als Schrittwert für den Schrittmotor verwendet werden. Den Wert des Rotary Bricklets als Schrittanzahl zu verwenden ist nicht das Problem (das läuft auch schon), aber wie verwende ich den Interrupt des IO Bricklets um beim drücken des Schalters den Motor die angegebene Anzahl an Schritten laufen zu lassen? Oder als einfacheres Beispiel, eine LED anschalten. Ich bin noch neu in Sachen programmieren, bisher nur reines Bash Scripting, und wollte mich mal an Python wagen. Gruß, Paul PS: den Interrupt auslesen (per Callback) hab ich auch drin, aber was mache ich mit dem String, den ich dadurch bekomme, bzw wie wird der weiter verarbeitet? Ich vermute mal, dass die Lösung total einfach sein wird, ich nur mal wieder außenrumdenke

Die imports schluckt er ohne Fehler. Werd mir mal bei Gelegenheit die mainwindow.py vornehmen. Den Viewer brauchts zum benutzen der Bricks ja nicht und zum testen gibts noch die Windows Kiste. Danke schonmal!

Speicherzugriffsfehler (Speicherabzug geschrieben) Das kommt auch mit logging.DEBUG Hier einmal ein strace, falls dieser hilft: http://pastebin.com/C1NB0nHr Kommt mir irgendwie seehr "spanisch" grade vor.

Moin, gerade meine Lieferung bekommen und am rumspielen (seeehr zufrieden ) unter Windows läuft der Brick Viewer (1.0.7) auch, nur auf meinem Ubuntu 12.04 beta x64 bekomme ich ihn nicht zum laufen: Tinkerforge-brickv-09e2e49/src/brickv# python main.py Traceback (most recent call last): File "main.py", line 38, in <module> from mainwindow import MainWindow File "/home/user/Downloads/Tinkerforge-brickv-09e2e49/src/brickv/mainwindow.py", line 26, in <module> from ui_mainwindow import Ui_MainWindow ImportError: No module named ui_mainwindow Wenn ich den per .deb installierten Brickv starte, kommt nen Segfault mit "not located in a know VMA region (needed writable region)!" mit dem SegvReason: writing NULL VMA Python ist in der Version 2.7.3 installiert und der brickd läuft. Alle dependencies sind installiert. Gruß, Paul

You shouldn't have any problems with the Raspberry Pi, cause you can run Debian or Ubuntu on it, so you won't have a problem with installing phyton dependencies.

Ich finde gerade den Thread nicht, aber ich habe hier gelesen, dass die Chibi Extension, wie auch die anderen Bricks, völlig transparent sind und zum Verbinden mehrerer Stacks einfach mehrere Chibi Bricks (pro Stack 1x Chibi) verwendet werden können (ohne zweiten Sender) und alle mit Chibi verbundenen Bricks völlig transparent programmiert/angesprochen werden können. D.h. du musst dir bei der Ansteuerung der unterschiedlichen Stacks keine Gedanken um die Chibi Verbindungen zwischen diesen machen. Gruß, Paul

Es gibt auch für SMF Antispam Module (z.B. Stop Forum Spam http://custom.simplemachines.org/mods/index.php?mod=1519 oder Bad Behavior http://custom.simplemachines.org/mods/index.php?mod=2502 ), was die Registrierung der Bots von vorne herein verhindert. Oder verstärkt auf menschliche Moderation setzen, gibt hier sicher ein paar User, die sich bereit erklären würden bei der Moderation zu helfen.

Another possibility is the Raspberry Pi ( http://www.raspberrypi.org/ currently unavailable due to the Anti SOPA protest), its a fully featured mainboard with USB and HDMI for only 25$ and you can run for example a Debian Linux on it. It is powered with 5V over an USB Micro port, so you could use it as a portable solution as well.

As far as I understand it, the PC is used to control the bricks and to run the code that drives the bricks, so the bricks need to have a connection to the pc all the time. If you need code that runs on the bricks itself, you need to write the code in embedded c and flash it to the bricks, but this is not supported right now.