photron

Dein Problem liegt hier: $VALUE_ON = (1 << 3); $iqr->setMonoflop($VALUE_ON, 1, 500); Die Signatur ist so: setMonoflop(int $selection_mask, int $value_mask, int $time) Für die selection_mask nimmst du 1 << 3, also eine 1 um 3 Bit nach links geschoben, in Binär 0b1000 (0b als Prefix für Binär, so wie 0x für Hexadezimal). Damit hast du das Relais 3 (von 0 gezählt) ausgewählt. Für die value_mask nimmst du 1, in Binär 0b0001. Damit gibst du für Relais 0 vor dass es eingeschaltet werden soll und alle anderen ausgeschaltet. Da du mit der selection_mask von 0b1000 aber gesagt hast, dass über haupt nur Relais 3 geschaltet werden soll passiert nichts, da Relais 3 schon aus ist. Die selection_mask sagt welche Relais überhaupt geschaltet werden sollen und die value_mask sagt wie geschaltet werden sollen. 0b1000 selection_mask 0b0001 value_mask In der value_mask werden also nur die Stellen betrachtet, für die in der selection_mask eine 1 steht. Du schaltest also Relais 3 aus und alle anderen bleiben unverändert. Um Relais 3 einzuschalten muss es so aussehen: 0b1000 selection_mask 0b1000 value_mask und daher so in PHP: $SELECT_3 = (1 << 3); $VALUE_3_ON = (1 << 3); $iqr->setMonoflop($SELECT_3, $VALUE_3_ON, 500); Bitmasken können verwirrend sein

Leider nein, das hatte ich schon beim eigenen Ausprobieren getestet, Fehlermeldung "adress already in use" Doch doch, das geht, du musst dann nur für den zweiten Listen Aufruf einen anderen Port nehmen. Standardmäßig lauscht Listen auf Port 4217 auf eingehende Verbindungen von NetIO. Hier mit lauscht das zweite Listen auf Port 4218 für die zweite Ethernet Extension: tinkerforge --host 192.168.2.242 --port 4222 listen --port 4218

Wenn du den Listen Modus so startest tinkerforge --host 192.168.2.241 --port 4222 listen dann werden all Befehle die von NetIO eingehen an 192.168.2.241:4222 geschickt. Für deine zweite Ethernet Extension kannst du jetzt die Shell Bindings in zweites Mal im Listen Modus mit der anderen IP Adresse starten. In NetIO verwendet du dann auch zwei verschiedene Connections. Du kannst aber auch die --enable-host und --enable-port Option des Listen Modus nutzen. Dann kannst du von NetIO aus für jeden Befehl --host und --port setzen. Also tinkerforge listen --enable-host --enable-port und dann in NetIO statt "call ..." --host 192.168.2.241 --port 4222 call ...

Okay, nehmen wir mal an die Verschraubung ist wirklich das Problem. Wie fest hast du die Bolzen angezogen? Wenn du die sehr stramm anziehst dann kann es vorkommen, dass du die Platine etwas verbiegst. Vielleicht ist das Verbiegen das eigentliche Problem. Was passiert, wenn du die Bolzen nur sehr locker verschraubst? Eigentlich sollten alle Bauteile auf den Bricks so gesetzt sein, dass du mit den Bolzen in jeglicher Stellung keine Bauteile berühren kannst und damit auch keine Kurzschlüsse machen kannst. Schau dir dennoch mal an ob du nicht irgendwo eine Bolzen hast der ein Bauteil oder ein Lötstelle berührt.

Dass heißt also, ob es funktioniert oder nicht hängt davon ab wie du das ganze mit Strom versorgst? Dein Stack besteht aus Step-Down Power Supply, zwei Master Bricks und einem DC Brick. Wenn du den Stack mit 5V über USB versorgst und den Lüfter mit 12V über den schwarzen Stecker des DC Bricks, dann funktioniert es. Sobald du aber den Stack über die Step-Down Power Supply versorgst geht es nicht mehr. Frage 1: Versorgst du den Lüfter und die Step-Down Power Supply mit dem gleichen Netzteil? Und was ist das überhaupt für ein Netzteil: Spannung, maximaler Ausgangsstrom, etc? Frage 2: Hast du ein zweites Netzteil zur Hand, so dass du als Test Step-Down Power Supply und Lüfter aus zwei verschiedenen Netzteilen versorgen könntest?

Wenn es das Problem aus dem Stepper Brick Thread ist, dann sollte es helfen, wenn du auf allen Brick im Stapel die aktuellen Firmware Versionen hast: Master Brick 2.2.2, DC Brick 2.0.3. Wenn du schon die aktuellen Firmware Versionen verwendest und das Problem besteht weiterhin, dann ist es wahrscheinlich nicht direkt das Problem aus dem Stepper Brick Thread.

Dass heißt, sobald du enable aufrufst wenn der Drive Mode auf Drive/Coast stehst oder du auf Drive/Coast umstellst während enabled=true ist dann startet der DC Brick neu. Der Neustart ist dann daran zu erkennen, dass der Drive Mode auf Drive/Break zurückgesetzt wurde und is-enabled false ausgibt. Ich nehme an, in den Fällen wo get-drive-mode einen Fehler ausgibt, hast du get-drive-mode direkt nach set-drive-mode oder enable aufgerufen, so dass du den DC Brick im Neustart erwischt hast und er noch nicht antwortet konnte. Tritt das Prpblem nur auf, wenn der Lüfter angeschlossen ist, oder auch wenn der Lüfter nicht angeschlossen ist?

Du hast den EN Eingang des I2C Trenners ICs mit dem ADDR Ausgang des Bricklet Steckers verbunden. Das funktioniert nur am Master Brick. Der Master Brick setzt den ADDR Ausgang auf High für das Bricklet mit dem er I2C sprechen will, und sonst auf Low. Bei allen anderen Bricks mit zwei Bricklet Ports ist der ADDR Ausgang des einen Bricklet Ports fest auf High und des anderen Bricklet Ports fest auf Low. Das Problem kannst du lösen indem du den EN Eingang des I2C Trenners ICs nicht mit ADDR, sondern mit IO_1 verbindest. Der A03 Eingang des EEPROMs muss aber mit ADDR verbunden bleiben.

Callbacks werden nicht per IP Connection eingestellt, sondern die Callback Einstellungen sind auf dem Brick(let)s und somit global über alle IP Connections hinweg. Daher können sich zwei Programme die die gleichen Callbacks nutzen in die quere kommen.

setChipType() ist neu in Java Bindings Version 2.1.1. Verwendest du vielleicht unter Linux eine ältere Version der Bindings?

Vielleicht haben AB440S und AB440SC verschiedene Toleranzen für das gesprochenen Protokoll und wir treffen die Timings nicht immer gut genug für die AB440S Version. Müssen wir uns genauer anschauen.

Hrm, die interessante Zeil aus dem Log ist diese: libusb: warning [windows_get_device_list] could not retrieve port number for device '\\.\USB#VID_16D0&PID_063D&REV_0110#3&2CD4FE1F&0&A277F366-0B82-494C-9CF6-4FBCD4D47C5F', skipping: [13] Die Daten sind unzulässig. libusb fragt hier Windows bzw. den USB Hub Treiber nach der Portnummer des Bricks am USB Hub und bekommt als Antwort ERROR_INVALID_DATA, was laut Dokumentation bedeutet, dass die angefragte Information nicht vorhanden oder ungültig ist. Da bin ich jetzt etwas ratlos, sorry. Wie ist den der Aufbau des ganzen? Irgendwo steht ein Window Server auf dem unter Hyper-V Windows VM laufen. Du verbindest sich von einem anderen Windows Rechner zu so einer VM. An deinem lokalen Windows Rechner ist ein Brick per USB angeschlossen und über RDP reichst du den in die VM rein. Stimmt das so? Wenn ja, funktioniert der Brick den dann im lokalen Windows?

Okay, laut dem brickd.log sieht brickd keine Bricks, warum ist nicht klar. brickd verwendet libusb für die USB Kommunikation. Starte den Service nochmal mit folgenden Optionen: --debug --libusb-debug --log-to-file Dann werden auch noch Debug Informationen von libusb ausgegeben, das könnte weiterhelfen.

Welche Windows Version hast du in der VM laufen? Unter Windows 8 wird ein Brick mit seinem richtigen Namen angezeigt, ein Master Brick taucht also als "Master Brick" auf. Unter früheren Windows Versionen tauchen alle Brick als "Tinkerforge Brick" auf. Ist das der Fall in der VM? Wenn nicht ist der Treiber für den Brick noch nicht richtig geladen. Hast du Brick Daemon in der VM installiert? Wie genau funktioniert denn ein Connect nicht? Wenn du auf Connect klickst, ändert sich der Knopf zu Disconnect, es tauchen aber keine Brick auf, oder kommt eine Fehlermeldung wenn du auf Connect klickst?

Wir empfehlen typischerweise Python, wenn es um's Programmierenlernen geht, unabhängig vom Alter der Zielgruppe Python hat als Scriptsprache z.B. den Vorteil, dass man sich nicht noch zusätzlich mit einem externen Compiler und möglicherweise einem Build-System befassen muss. Ein anderer Vorteil von Python ist die einfach Syntax im Vergleich zu vielen anderen Programmiersprachen.

Für Android entwickeln heißt Java programmieren. Da kommst du mit Visual Studio nicht weit, das stimmt. Wenn du dich auf Android fokussieren willst, dann ist sicherlich Android Studio das Richtige. Eine Java IDE die direkt auf Android zugeschnitten ist, ist allerdings noch Beta. Vorher war Eclipse die IDE der Wahl für Android. Wenn es um generelle Java Entwicklung geht ist Eclipse sicherlich immer noch genau das Richtige. Für Eclipse gibt es verschiedene Erweiterungen, um es für verschiedene anderen Sprachen wie C/C++, Python, etc zu verwenden. Wenn du deinem Sohn das Programmieren beibringen willst, dann ist es vielleicht gar nicht das Richtige direkt mit einer großen, komplexen IDE anzufangen. Für den erfahrenen Entwickler ist eine IDE gut und hilfreich. Zuvor muss man aber erstmal lernen mit der IDE umzugehen, neben der eigentlichen Aufgabe Programmieren zu lernen. Vielleicht reicht für den Anfang ein simpler Texteditor und eine Kommandozeile, oder eine einfach Java IDE wie BlueJ, die sich direkt an Anfänger richtet. Persönlich verwende ich derzeit primär Geany (Texteditor mit Syntax Highlighting) und kompilieren und debugge auf der Kommandozeile. Ich habe aber auch schon verschiedenste IDEs für verschiedenste Zwecke verwendet, darunter JCreator, Eclipse JDT/CDT/ADT, Visual Studio (6 und neuer), Dev-C++, Qt Creator, KDevelop, Anjuta, Code::Blocks, etc. Alle haben ihre Vor- und Nachteile. Aktuell bin ich sozusagen mit IDEs durch und wieder bei Texteditor und Kommandozeile angekommen

Richtig, du kannst die USB Verbindung zum Brick durch eine Netzwerkverbindung mittels WIFI oder Ethernet Extension ersetzen. Ein Brick muss aber nicht an dem PC/VM per USB angeschlossen werden, auf dem du Brick Viewer verwenden willst. Du kannst den Brick an irgendeinen PC per USB anschließen. Auf diesem PC muss dann der Brick Daemon laufen und du kannst dich dann von überall im Netzwerk zu diesem PC per Brick Viewer verbinden un den Brick erreichen.

Der Brick sollte entweder im Bootloader sein (AT91 USB to Serial Converter) oder seine Firmware ausführen und als Brick auftauchen. Wenn er als unbekanntes Gerät auftritt oder der Geräte Manager ein Fehler angezeigt wird ist irgendwas nicht richtig. Hast du Bricklets angeschlossen? Wenn ja, funktioniert es ohne Bricklets? Versuch den Brick nochmal in Bootloader zu bringen. Es kommt in sehr seltenen Fällen vor, dass der Brick in einem komischen Zustand zwischen Bootloader und Firmware ist. Dann hilft es normalerweise den Brick nochmal in den Bootloader zu bringen. Es könnte auch ein USB Kommunikationsproblem sein. Hast du mal ein anderes USB Kabel probiert? Da du schon an zwei PCs getestet hast, liegt es wahrscheinlich nicht an der USB Buchse des PCs. Schau dir mal Erase und Reset Knopf genauer an. Machen beide beim Drücken ein Klickgeräusch und bewegt sich der kleine schwarze Knopf nach dem Drücken von selbst wieder in seine Ausgangsposition zurück? Ansonsten bleiben noch die üblichen Verdächtigen: Krumme Pins in den Bricklet Steckern.

Ich musst gerade erstmal ergooglen warum du mit Hyper-V RDP für's durchreichen von USB Geräten an eine VM brauchst: Hyper-V selbst kann das nicht, im Gegensatz zu anderen Hypervisorn. Bricks verwenden keine der vordefinierten USB Klassen (Mass Storage, Keyboard, Mouse, etc), sondern eine Vendor Specific Class. Wenn RDP nur vordefinierten USB Klassen durchreichen kann, dann klappt das mit Bricks nicht. Taucht denn der Brick im Geräte Manager im Windows in der VM auf, wenn du ihn durchgereicht hast? Bist du auf Hyper-V angewiesen? Ansonsten verwenden wir hier Virtual Box, da funktioniert das Durchreichen von Bricks einwandfrei. Mit VMware Workstation habe ich das noch nicht getestet, sollte aber höchstwahrscheinlich auch funktionieren.

jan, der RED Brick kann Master des Stacks sein. Du kannst also Stepper Bricks direkt auf dem RED Brick stecken und verwenden, ohne Master Brick dazwischen.

Der RED Brick ist an sich ein kleiner Linux Rechner. Du wirst auf ihm alle Programmiersprachen verwenden können die du unter Linux verwenden kannst. Zum Beispiel C, C++, C#, Delphi, Java, JavaScript, Perl, PHP, Python, Ruby, VB.NET, etc.

Ja, das ist eine gute Möglichkeit das zu tun. Dein Script wird alle 5 Minuten durch cron gestartet. Bei jedem Start schaut dein Script in deiner Datenbank nach ob es gerade Zeit ist etwas an oder aus zu schalten. Falls das der Fall ist schaltet das Script nach Vorgabe aus der Datenbank. Oder falls gerade nichts zu schalten ist tut dein Srcipt nichts und beendet sich wieder. Das ganze beginnt dann alle 5 Minuten von neuem. Worauf du dabei möglicherweise achten musst, ist der Zeitprüfung etwas Ungenauigkeit zu erlauben. Je nachdem wie exakt cron die Zeiten einhält sollte dein Script z.B. 10:14-10:16 noch als 10:15 interpretieren.

Richtig, du kannst da keinen request_tag_id Aufruf weglassen. Du hast da kein Problem, dein Programm funktioniert richtig. Das NFC/RFID Bricklet sendet dir von sich aus keinen StateChange Callback von sich aus, abgesehen vom Initialization nach Idle Übergang, alles andere danach ist eine Reaktion auf Funktionsaufrufe in deinem Programm. Du rufst request_tag_id/request_page auf. Darauf hin führt das Bricklet intern die angeforderte Aufgabe aus. Da die NFC/RFID Funkkommunikation etwas Zeit dauert, kann das nicht in einem Getter Aufruf passieren, das würde das ganze System blockieren. Die Funktionen starten also eine Aufgabe, die dann im Hintergrund auf dem Bricklet durchgeführt wird. Der Zustand der Durchführung der Aufgabe wird dir per StateChange Callback mitgeteilt: - State ist Idle - Du rufst request_tag_id - State ändert sich zu RequestTagID, StateChange Callback wird verschickt - Tag ID wird per Funk abgefragt - Entweder klappt die Abfrage oder nicht, der State ändert sich zu RequestTagIDReady oder RequestTagIDError und wir dir per Callback mitgeteilt - Jetzt kannst du per get_tag_id die letzte gelesene und im Bricklet zwischengespeicherte TagID abfragen Der selbe Ablauf passiert für request_page. StateChange Callback sind immer eine Folge eines Funktionsaufrufs. Der State ist nicht da, um auszusagen ob da in Tag da liegt oder nicht oder ob er sich ändert, sondern der State sagt aus in welchem Zustand eine Aufgabe ist, die du angestoßen hast.

Das ist kein Problem, sondern so arbeitet dein Programm einfach! Du fängst im __main__ Block mit nfc.request_tag_id(nfc.TAG_TYPE_TYPE2) an und löst damit den ersten Callback aus, mit State 2 (STATE_REQUEST_TAG_ID, ein Tag ID Anfrage ist im Gange). Darauf hin fragst du im else Zweig cb_state_changed erneut eine Tag ID an, was vom Bricklet ignoriert wird (denke ich, hab's nicht nachgesehen). Der nächste Callback kommt dann mit State 130 (STATE_REQUEST_TAG_ID_READY, eine Tag ID wurde gefunden) oder State 194 (STATE_REQUEST_TAG_ID_ERROR, keine Tag ID wurde gefunden). Woraufhin du den Inhalt liest und am Ende wieder request_tag_id aufrufst. Wenn kein Tag zu lesen ist, ist dein Programm in einer request_tag_id/Callback-STATE_REQUEST_TAG_ID_ERROR Schleife und wartet darauf, dass ein Tag auftaucht. Daher bekommst du ständig Callbacks, da dein Program ständig nach dem Vorhandensein eins Tags fragt.

get_rgb_values ist richtig, das muss du jetzt nur wie set_rgb_values rückwärts verwenden. Hier ein kurzes Beispiel (ungetestet): # the number of LEDs to get the color for number_of_leds = ... all_r = [] all_g = [] all_b = [] # list of indices [0, 16, 32, ...] that are smaller than number_of_leds indices = range(0, number_of_leds, 16) for index in indices: # number of LEDs remaining, but not more than 16 length = min(number_of_leds - index, 16) r, g, b = led_strip.get_rgb_values(index, length) all_r += r[:length] all_g += g[:length] all_b += b[:length] Wie set_rgb_values arbeitet auch get_rgb_values auf 16er Blöcken. Die indices Liste beinhaltet alle Startindizes der 16er Blöcke bis zur angegebenen LED Anzahl (number_of_leds). In der Schleife werden die Blöcke dann abgefragt. Die Länge des Blocks wird jeweils berechnet. Für alle Blöcke außer dem Letzten ist die Länge 16, da für diese number_of_leds - index > 16 ist. Für den letzten Block kann die Länge kürzer sein. Zum Beispiel: number_of_leds ist 40, dann ist indices [0, 16, 32] und es wird get_rgb_values(0, 16), get_rgb_values(16, 16) und get_rgb_values(32, aufgerufen. 8 daher weil number_of_leds - index in diesem Fall 40 - 32 = 8 ist, also kleiner 16. Da get_rgb_values aber immer 3 Listen der Länge 16 zurück gibt müssen beim letzten Aufruf diese Listen gekürzt werden auf die wahre Länge, daher r[:length].