photron

Frage ist jetzt was ist am Analog In Bricklet anders als mit den anderen Bricklets. Hast du das abgesetzt vom Stapel an einem langen Bricklet Kabel? Was misst du mit dem Analog In Bricklet? Hast du vielleicht die Schrittmotorkabel parallel zum Analog In Bricklet Kabel verlegt? Die Vermutung ist, dass du dort elektromagnetische Störungen einfängst, die dann die Kommunikation mit dem Bricklet stören. Beobachte mal im Betrieb mit dem Health Monitor die Fehlerzähler. Gibt es bestimmte Situation in denen diese steigen? Zum Beispiel, wenn die Schrittmotoren laufen?

Der Fehler kommt daher, dass die Bindings eine beschädigte Antwort empfangen haben. Es steht noch auf der TODO Liste diesen Fehler besser zu behandeln. Das ist aber kein Bug in den Bindings, sondern die Antwort wurde vom Brick(let) entweder schon beschädigt losgeschickt, oder ist auf dem Weg beschädigt worden. Wie ist dein Stack angeschlossen? USB, WLAN oder Ethernet? Ist ein RED Brick involviert? Wie sehen die Fehlerzähler im Brick Viewer Health Monitor aus? Im besten Fall sind alle 0, oder ändern sich zumindest nicht. Falls diese durchgängig steigen dann ist deine Bricklet Kommunikation durch die Umgebung gestört. Die Kommunikation kann ein gewisses Level an Störung kompensieren, ab einem bestimmten Level greift das aber nicht mehr und beschädigte Antworten kommen durch.

Nein, zwischen Bricklets darf so nicht gebrückt werden. Dadurch würde die Messung des Kabelwiderstandes verfälscht. Wenn du Adern sparen musst, dann empfehle ich einen Dreileiter-Pt-Sensor. Bei der Dreileitermessung wird angenommen, dass der Kabelwiderstand in beiden Pfaden gleich ist und es daher reicht nur den Kabelwiderstand in einem Pfad zu messen.

Das Thermocouple Bricklet 2.0 kann die Kabellänge nicht kompensieren. Mir sind aber auch keine Vierleiter-Thermocouple-Sensoren bekannt. Das PTC Bricklet 2.0 für Pt100 und Pt1000 Sensoren kann mit Zwei-, Drei- und Vierleiter-Pt-Sensoren umgehen und bei Drei- und Vierleitermessung auch die Kabellänge kompensieren.

Es hat also mal funktioniert jetzt aber nicht mehr? Hast du mal mit frischen Batterien versucht? Vielleicht reicht es noch für die LED aber nicht mehr für die Funkverbindung. Hat sich die Antenne am Outdoor Weather Bricklets losgeschraubt? Hat sich irgendwas in der Funkstrecke geändert, das jetzt den Empfang schwächt? Vielleicht die Regentonne umgestellt? Die Timeout-Anzeige im Brick Viewer bezieht sich auf die Verbindung Brick Viewer zu Outdoor Weather Bricklet, nicht zu Wetterstation.

Die wenigsten USB Hubs sind wirklich gut. Die meisten haben irgendwelche Probleme. Ich hätte auch die USB Kabel selbst in Verdacht. Ich habe hier im Laufe der Firmengeschichte son mehrere USB Kabel auf der A und der Mini B Seite ausgenudelt.

Die Bytefolge 00 00 00 00 0A E6 08 00 00 00 ist an sich erstmal ein fast gültiges Packet. Das könnte ein interne Enumerate Connected Request sein, das aber nie über USB raus geht. Die Bytefolge hat allerdings das Längenbyte auf 0A statt 08 stehen. Ich kann dir nicht erklären warum das passiert. Gegenfrage: Das Auftauchen und Verschwinden der Bricks an USB und diese ungültigen Packets tauchen alle nur in Verbindung mit dem USB Hub auf, oder? Funktioniert der Stack denn, abgesehen von der Invalid-UID Meldung?

Dass libusbK und UsbDk fehlen ist normal und erwartet. Der normale Brick Daemon findet aber die Bricks? Das keine Bricks gefunden werden liegt an diesem speziellen Brick Daemon, oder? Starte brickd bitte mit Debug Logging (--debug). Da das viel Ausgabe erzeugt solltest du das direkt in eine Datei schreiben lassen (--log-to-file <pfad-zur-datei>). brickd.exe --console --debug --log-to-file brickd-debug.log Nach dem Start 10 Sekunden laufen lassen, dann mit Ctrl+C beenden und die brickd-debug.log Datei hier anhängen.

@MBOBHast du ab und zu Timeouts, oder treten den Timeouts ab einem gewissen Zeitpunkt durchgehend auf und es funktioniert dadurch nichts mehr bis du den Aufbau from Strom trennst?

Dann bau mal testweise den defekten Stepper Brick aus, um zu sehen ob der das Timeout Problem auslöst.

Ich habe dazu mal ein kleines Beispiel gemacht: https://github.com/Tinkerforge/thermal-imaging-bricklet/blob/master/software/examples/python/example_opencv_high_contrast.py https://github.com/Tinkerforge/thermal-imaging-bricklet/blob/master/software/examples/python/example_opencv_temperature.py

Ich rate mal und sage du meinst diese Meldung: Exception in thread "main" com.tinkerforge.TimeoutException: Did not receive response in time for function ID -1 Die -1 ist ein falsch dargestelltes Byte und soll 255 sein. Das ist ein Darstellungs-Bug in den Java Bindings. Wird behoben. auf Dauer zeigen wir da vermutlich einfach den Funktionsnamen und nicht die ID an. 255 ist die Funktions ID für die getIdentity Funktion. Die Bindings rufen beim ersten Aufruf den dein Programm macht intern getIdentity auf, um zu prüfen ob der Brick/Bricklet vom Typ her zur Bindings Klasse passt, die du instanziiert hast. Das gibt dir da keine weitere Information, du läufst da einfach in einen Timeout rein, sprich die Kommunikation ist gestört, oder du versuchst Bricks/Brciklets anzusprechen die nicht angeschlossen sind. Taucht der Stapel sauber in Brick Viewer auf? Hast du vielleicht einfach den Stapel nicht ordentlich zusammengesteckt? Ist der Stapel nicht verschraubt und hat einen Stoß bekommen?

Interessant ist das widersprüchliche Timeout verhalten. Ruf am Anfang mal set_response_expected_all(True) auf das OLED Bricklet Objekt auf. Das ändert nichts am Bricklet selbst, sondern gibt dem Bindings Objekt vor für alle Aufrufe auch eine Antwort anzufragen, da sonst nicht alle Funktionen eine Antwort auf Protokollebene erhalten, wenn keine notwendig ist. Seit kurzem hat der Brick Viewer einen Health Viewer, der die Fehlerzähler aller angeschlossenen Bricks und Bricklets anzeigt. Normalerweise sollte Zähler alle 0 sein. Du könntest mal beobachten wie sich die bei dir verhalten, im Fehlerfall und im Normalfall. Für Bricks werden diese Zähler für ihre Ports aufgeschlüsselt angezeigt. Selbst wenn das OLED Bricklet nicht mehr im Brick Viewer auftaucht kannst du zumindest noch die Fehlerzähler für dessen Port ansehen. Interessant wäre vielleicht auch das Programm ansehen zu können, wenn du das vorzeigen kannst/willst.

https://www.tinkerforge.com/de/doc/Downloads.html Erwarten würde ich ein Problem im OLED Bricklet selbst. Es gibt in den letzten Firmware Versionen aber keine offensichtlich relevanten Änderungen. Die Frage nach aktueller Firmware zielt darauf ab zu vermeiden einen alten, bereits behobenen Bug, zu suchen. Ist die Firmware auf dem OLED Bricklet aktuell? Das Timeout-Verhalten ist unerwartet. Dass nach dem Auftreten des Problems das OLED Bricklet nicht mehr in Brick Viewer auftaucht deute darauf hin, dass das Bricklet die Kommunikation eingestellt hat. Das hier würde ich genauer betrachten. Ja, der RED Brick ist intern einfach ein Debian Linux. Du kannst also einfach reboot aufrufen. Da die Programm auf dem RED Brick aber als User tf laufen musst du das so machen: os.system('echo tf | sudo -S -p "" reboot') Wobei ich nicht erwarte, das das hier hilft.

Was heißt Neustart hier? Per Software Reboot des RED Brick, oder Reset des Master Bricks, oder Power Cycle durch Unterbrechung der Stromversorgung des ganzen Aufbaus? Sind alle Firmwares auf den Bricks und Bricklets aktuell? Die Vermutung ist, dass das OLED Bricklet abstürzt. Dass es auch nicht mehr im Brick Viewer auftaucht, heißt, dass es nicht mehr auf Anfragen antwortet. Da das Programm weiter läuft und keine Fehler auftreten gehe ich davon aus, dass Timeout-Fehler behandelt werden. Das Programm also damit umgehen kann, wenn das Bricklet nicht mehr antwortet.

Die 4 Anschlüsse auf dem Streifen selbst sind mit +12V, G(reen), R(ed) und B(lue) gekennzeichnet. Das ist also ein "dummer" Streifen. Dort können nur alle LEDs gleichzeitig in der gleichen Farbe leuchten. Das LED Strip Bricklet ist für "smarte" Streifen, bei denen jede LED einzeln gesteuert werden kann. Sprich, der Streifen ist nicht kompatible mit dem LED Strip Bricklet.

Welcher Fehler tritt denn da auf? An sich ist das erlaubt.

Es ist kein FI-Schalter im WARP Charger verbaut. Der WARP Charger ist mit einer DC-Fehlerstromerkennung ausgestattet. Dadurch kann der WARP Charger an einem normalen 30mA Typ A FI-Schalter betrieben werden. Das ein Typ B FI-Schalter in der Betriebsanleitung als Ersatzteil aufgeführt ist, ist ein Fehler auf unserer Seite. In Betriebsanleitung Version 1.2.5 ist dieser korrigiert und der Typ B FI-Schalter aus der Ersatzteilliste entfernt. Danke für den Hinweis. Hintergrund dazu: In der frühen Phase der Entwicklung war vorgesehen in der Wallbox einen Typ B FI-Schalter zu verbauen. Das wurde aber wieder verworfen und durch die auch aktuell verbaute DC-Fehlerstromerkennung ersetzt. Da wir aber noch einige Typ B FI-Schalter auf Lager haben verkaufen wir diese in unserem Shop ab. Ich habe jetzt den Shop-Eintrag um den Hinweis ergänzt, dass im WARP Charger kein FI-Schalter verbaut ist und auch kein Typ B FI-Schalter zum Betrieb notwendig ist, sondern ein normaler 30mA Typ A FI-Schalter ausreicht. Sorry, für die Verwirrung, die jetzt hoffentlich aufgeklärt ist.

Im Prinzip richtig, aber im WARP Charger ist kein FI-Schalter (weder Typ A noch Typ B) verbaut, sondern eine DC-Fehlerstromerkennung. Durch die Kombination DC-Fehlerstromerkennung im WARP Charger und Typ A FI-Schalter im Sicherungskasten entsteht in Summe die Funktionalität eines Typ B FI-Schalters. Der WARP Charger kann also normal angeschlossen werden, ohne das es zu Problemen mit einer Reihenschaltung von FI-Schaltern kommt.

Das RS485 Bricklet arbeitet auf Arrays von 1-Zeichen Strings. Du kannst die \x Escapesequenz oder die chr Funktion verwenden, um beliebig Bytes zu übergeben. Die Hex-Folge F1 00 05 29 1E kannst du mit \x Escapesequenz so schicken: $rs485->write(array("\xF1", "\x00", "\x05", "\x29", "\x1E")); Oder mit chr Funktion so: $rs485->write(array(chr(0xF1), chr(0x00), chr(0x05), chr(0x29), chr(0x1E))); Die Antwort im Callback kommt auch als Array von 1-Zeichen Strings. Diesen kannst du dann mit der ord Funktion so in Bytes umwandeln: foreach ($message as $char) { $byte = ord($char); echo dechex($byte) . "\n"; }

Beides. Ein Typ 2 Kabel hat in jedem Stecker lokal einen PP Widerstand verbaut. Auf der Autoseite einen für das Auto und auf der Wallbox-Seite einen für die Wallbox. Es gibt also keine PP Leitung im Kabel selbst, es gibt nur die CP Leitung. Im Falle eines fest angeschlossenen Kabels, wie beim WARP Charger, ist der PP Widerstand für die Wallbox-Seite in der Wallbox verbaut. Der hat aber nichts mit dem PP Widerstand auf der Autoseite zu tun. Daher kann die Wallbox PP nicht trennen, denn sie hat keinen Zugriff auf die Autoseite. 1P/3P Umschaltung scheint kein einfaches Thema zu sein. OpenWB unterstützt das für die Zoe überhaupt nicht. https://openwb.de/forum/viewtopic.php?f=4&t=3063 In dem Thread sagt einer der Entwickler, sie hätten beim Testen eine Zoe zerstört (altes Model), laut Renault wäre das Verhalten aber beim neuen Model gleich geblieben: https://openwb.de/forum/viewtopic.php?p=31505#p31505 Im gleichen Thread behaupten Leute es gäbe Wallboxen die 1P/3P mit der Zoe könnten. Auf Anhieb schwer zu sagen was da jetzt die Wahrheit ist.

Wenn du das im ExecStop des brickd Services machst, dann hat das denn Nachteil, dass das auch gemacht wird wenn brickd aus anderen Gründen (z.B. Update) gestoppt/neugestartet wird. Bei Requires= scheint das Problem zu sein, dass das keine Reihenfolge definiert. Teste mal mit After=brickd.service in deiner ursprünglichen Service Datei. Laut systemd Doku wird dadurch dein Service nach brickd gestartet und vor brickd beenden: https://www.freedesktop.org/software/systemd/man/systemd.unit.html

Du kannst beides machen, die Hardware direkt reagieren lassen, oder dir einen Callback schicken lassen, damit deine Software reagieren kann. Schau dir mal die set_gpio_action Funktion des Bricklets an.

Das hat nichts mit dem Linken zu tun. Du kannst pro IPConnection Objekt ein funktionales LEDStripV2 Object haben, da die IPConnection intern eine Tabelle hat die eine UID eindeutig auf ein Device Objekt abbildet. Wenn du ein weiteres Device Objekt für eine UID anlegst mit einer IPConnection bei der für diese UID schon ein Device hinterlegt ist, so wird das alte Device durch das neue verdrängt und nur noch das neue Device Objekt kann mit dem Brick/Bricklet kommunizieren. Du kannst aber ohne Probleme in einem Programm parallel mehrere IPConnections mit jeweils einem Device Objekt haben die auf die gleiche UID verweisen. Ähnlich funktioniert das für die Registrierung von Callbacks. Jedes Device Objekt hate eine Tabelle die eine Callback ID eindeutig auf einen Fuktionspointer zuweist. Wenn du einen Callback nochmal registrierst der auf diesem Device Objekt schon registriert wurde, dann wird der alte Funktionspointer verdrängt und nur noch der neue wird aufgerufen werden. All dies passiert nur bei dir lokal im Programm, ohne jegliche Kommunikation mit der Hardware. Was das passiert ist, dass eine Zuordnung zwischen eingehenden Antworten (Getter und Callbacks) und den Device Objekten und Callback Funktionspointern hergestellt wird. Dadurch weiß die IPConnection dann wohin mit den Antworten. Da kann dir erstmal keiner dazwischen fummeln. Was dir jetzt passieren kann ist dass zwei Programme die gleichzeitig laufen sich in die Quere kommen. Zum Beispiel kann dein Programm den Frame-Started-Callback aktivieren und ein anderes Programm diesen wieder deaktivieren. Denn die Information ob der Callback an oder aus ist ist auf dem Bricklet gespeichert, da das Bricklet wissen muss ob es den schicken muss oder nicht. Das ist also global und nicht lokal in deinem Programm. Ähnlich ist dass dann auch mit dem Setzen der LEDs, wenn das dein Programm und ein anderes Programm gleichzeitig machen kommt am Ende Quatsch bei rum. Zu Brick Viewer: Hier werden nur dann Callbacks verwendet, wenn es nicht anders geht, oder der Callback nicht konfiguriert werden muss. Beim Anwählen des LED Strip 2.0 Tabs in Brick Viewer wird geprüft ob der Frame-Started-Callback aktiv ist. Falls ja passiert nichts. Falls nein, dann aktiviert Brick Viewer den Callback und merkt sich das. Beim Abwählen des Tabs prüft Brick Viewer ob der Callback vorher aus war und aktiviert wurde. Falls ja wird der Callback wieder deaktiviert. Falls nein passiert nichts.

Zu dem Zeitpunkt an dem dein Serivce ausgeführt läuft Brick Daemon schon nicht mehr. Du musst das also so bauen, dass dein Service ausgeführt wird bevor der brickd Service beendet wird. Du kannst mal versuchen im [Unit] Abschnitt ein Requires=brickd.service anzugeben, wobei mir nicht klar ist ob sich das wie gewünscht auswirkt, da für Wants=, Requires= und Requisite= nur die Auswirkung auf das Startverhalten dokumentiert ist.