photron

Du brauchst nicht unbedingt die korrekte Zeit auf dem RED Brick.

Das apt-get upgrade Problem kann ich hier reproduzieren. Sieht aus als wäre dieser Debian Bug aus 2014 wieder aufgetaucht. Da habe ich ad hoc keinen Lösungsvorschlag für. Laut Bugreport soll man systemd-shim deinistallieren können und das würde das Problem lösen. Allerdings lässt mich apt das Package nicht purgen, da es erst systemd upgraden will.

Den QXcbConnection kann ich hier erzeugen wenn ich die DISPLAY Umbegungsvariable für das Programm nicht setzte. Hast du DISPLAY auf :0 gesetzt wie hier im Tutorial zu sehen?

Dafür gibt es keine direkte API Funktion. Die API des RED Brick ist generischer gebaut. Du kannst grob gesagt auf dem RED Brick Dateien lesen/schreiben, Shell Befehle ausführen und User Programme definieren. Darauf basierend sind alle RED Brick Funktionen im Brick Viewer gebaut. Das führt dazu, dass die API schwieriger zu benutzen ist, im Gegenzug können wir aber einfach neue Funktionen zum Brick Viewer hinzufügen ohne dazu die API des RED Bricks erweitern zu müssen. Um die Uhrzeit zu setzen ruft Brick Viewer den date Befehl auf dem RED Brick mit passenden Parametern auf.

Das Industrial Digital In 4 Bricklet ist für DC gedacht. Intern treibt die Eingangsspannung LEDs an. Daher haben die Eingänge auch eine Polung. Du kannst auch 36V AC einspeisen, dadurch geht das Bricklet nicht kaputt. Aber bedingt durch die LEDs kannst du nur die positive Halbwelle messen.

MacDuff, ich hab das gerade mal getestet und dazu folgendes getan: - RED Brick mit Image Version 1.5 und Monitor per HDMI - "sudo apt-get install python3-pyqt5" auf dem RED Brick - entsprechend des Tutorials diese PyQt5 Beispiel hochgeladen - funktioniert

MasT3r-A, dein Problem ist, dass position vom Typ char ist. Du musst also nicht mit 1 und 2, sondern mit '1' und '2' vergleichen musst.

Du hast recht, eLurch. Ich habs in der Dokumentation abgeändert.

Brick Viewer 2.2.2 Add service configuration tab to RED Brick plugin Add wireless access point tab to RED Brick plugin Add program import/export and system log export tab to RED Brick plugin Fix make buttons on RED Brick compile dialogs for C/C++ and Delphi/Lazarus Replace all PyQwt usage with custom code Fix maximum page number in NFC/RFID Bricklet plugin Downloads: Windows, Linux, Mac OS X

Brick Viewer 2.2.2 Service Konfigurations Tab zu RED Brick Plugin hinzugefügt WLAN Access Point Tab zu RED Brick Plugin hinzugefügt Programm Import/Export und System Log Export Tab zu RED Brick Plugin hinzugefügt Make Buttons auf RED Brick Kompilier-Dialogen für C/C++ und Delphi/Lazarus funktionieren wieder PyQwt komplett durch eigenen Code ersetzt Maximale Page Nummer für NFC/RFID Bricklet Plugin korrigiert Downloads: Windows, Linux, Mac OS X

Brick Daemon 2.2.1 Improve RED Brick hotplug detection and error handling on Windows Add debug filter to fine-tune debug output Wait for WebSocket handshake completion before sending data Use redapid version as RED Brick firmware version Don't send packet twice after partial write Downloads: Windows, Linux (amd64, i386, armhf), Mac OS X

Brick Daemon 2.2.1 RED Brick Hotplug Erkennung und Fehlerbehandlung auf Windows verbessert Debug-Filter zur Feineinstellung der Debug-Ausgabe hinzugefügt Auf WebSocket Handshake warten bevor Daten gesendet werden redapid Version wird als RED Brick Firmware Version verwendet Packet wird nach Partial Write nicht mehr fälschlicherweise noch ein zweites Mal gesendet Downloads: Windows, Linux (amd64, i386, armhf), Mac OS X

Es ist sicherlich schon ein Unterschied ob du zwischen zwei Rechnern übers Netzwerk kommunizierst oder nur auf einem mit sich selbst über die Loopback Schnittstelle. Da würde ich die Flinte nicht gleich ins Korn werfen. Wie ist den dein bisheriger Aufbau genau?

Der Power Knopf am RED Brick bezieht sich nur auf den RED Brick. Der Rest des Stacks hat damit nichts zu tun. Die Stromversorgung des Stacks ist vom Stack aus intern nicht schaltbar. Wenn dann muss diese extern getrennt werden.

Mit dem RED Brick entfällt die USB Verbindung, wenn du das Bricklet an einem Brick angeschlossen hast, dass auf den RED Brick gesteckt ist. Die Netzwerkverbindung bleibt, wenn auch in anderer Form. Dein Programm auf dem RED Brick verbindet sich immer noch über localhost mit dem brickd auf dem RED Brick. Potentiell könnte das mit Auswertung auf dem RED Brick schneller/stabiler werden, weil du die externe Netzwerkverbindung nicht mehr in der Kommunikationskette hast. Das hängt aber wirklich davon ab wo dir in deinem jetzigen Aufbau die 10-20ms verloren gehen.

Welche Linux Distribution verwendest du? Serielle Schnittstellen sind normalerweise der Gruppe dialout zugeordnet und normalerweise ist der Standardnutzer auch in dieser Gruppe. In diesem Fall funktioniert alles wie beschrieben. Wenn der Nutzer nicht in der dialout Gruppe ist kann man das Problem mit sudo umgehen. Alternative kann der Nutzer auch der dialout Gruppe hinzugefügt werden. Ich habe die Fehlermeldung in brickv jetzt um den Hinweis erweitert brickv als root zu starten und den entsprechenden Hinweis auch in die Dokumentation aufgenommen. Wo hast du gelesen, dass du den USB Stecker einstecken sollst während du Erase gedrückt hältst? Was eigentlich passieren muss ist, dass Erase gedrückt ist wenn der Brick startet. Das kannst du auf zwei Wegen erreichen: - Entweder wie dokumentiert: Brick an USB anschließen, Erase gedrückt halten und dabei Reset drücken. Das Ziel ist, dass beim Loslassen von Reset der Erase Knopf gedrückt ist. - Die andere (undokumentierte) Weise: Erase gedrückt halten und dabei USB anstecken. Der Brick startet dann beim Anstecken von USB, kein Reset Knopf nötig. Beides führt zum Ziel. Wir haben aber absichtlich nur eine Weise dokumentiert, um Verwirrung zu vermeiden. Hat scheinbar nicht geklappt Ich habe die Beschreibung in der Dokumentation jetzt hoffentlich verständlicher umformuliert.

Ich sehe gerade dein spezielles Problem mit tinkerforge_touch_calibrator.py solte im aktuellen git Stand behoben sein. Ich rate dennoch dazu den Stand vorm Wechsel zu jessie zu verwenden, da gerade noch sehr vieles nicht mehr funktioniert und erst für jessie korrigiert werden muss.

Wir arbeiten gerade am nächsten Release des Image und sind gerade noch mitten drin. Es kann sein, dass der aktuelle git Stand nicht funktioniert, sorry. Du kannst versuchen auf den git Stand vor dem Wechsel zu Debian jessie zurück zu gehen, der sollte funktionieren. Das ist dieser commit: https://github.com/Tinkerforge/red-brick/commit/543cf3fb5a997cdb3f6c00b24ae590480d3807ef

Warum das Image bei dir nicht direkt funktioniert hat kann ich nicht sagen. Normalerweise ist der Ablauf: Image auf SD Karte schreiben, SD Karte in RED Brick stecken, RED Brick mit Strom versorgen, RED Brick bootet. Es kann sein, dass der erste Bootvorgang etwas länger dauert, weil das System dann noch Verschiedenes initialisieren muss, aber es sollte booten. Bezüglich DC Brick, der funktioniert direkt auf dem RED Brick, aber dazu muss er auf der aktuellen Firmware Versino sein: 2.3.0. Wenn auf dem DC Brick eine ältere Firmware ist, kann dass dein Problem erklären. Dies gilt für alle Bricks.

Es gab mal vor einer Weile einen ähnlichen Fall. Da war auch das Problem, dass die Bolzen ein klein bisschen zu kurz waren. Dadurch hat sich dann die Platine verbogen, wenn die Verschraubung fest angezogen wurde. Es ist durchaus möglich, dass das hier das gleiche Problem ist. Wenn dem so ist dann ist die Empfehlung die Verschraubung nur so fest anzuziehen, dass sich die Platinen nicht verbiegen. Nicht die schönste Lösung, ich weiß, leider kann ich dir derzeit keine bessere anbieten.

Richtig g_ether ist derzeit nicht verfügbar. g_ether wird aber in der kommenden Image Version 1.4 enthalten sein.

Im Log sehe ich, dass brickv mit brickd verbunden ist und einen Enumerate Request sendet, damit sich alle erreichbaren Bricks und Bricklets melden: <D> <client.c:278> Received request (U: 1, L: 8, F: 254, S: 2, R: 0) from client (N: 192.168.###.###:22030, T: plain-socket, H: 16, A: disabled) brickd sendet dann diesen Enumerate Request an einen Master Brick mit UID 6xCjQr über USB weiter: <D> <hardware.c:111> Broadcasting request (U: 1, L: 8, F: 254, S: 2, R: 0) to 1 stack(s) <D> <usb_transfer.c:262> Submitted write transfer 0x904af8 for 8 bytes to Master Brick [6xCjQr] <D> <stack.c:129> Forced to sent request to Master Brick [6xCjQr] Es kommt aber keine Antwort vom Master Brick. Das hab ich so noch nicht gesehen. Das muss aber kein Hardwarefehler sein. Es muss noch nicht mal sein, dass die Firmware neu aufgespielt werden muss. Es kann schon reichen den Brick einfach mal nur neuzustarten durch Reset Knopf drücken oder kurz die Stromversorgung trennen.

Erstmal vorweg: Flashen über das SAM-BA Tool mittels brickboot wird von uns nicht mehr supportet. Es kann durchaus sein, das brickboot nicht mehr kompiliert. Wie das Flashen mit dem SAM-BA Tool mal funktioniert hat kannst du in der alten Dokumentation nachsehen, die auf archive.org noch verfügbar ist. Du musst aber brickboot nicht selber kompilieren. Du kannst einfach die alten vorkompilieren brickboot Dateien für SAM-BA verwenden: http://download.tinkerforge.com/tools/samba/

Da wurde vor kurzem dran gearbeitet. Einige Änderungen waren noch nicht committet. Jetzt geht es wieder, danke für den Hinweis.

Du kannst mit einem WLAN USB Stick der den Access Point Modus unterstützt ein Raspberry Pi in einen Access Point verwandeln und dann dich vom iPhone aus direkt damit verbinden. Du brauchst aber das Raspberry Pi nicht zwingend als Proxy zwischen iPhone und Tinkerforge Bausteinen. Es geht auch ohne, wenn auch nicht so schön und einfach, mit dem Nachteil, dass du aus NetIO heraus dann das unser binäres Protokoll sprechen musst. Wenn du nur Steuerbefehle, wie das schalten eines Dual Relay Bricklets brauchst ist das nicht so schwer. Ich hab hier mal schnell ein einfaches Beispiel zusammen gebaut. Die NetIO Konfiguration ist angehängt plus modifizierte Shell Bindings, die das Binär Paket in hex ausgeben. Dieses muss dann bei den einzelnen Knöpfen unter "sends" eingetragen werden. Um diese hex Strings zu erzeugen muss du die modifizierten Shell Bindings wie folgt aufrufen. Dabei musst du statt fCp die UID deines Dual Relay Bricklets angeben. Relay 1 On: python tinkerforge_netio call dual-relay-bricklet fCp set-selected-state --expect-response 1 true Relay 1 Off: python tinkerforge_netio call dual-relay-bricklet fCp set-selected-state --expect-response 1 false Relay 2 On: python tinkerforge_netio call dual-relay-bricklet fCp set-selected-state --expect-response 2 true Relay 2 Off: python tinkerforge_netio call dual-relay-bricklet fCp set-selected-state --expect-response 2 false Dual_Relay_Test.json tinkerforge_netio