photron

Ja.

Ja.

Die Bricks mit 10 Pol Stecker haben I2C auf dem 10 Pol Stecker. Dies ist aber nur für interne Zwecke und nicht über die API der Bricks zugreifbar. Darüber kannst du keinen beliebigen I2C Sensor auslesen. Der HAT Brick schließt am I2C Anschluss des Raspberry Pis eine Real-Time Clock an und lädt den passenden Kernel Treiber per Device Tree dafür. Dadurch ist die I2C Schnittstelle des Raspberry Pis belegt. Der HAT Zero Brick (der auch auf einem normal großen Raspberry Pi passt) lässt den I2C Anschluss des Raspberry Pis frei. Allerdings musst du dir dann einen Adapter basteln, um an die Pins zu kommen. Dort kannst du dann mit python-smbus arbeiten. Alternativ zum HAT (Zero) Brick, kannst du auch einen Master Brick per USB anschließen, um Tinkerforge Bricks und Bricklets zu verwenden und hast so den Pin Header des Raspberry Pis frei, um dessen I2C Anschluss nutzen zu können.

Das ist nicht normal. Was hast du denn so am Industrial Counter, Analog In und IO-16 Bricklet angeschlossen? Wie lang sind die Bricklet Kabel und sonstige Kabel? Wie versorgst du den Stapel mit Strom? PoE, Step-Down Power Supply oder USB Netzteil? Über das Multimeter solltest du keine statische Entladung hinbekommen, außer deine Hand kommt dem Aufbau dabei sehr nah. Bist du sicher, dass das nicht vielleicht ein Wackelkontakt ist und du beim messen/berühren den Aufbau bewegst und das das Problem erzeugt? Was musst du tun, damit die Ethernet Extension wieder erreichbar wird? Kannst du ein Foto vom aufbau zeigen?

Windows speichert sich in der Registry Informationen zu jedem jemals angeschlossenen USB Gerät. Das diese Informationen so verfälscht/beschädigt werden können, dass das zu diesem Verhalten führt war mir nicht bekannt. Gut zu wissen.

Nein, das ist ein anderes Problem. Das Problem vom FlyingDoc ist ein internes Socket Problem, das brickd aus dem Tritt bringt. Du hast eher einen Wackelkontakt in der USB Verkabelung der zu Fehlern in der USB Kommunikation führt. Es geht hier um eine IMU, die an einem PC funktioniert, aber an einem anderen nicht mehr? Von den Fehlermeldungen her sieht das wie gestörte USB Kommunikation aus. Da die IMU an einem PC funktioniert, gehe ich davon aus, dass das Problem nicht direkt an der IMU liegt. Ich tippe auf ein beschädigtes USB Kabel oder auf einen Wackelkontakt an der USB Buchse am PC. Verwendest du in beiden Fällen das selbe USB Kabel, oder testet du mit zwei verschiedenen USB Kabeln? Wenn du mit zwei verschiedenen USB Kabeln testet, dann teste bitte das Kabel vom funktionierenden PC am nicht-funktionierenden PC, um zu sehen ob es am Kabel liegt. Teste am nicht-funktionierenden PC andere USB Buchsen, um zu sehen ob es die eine USB Buchse ist. Teste am nicht-funktionierenden PC andere USB Geräte an der Buchse an der die IMU nicht funktioniert, um zu sehen ob es die eine USB Buchse ist.

Bindings: JavaScript 2.1.27 Also call return-callbacks for pure setters Download: JavaScript

Bindings: JavaScript 2.1.27 Return-Callbacks auch für reinen Settern aufrufen Download: JavaScript

Firmware: LCD 128x64 Bricklet 2.0.8 Keine leeren Tabs anzeigen Keine falsche Antwort für die remove-gui-tab Funktion senden Download: LCD 128x64

Firmware: LCD 128x64 Bricklet 2.0.8 Don't draw empty tabs if less than 3 are active Don't send wrong response from remove-gui-tab function Download: LCD 128x64

Bindings: Go 2.0.7 Fix response length validation for empty responses Download: Go

Bindings: Go 2.0.7 Response Längenprüfung für reine Setter repariert Download: Go

Ich habe das Beispiel noch mal angepasst, damit zwischendrin der limited_count nicht außerhalb des erlaubten Bereichs liegen kann.

Dazu nimmst du nicht den Wert selbst, sondern nimmst den aktuellen Wert, ziehst davon den letzte Wert ab. Das Ergebnis davon addierst du dann zu deinem beschränkten Wert und beschränkst den beschränkten Wert dann wieder... hm, ziemlich beschränkt. Versteht wahrscheinlich so keiner. Hier ein Python Beispiel: #!/usr/bin/env python # -*- coding: utf-8 -*- HOST = "localhost" PORT = 4223 UID = "XYZ" # Change XYZ to the UID of your Rotary Encoder Bricklet 2.0 from tinkerforge.ip_connection import IPConnection from tinkerforge.bricklet_rotary_encoder_v2 import BrickletRotaryEncoderV2 UPPER_LIMIT = 10 LOWER_LIMIT = -10 last_count = None limited_count = None # Callback function for count callback def cb_count(count): global last_count global limited_count if last_count == None: last_count = count if limited_count == None: limited_count = count limited_count = min(max(limited_count + count - last_count, LOWER_LIMIT), UPPER_LIMIT) last_count = count print("Count: " + str(count)) print("Limited Count: " + str(limited_count)) print("") if __name__ == "__main__": ipcon = IPConnection() # Create IP connection re = BrickletRotaryEncoderV2(UID, ipcon) # Create device object ipcon.connect(HOST, PORT) # Connect to brickd # Don't use device before ipcon is connected # Register count callback to function cb_count re.register_callback(re.CALLBACK_COUNT, cb_count) # Set period for count callback to 50ms without a threshold re.set_count_callback_configuration(50, True, "x", 0, 0) input("Press key to exit\n") # Use raw_input() in Python 2 ipcon.disconnect() Die limited_count Variable hält den Zählerwert, der hier zwischen -10 und +10 beschränkt wird. Auf limited_count wird jeweils die Änderung des eigentlichen Zählerwerts des Rotary Encoders addiert. Dadurch bleibt limited_count zwischen -10 und +10, reagiert aber wie gewünscht auf alle Änderungen von count, dabei spielt der eigentliche Wert von count keine Rolle, sondern nur dessen Änderungen.

The space between -Xms and 64M is the problem. It has to read -Xms64M.

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.