photron

Als minimalste Lösung kannst du den IMU Brick per USB Kabel an der USB-A Buchse des RED Brick anschließen. Zusätzlich kannst du dann auch noch zwei Bricklets an der IMU anschließen und so zwischen beweglichem und festen Teil mit einem USB Kabel auskommen. Wenn du am beweglichen Teil mehr als zwei Bricklets hast, dann nimmst du einen Master Brick, steckst die IMU oben auf, schließt dann dort bis zu 6 Bricklets an und schließt das ganze mit einem USB Kabel zwischen Master Brick und RED Brick an. Alternative kannst du auch über WLAN, RS485 oder Ethernet gehen, das braucht aber alles mehr Bausteine. Wenn du genauer beschreiben könntest, welche Bricks und Bricklets wo sitzen und wo die Verbindungsengpässe sind, dann kann ich dir da auch noch exakter Rat geben.

Nein. Jeder Brick kann für sich alleine per USB angeschlossen werden. Du kannst mehrere Bricks parallel per USB an einem PC anschließen und alle zusammen dann über eine IP Connection erreichen. Der Master Brick Stapel bleibt so wie er ist. Den hast du wahrscheinlich per USB Kabel am PC angeschlossen. Den IMU Brick schließt du jetzt völlig unabhängig vom Master Brick Stapel mit einem weiteren USB Kabel am gleichen PC an.

Du musst bei den Pin Nummern aufpassen. Es gibt zwei Nummernsysteme. Einmal die GPIO Nummer und die Pin Nummer. In der dtoverlay Zeile ist der IRQ Pin als 25 angegeben, dass meint GPIO25 was Pin 22 (TP_IRQ) in deiner Tabelle entspricht. Als ich von Pin 25 sprach meinte ich GPIO25, sorry. https://github.com/Tinkerforge/hat-zero-brick/blob/master/hardware/hat-zero-schematic.pdf Du kannst hier im Schaltplan des HAT Zero Bricks sehen, welche Pins vom HAT Zero Brick verwendet werden (der gelbe Kasten rechts auf der ersten Seite stellt den Pin Header dar). Da kannst du sehen das SPI0 belegt ist. Dort hast du aber auch gerade den Touch Controller angeschlossen. Der IRQ Pin GPIO25 ist auch schon belegt. Du kannst jetzt versuchen, den Touch Controller an SPI1 anzuschließen, einen anderen freien Pin für den IRQ des Touch Controller zu nehmen und dann die dtoverlay Zeile anzupassen. Das wird aber alles nicht viel helfen. Das Problem liegt hier im Kernel: https://github.com/raspberrypi/linux/blob/34ae8ccc3d4c72b95aae68f2bd150246e44d6a5d/arch/arm/boot/dts/overlays/ads7846-overlay.dts Das ADS7846 Overlay erwartet fest mit dem spi0 Kernel Device zu arbeiten und deaktiviert auch gleich deaktiviert auch die Userland Devices spidev0 und spidev1. Daher kommt dann auch der "Could not open /dev/spidev0.0: ENOENT" Fehler im brickd.log, den brickd verwendet spidev0 um mit der SPI0 Schnittstelle zu kommunizieren. Es braucht also auch noch mindestens eine Overlay Anpassung im Kernel. Ich bin mir aber nicht mal sicher, ob spi1 und spidev0 so zusammenspielen können, so wie das für diesen Fall nötig wäre.

Die dtoverlay Zeile konfiguriert den Kernel Treiber für den ADS7846 Touch Screen Controller. Der penirq=25 konfiguriert wohl Pin 25 GPIO25 (Pin 22) als einen Interrupt Pin für das Display. Der HAT Zero Brick verwendet aber auch Pin 25 GPIO25 (Pin 22) als eine der Chip Select Pins. Das funktioniert so nicht. Ein Pin kann nicht gleichzeitig für zwei Funktionen verwendet werden. Wenn du die dtoverlay Zeile aktiv hast, dann kann brickd den Pin nicht mehr für seine Zwecke verwenden. Schau mal in die Log Datei /var/log/brickd.log. Dort sollten Fehlermeldungen über fehlgeschlagene Versuche stehen den HAT Zero Brick zu konfigurieren. Das ist so ohne weiteres nicht zu lösen, falls es überhaupt zu lösen ist, denn der ADS7846 Touch Screen Controller benötigt, wie der HAT Zero Brick auch, die SPI Schnittstelle des Raspberry Pis. Das Raspberry Pi hat zwei SPI Schnittstellen: spi0 und spi1. Bedingt durch Funktionseinschränkungen der spi1 Schnittstelle, funktioniert der HAT Zero Brick ausschließlich an spi0. Aus dieser Wikiseite über das Display leite ich ab dass dieses auch spi0 verwenden will: https://www.waveshare.com/wiki/5inch_HDMI_LCD Du müsstet also schauen wo Touch Controller und HAT Zero Brick bei den Pins und der SPI Schnittstelle kollidieren und versuchen diese Kollisionen zu lösen. Dazu wirst du dann wohl auch die Pins anders verbinden müssen durch einen selbstgebauten Adapter.

Versuchst du da die \x Escape Sequenz zu verwenden? Wenn ja, dann machst du das nicht richtig. Es muss \x und nicht /x heißen.

Ich habe mir das jetzt nicht alles im Detail angesehen, aber zumindest das hier tut nicht das was du denkst: for i in self.onewire: if i.get_identity() == uid: break # Wenn das Onewire Modul schon als Object in der Liste ist wird abgebrochen self.onewire.append(BrickletOneWire(uid, self.ipcon)) Die get_identity() Funktion gibt ein namedtuple zurück. Das mit uid zu vergleichen ist immer False. Du musst uid mit dem uid Feld des namedtuple vergleichen. Dann ist das break da nicht das richtige. Das bricht die for Schleife ab, aber der append() Aufruf danach wird trotzdem ausgeführt. Da muss du ein return verwenden um den gesamten Aufruf von cb_enumerate zu beenden. Etwa so: for i in self.onewire: if i.get_identity().uid == uid: return # Wenn das Onewire Modul schon als Object in der Liste ist wird abgebrochen self.onewire.append(BrickletOneWire(uid, self.ipcon)) So wie du es aktuell hast fügst du das Bricklet zweimal in deine Liste ein. Das könnte schon das ganze Problem sein.

Teste mal bitte die angehängt Version (siehe net40sn Verzeichnis). Ich habe hier gerade kein LabVIEW NXG zur Hand, aber diese Version lässt sich zumindest mit gacutil installieren. tinkerforge_labview_bindings_2_1_24_strong_name.zip

Brick Viewer 2.4.12 Fix RED Brick Server Monitoring support for Ambient Light Bricklet 3.0 and IO-4 Bricklet 2.0 Fix WIFI Extension 2.0 no-encryption configuration Add checkbox for setting the WIFI Extension 2.0 mesh password, old password is not shown anymore Improve firmware update error handling Fix RS485 Bricklet Modbus slave logic for write-multiple-registers function Improve RS485 Bricklet input field history handling Fix Data Logger support for Color Bricklet 2.0 Improve corner case handling in enumerate callback logic Fix error handling for RED Brick file upload Fix maximum number of LEDs for LED Strip Bricklet 2.0 Show milliseconds in GPS Bricklet 2.0 timestamp Downloads: Windows, Linux, macOS

Brick Viewer 2.4.12 RED Brick Server Monitoring Support für Ambient Light Bricklet 3.0 und IO-4 Bricklet 2.0 repariert WIFI Extension 2.0 No-Encryption Konfiguration repariert Checkbox für das Setzen des WIFI Extension 2.0 Mesh Passworts hinzugefügt, das alte Passwort wird nicht mehr angezeigt Firmware Update Fehlerbehandlung verbessert RS485 Bricklet Modbus Slave Logik für die Write-Multiple-Registers Funktion repariert Behandlung der RS485 Bricklet Eingabehistorie verbessert Data Logger Support für Color Bricklet 2.0 repariert Spezialfallbehandlung in der Enumerate Callback Logik verbessert Fehlerbehandlung für den RED Brick Datei-Upload verbessert Maximale LED Anzahl für das LED Strip Bricklet 2.0 korrigiert GPS Bricklet 2.0 zeigt Millisekunden an Downloads: Windows, Linux, macOS

Brick Logger 2.1.3 Fix support for Color Bricklet 2.0 Downloads: Windows, Linux, macOS, RED Brick

Brick Logger 2.1.3 Support für das Color Bricklet 2.0 repariert Downloads: Windows, Linux, macOS, RED Brick

So lange der RED Brick läuft zählt er seine Uhrzeit intern mit dem Prozessor weiter. Das ist aber auf Dauer nicht besonders genau. Neben NTP und RTC, wie Jan schon richtig vorschlägt, kannst du auch noch GPS als Zeitquelle nutzen, um die Uhrzeit des RED Bricks dauerhaft stabil zu halten. NTP funktioniert automatisch, sobald dein RED Brick Internetverbindung hat. Für RTC und GPS haben wir in der Dokumentation Beispielprogramme, die du auf den RED Brick hochladen kannst: https://www.tinkerforge.com/de/doc/Hardware/Bricks/RED_Brick.html#datum-uhrzeit

Firmwares: CAN Bricklet 2.0 2.0.4 Fix bit0 error handling in bus-off mode Download: CAN Bricklet 2.0

Firmwares: CAN Bricklet 2.0 2.0.4 Bit0 Fehlerbehandlung im Bus-Off Modus korrigiert Download: CAN Bricklet 2.0

Unexpected error ERANGE (34) occurred Die 34 da bedeutet nicht Zeile 34, sondern das der Fehler ERANGE die Nummer 34 hat. Kommt der Fehler wieder, wenn du die leere Zeile wieder einfügst? Häng doch mal bitte die ganze /etc/brickd.conf Datei an. Das # am Ende der websocket_port Zeile ist da nicht erlaubt. Kommentare können nicht am Ende einer Zeile stehen, sondern nur am Anfang. Das ist aber hier nicht das Problem. ERANGE besagt hier etwas anderes kaputt ist. Leider gibt die Meldung nicht her was genau das Problem ist. Ich werde das gleich mal verbessern.

Irgendetwas stimmt mit /etc/brickd.conf nicht und Brick Daemon kann sie nicht lesen. Führe bitte diesen Befehl auf dem Raspberry Pi aus: sudo brickd --check-config Der sollte ausgeben was mit /etc/brickd.conf nicht stimmt.

Wir können das Problem hier nachstellen. Das scheint ein Bug in den Perl API bindings zu sein, sorry. Wie arbeiten an einer Lösung.

Okay, mit einer neueren GCC Version können wir hier das Problem nachstellen. Es ist jetzt in der aktuellen GitHub Version behoben. https://github.com/Tinkerforge/master-brick/commit/80ded4b682ffb063fe88133eecf81c7770a9b6d2

Teste mal bitte #define logf(str, ...) {} durch #define logf(str, ...) ((void)0) zu ersetzen.

Dann leg mal bitte die Umgebungsvariable HTTPS_PROXY mit dem Wert www.example.com:3128 (natürlich angepasst auf deinen Proxy) an. Wenn du Brick Viewer startest sollte er dir das als Proxy Einstellung anzeigen.

Ich kann das Problem hier unter Linux mit Docker und dem aktuellen GitHub Stand der Master Brick Firmware nicht nachstellen. Hast du dir mit build_environment_setup.sh unter Linux oder in einer VM die Build Umgebung ausgesetzt, oder nutzt du das Docker Image?

Unfortunately. this ist not true. The CMP11 pyranometer outputs a 0 to 20 mV signal, this cannot be measured with a PTC Bricklet 2.0. The PTC Bricklet 2.0 is designed to measure the resistance of a PTC sensor. Also there is no Bricklet that can measure such small voltages accurately enough for this use case. There is the SMP series of pyranometers that output a 4 to 20 mA signal, that can be measured using an Industrial Dual 0-20mA Bricklet 2.0: https://www.rg-messtechnik.de/smp-pyranometer.php

ts555, was ich in Python tun müsste ist klar. Ich will aber vermeiden, dass händisch tun zu müssen, da Python das automatisch kann, wenn in Windows der Proxy richtig eingestellt ist. Bei dir scheint das aber nicht der Fall zu sein. Heißt das, dass du in jedem Programm, das sich mit dem Internet verbindet, auf deinem Firmen PC händisch den Firmen Proxy eingestellt hast? Versuch mal in Windows den Proxy einzustellen, anstatt für jedes Programm einzeln: Einstellungen -> Netzwerk und Internet -> Proxy -> Manuelle Proxyeinrichtung "Proxyserver verwenden" einschalten Adresse: www.example.com Port: 3128 "Proxyserver nicht für lokale Adressen verwenden" einschalten Änderungen mittels "Speichern" Knopf speichern. Die Werte für Adresse und Port habe ich jetzt entsprechend deines Beispiels gewählt. Da musst du natürlich deine richtig Proxy Konfiguration eintragen. Dann sollte dir das Brick Viewer beim Start auch anzeigen und die Firmware Abfrage sollte funktionieren.

ts555, du hast da noch einen anderen Bug gefunden. Du versuchst da gerade eine Co-Prozessor Bricklet Firmware auf ein nicht vorhandenes Bricklet an Port B des Master Bricks zu flashen. Das geht nicht. Das erzeugt diese falsche Fehlermeldung, da diese Situation in Brick Viewer nicht richtig behandelt wird. Ich habe das gerade für die nächste Brick Viewer Version behoben. Wenn du da jetzt das XMC1400 Breakout Bricklet mit dessen Standard-Firmware flashen würdest, dann sollte das funktionieren. Testet auch mal bitte diese Version: https://download.tinkerforge.com/_stuff/brickv_windows_2_4_11_snapshot_e750b42.exe Die zeigt beim Start jetzt eine Meldung mit der von Python erkannten Proxy Konfiguration an. Ich vermute das bei euch beiden nur eine Proxy Konfiguration für HTTP, aber nicht für HTTPS erkannt wird und das das Problem hier ist. Wenn ich hier testweise unter Windows 10 in den Windows Netzwerkeinstellungen als Proxy foobar.com:5544 einstelle, dann zeigt mir Brick Viewer das beim Start so an: http: http://foobar.com:5544 https: https://foobar.com:5544 ftp: ftp://foobar.com:5544 Wenn ich aber bei der Proxy Einstellung http://foobar.com:5544 eintrage, dann kommt das in Python nur als HTTP Proxy an: http: http://foobar.com:5544 Wie und wo ist bei euch der Proxy in Windows eingestellt?

Teste mal bitte diese beiden Versionen: https://download.tinkerforge.com/_stuff/brickv_windows_2_4_11_snapshot_9857a16_http.exe https://download.tinkerforge.com/_stuff/brickv_windows_2_4_11_snapshot_9857a16_https.exe Die HTTP Version ist der aktuelle Entwicklungsstand mit allen https://download.tinkerforge.com URLs auf http:// geändert. Die HTTPS Version ist der aktuelle Entwicklungsstand unverändert. Damit sollte jetzt raus zu bekommen sein, ob es rein an HTTPS liegt. Laut Dokumentation sollte Python automatisch einen in Windows eingestellten Proxy nutzen: https://docs.python.org/3.7/library/urllib.request.html#urllib.request.getproxies