photron

Das ist ein Fehler in den Bindings. Teste mal bitte die angehängte Version. tinkerforge_go_bindings_2_0_7_beta_1.zip

Okay, ich kann das Problem nachstellen mit einem Stück Panzerband und zwei Stück Druckerpapier über dem Sensor. Es tritt auch häufiger auf je kleiner der Messbereich. Bei 0-600 Lux und 50 ms tritt das fast durchgehend auf in diesem Aufbau. Ich habe mir mal testweise die Firmware so umprogrammiert, dass sie mir den Wert und das Invalid getrennt ausgibt, damit ich sehen kann welcher Wert dabei rum kommt, wenn Invalid gesetzt ist. Es kommen dann immer 0 Lux bei rum, wenn Invalid gesetzt ist in diesem Wenig-Licht-Test. Wenn ich aber mit viel Licht teste, dann sehe ich beim Wechsel von Valid auf Invalid einen Sprung von so 60000 Lux. Ich kann also da auch nicht einfach das Invalid ignorieren. Mit dieser Erkenntnis werde ich erstmal die Dokumentation anpassen müssen und dort nicht mehr von gesättigt sprechen können, sondern davon, dass sich der Sensor nicht sicher über den Messwert ist und dies bei sehr viel Licht oder sehr wenig Licht auftreten kann. Zusätzlich könnte man die API des Bricklets erweitern, um den Illuminance Wert und das Invalid Flag getrennt abfragen zu können, und nicht so wie jetzt in einen Wert gemischt. Ich habe dir mal zum Testen eine Firmware Version angehängt, die das Invalid Flag einfach ignoriert. ambient-light-v3-bricklet-firmware-202-no-invalid.zbin

Ja, Status LED ist aus. Dieser feste zeitliche Ablauf lässt mich denken, dass das Bricklet da korrekt misst und du wirklich kurzzeitig Sättigung sieht. 6:13 Uhr ist nah an Sonnenaufgang dran. Ist das vielleicht irgendeine Reflektion (CDs im Obstbaum des Nachbarn?) oder sonstige Lichtquelle die da morgens auftritt? Teste doch nochmal mit dem Kochtopf. Wenn das ein Problem/Fehler mit dem Bricklet ist, dann müsste das ja auch unter dem Topf auftreten. Wenn das ein Effekt der Umgebung ist dann schirmt der Topf das vielleicht ab.

Ich habe das jetzt mal nur mit Ambient Light Bricklet 3.0 an einem Master Brick per USB angeschlossen seit gestern Laufen lassen, mit deinen Einstellungen, und das Problem tritt nicht auf. Ich habe das noch nicht in deinem Gesamtaufbau getestet.

This is not possible from a single enumerate callback, as you already figured out. Possible solutions: a) In the Isolator enumerate callback you remember its UID and port. In the IDAI enumerate callback you compare the connected UID (this is the UID of the Isolator) to the Isolator UID/Port pairs you have remembered. b) In the IDAI enumerate callback you use the connected UID (this is the UID of the Isolator) to call the get-identity function of the Isolator to get its port.

Mit welchen Einstellungen arbeitet du da genau? Welche Illuminance Range? Welche Integration Time? Hast du den Callback mit value-has-to-change auf true oder false bei 1000ms Periode laufen? Was hast du sonst noch so an Bricks und Bricklets in deinem Aufbau und wie sind die verbunden? Ist auf allen Bricks und Bricklets die aktuelle Firmware (Brick Viewer zeigt das an)? Wenn nicht, ändert ein Update etwas an dem Verhalten? Sprich, ich würde gerne deine Aufbau möglichst exakt nachbauen, um zu sehen ob ich das Problem nachstellen kann.

Das Datenblatt schweigt sich darüber aus was ALS_Data_Valid heißt. Experimentell zeigt sich aber, dass das auf Invalid geht wenn der Messwert intern im Sensor zu groß wird. Das kannst du selbst mit einer Lichtquelle nah am Sensor testen. Dazu am besten die Illuminance Range auf Unlimited stellen. Bis zu einer bestimmten Helligkeit misst der Sensor noch und dann kommt springt er auf Invalid. Daher habe ich daraus abgeleitet, dass der Sensor dann gesättigt ist, bzw. der interne Messwert überläuft. Dazu passt auch, dass der Wert bei dem da passiert kleiner wird je länger die Integration Time ist. Aus dem Datenblatt geht nicht zwingend hervor, dass man den Messwert auslesen MUSS wenn das Status Register sagt, dass ein neuer Wert vorliegt. Wenn das so wäre, dann würde kein neuer Wert vom Sensor mehr geliefert, wenn der Wert einmal Invalid gewesen wäre und das Bricklet ihn dann nicht ausgelesen hätte. Der Hinweis auf Seite 19 besagt nur, dass man zwingend alle 4 Register des Messwertes auslesen muss, wenn man das erste Register gelesen hat. Das hat den Zweck zu verhindern, dass der Sensor den Messwert in den 4 Registern ändert während das Bricklet den Wert ausließt. Wenn das passieren würde, dann könnte es vorkommen, dass das Bricklet die ersten 2 Register gelesen hat, dann den Sensor die 4 Register aktualisiert und das Bricklet dann die letzten 2 Register liest, die aber jetzt einen Wert beinhalten der nicht mehr zu den 2 schon gelesenen Registern gehört, der Wert also verfälscht ist. Da das Bricklet aber immer alle 4 Register in der Reihenfolge und am Stück ausließt wie es das Datenblatt vorschreibt, kann das nicht das Problem sein.

Bindings: C/C++ 2.1.28, C# 2.1.26, Delphi/Lazarus 2.1.27, Go 2.0.6, Java 2.1.26, JavaScript 2.1.26, LabVIEW 2.1.25, Mathematica 2.1.25, MATLAB/Octave 2.0.26, MQTT 2.0.9, Perl 2.1.26, PHP 2.1.25, Python 2.1.25, Ruby 2.1.25, Rust 2.0.14, Shell 2.1.25, Visual Basic .NET 2.1.25 Properly check device-identifier and report mismatch between used API bindings device type and actual hardware device type [All except Rust] Fix race condition between device constructor and callback thread [All except Go, JavaScript, PHP and Rust] Fully initialize device before adding it to an IP Connection [JavaScript and PHP] Add set/get-flux-linear-parameters functions to Thermal Imaging Bricklet API [All] Add set/get-frame-readable-callback-configuration functions and frame-readable callback to CAN (2.0), RS232 (2.0) and RS485 Bricklet API [All] Add set/get-error-occurred-callback-configuration functions and error-occurred callback to CAN Bricklet 2.0 API [All] Add read-frame function to RS232 Bricklet API [All] Add write/read-bricklet-plugin functions to all Brick APIs for internal EEPROM Bricklet flashing [All] Add set-bricklet-xmc-flash-config/data and set/get-bricklets-enabled functions to Master Brick 3.0 API for internal Co-MCU Bricklet bootloader flashing [All] Validate response length before unpacking response [All] Properly report replaced device objects as non-functional [All except Go and Rust] Properly lock devices table during modification and lookup [Delphi/Lazarus] Fix bool array unpacking [JavaScript and Perl] Don't use signal SIGQUIT, not supported on Windows [MQTT] Warn about device replacement because of conflicting UIDs [MQTT] Add support for duplicate topics in init file [MQTT] Fix callbacks with one array parameter [Perl] Download: C/C++, C#, Delphi/Lazarus, Go, Java, JavaScript, LabVIEW, Mathematica, MATLAB/Octave, MQTT, Perl, PHP, Python, Ruby, Rust, Shell, Visual Basic .NET

Bindings: C/C++ 2.1.28, C# 2.1.26, Delphi/Lazarus 2.1.27, Go 2.0.6, Java 2.1.26, JavaScript 2.1.26, LabVIEW 2.1.25, Mathematica 2.1.25, MATLAB/Octave 2.0.26, MQTT 2.0.9, Perl 2.1.26, PHP 2.1.25, Python 2.1.25, Ruby 2.1.25, Rust 2.0.14, Shell 2.1.25, Visual Basic .NET 2.1.25 Device-Identifier Prüfung hinzugefügt, Abweichungen zwischen API Bindings Device Type wirklichem Hardware Device Type werden als Fehler gemeldet [Alle außer Rust] Race Condition zwischen Device Konstruktor und Callback Thread vermieden [Alle außer Go, JavaScript, PHP und Rust] Devices werden vollständig initialisiert bevor sie einer IP Connection hinzugefügt werden [JavaScript und PHP] set/get-flux-linear-parameters Funktionen zur Thermal Imaging Bricklet API hinzugefügt [Alle] set/get-frame-readable-callback-configuration Funktionen und frame-readable Callback zur CAN (2.0), RS232 (2.0) and RS485 Bricklet API hinzugefügt [Alle] set/get-error-occurred-callback-configuration Funktionen und error-occurred Callback zur CAN Bricklet 2.0 API hinzugefügt [Alle] read-frame Funktion zur RS232 Bricklet API hinzugefügt [Alle] write/read-bricklet-plugin Funktionen zu allen Brick APIs hinzugefügt für internes EEPROM Bricklet Flashen [Alle] set-bricklet-xmc-flash-config/data und set/get-bricklets-enabled Funktionen zur Master Brick 3.0 API hinzugefügt für internes Co-MCU Bricklet Bootloader Flashen [Alle] Response Länge wird geprüft bevor Response entpackt wird [Alle] Ersetze Devices Objekte werden als nicht-funktional gemeldet [Alle außer Go und Rust] Zugriff auf Devices Table wird durch Mutex geschützt [Delphi/Lazarus] Entpacken von Bool Arrays repariert [JavaScript und Perl] SIGQUIT wird nicht verwendet da es auf Windows nicht vorhanden ist [MQTT] Ersetzungen von Device bedingt durch fehlerhafte UID Überschneidungen erzeugen eine Warnung [MQTT] Support für mehr als eine Message pro Topic zu init Datei hinzugefügt [MQTT] Callbacks mit einem Array Parameter repariert [Perl] Download: C/C++, C#, Delphi/Lazarus, Go, Java, JavaScript, LabVIEW, Mathematica, MATLAB/Octave, MQTT, Perl, PHP, Python, Ruby, Rust, Shell, Visual Basic .NET

Mir ist unklar was du genau meinst, mit "Strom unterbrechen" und warum das einen Unterschied bezüglich Eingang/Ausgang machen sollte. Beschreibe mal bitte deinen Aufbau genauer. Was misst du und wie ist das alles elektrisch mit einander verbunden? Ein Schaltplan deines Aufbaus wäre hier hilfreich. Abhängig davon was du genau misst und wie das elektrisch im Bezug zum Voltage/Current Bricklet 2.0 steht kann ein Isolator Bricklet notwendig sein.

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.