photron

Please try this example. I think the critical difference is the disable_read_callback() function call here. If you have the Brick Viewer tab for the RS232 Bricklet open, then the read callback is enable and the read() function call will return empty in that case. You should close Brick Viewer before testing this example. #!/usr/bin/env python # -*- coding: utf-8 -*- HOST = "localhost" PORT = 4223 UID = "XYZ" # Change XYZ to the UID of your RS232 Bricklet import time from tinkerforge.ip_connection import IPConnection from tinkerforge.bricklet_rs232 import BrickletRS232 # Convert string to char array with length 60, as needed by write def string_to_char_list(message): chars = list(message) chars.extend(['\0']*(60 - len(message))) return chars, len(message) # Assume that the message consists of ASCII characters and # convert it from an array of chars to a string def char_list_to_string(message, length): return ''.join(message[:length]) if __name__ == "__main__": ipcon = IPConnection() # Create IP connection rs232 = BrickletRS232(UID, ipcon) # Create device object ipcon.connect(HOST, PORT) # Connect to brickd # Don't use device before ipcon is connected # Ensure read callback is disabled, otherwise the read call will return empty rs232.disable_read_callback() # Send request rs232.write(*string_to_char_list('S02\r\n')) rs232.write(*string_to_char_list('MSV?\r\n')) # Wait for response time.sleep(1) # Read response message = char_list_to_string(*rs232.read()) print('Message: ' + repr(message)) ipcon.disconnect()

As the "Not connected" error indicates, you didn't connect the IP Connection. Take a look at any of our Python examples. Before the can.reset() call you have to call ipcon.connect(HOST, PORT). But you should figure out where the bit1 errors are coming from. Double check you electrical CAN bus connection. Did you mix up CAN-low and CAN-high? Also, your post seem to be from May 28 2021, but you seem to have registered your account on August 23 2021 (yesterday). This is confusing me.

Aus dem 10p Stecker entfallen Pin 4, 5 und 6. Der Rest ist dann gerade auf den 7p Stecker durchverbunden. Also 1 -> 1, 2 -> 2, 3 -> 3, 7 -> 4. 8 -> 5, 9 -> 6, 10 -> 7.

Pin 1 ist auf dem HAT Zero Brick nicht angeschlossen. Siehe Schaltplan: https://github.com/Tinkerforge/hat-zero-brick/raw/master/hardware/hat-zero-schematic.pdf Du musst Pin 2 mit 5V versorgen. Daraus macht sich der HAT Zero Brick dann selbst 3,3V. Deine getDeviceInfo Funktion gibt Wortschrott aus, weil du dem tf_hal_printf Aufruf für %s eine String Instanz mit gibst. Die tf_hal_printf Funktion erwartet aber für %s einen char Pointer. Du musst also von der String Instanz mit der c_str Methode deren internen char Pointer abfragen: tf_hal_printf("Get Device Info:\n %s", result.c_str());

Ich habe aus den 6 mm jetzt M6 gemacht.

Ja, steht im Shop in der Beschreibung.

Schreib mal in die .bat Datei hinten dran noch ein %*, also: @"C:\Python39\python.exe" "C:\Python39\Scripts\tinkerforge_mqtt" %* Dann werden die Parameter auch durch gereicht. Das fehlt in der Dokumentation.

Das stallguardThresholdValue Problem ist ein Fehler in der Firmware. Teste mal mit der angehängten Version. Das Data Logger Problem ist unabhängig davon. Speicher mal die Data Logger Config mit der der du das erzeugt hast und häng es hier an. silent-stepper-v2-bricklet-firmware.zbin

Du hast bei mosquitto_sub und mosquitto_pub keinen Host angegeben. Hast du das hier nur der Kürze halber weggelassen, oder hast du da wirklich nur das Topic per -t angegeben. Das kann so nicht funktionieren, wenn du das auf zwei verschiedenen Raspberry Pis ausführst, denn ohne Angabe des Hosts verbinden sich beide Befehle zum jeweils lokalen MQTT Broker. Damit alle Beteiligten die jeweiligen Nachrichten auch sehen können müssen mosquitto_sub, mosquitto_pub und die MQTT Bindings sich zum gleichen MQTT Broker verbinden. Läuft der MQTT Broker auf dem zentralen Raspberry oder dem Pi Zero? Du musst auf dem Raspberry Pi Zero zumindest den Brick Daemon installiert haben, weil dort der HAT Zero Brick angeschlossen ist. Zusätzlich brauchst du noch die MQTT Bindings und einen MQTT Broker. Beides kann auf dem Pi Zero laufen, muss aber nicht. Wenn beides auf dem Pi Zero läuft, dann musst du nichts konfigurieren, weil das die Standardeinstellung ist. Du musst dann allerdings beim mosquitto_sub Befehl auf dem zentralen Raspberry als Host den Pi Zero angeben. Wenn aber die MQTT Bindings nicht auf dem Pi Zero laufen, dann musst du in den MQTT Bindings einstellen wo der Brick Daemon läuft. Dort wo die MQTT Bindings installiert sind (ich nehme an du hast diese per Debian Package als systemd Service installiert) die Datei /etc/tinkerforge_mqtt.cmdline bearbeiten, dort die --ipcon-host Zeile einkommentieren und localhost durch den Hostname oder die IP Adresse des Pi Zeros ersetzen. Danach per "sudo sytemctl restart tinkerforge_mqtt" die MQTT Bindings neustarten. Wenn der MQTT Broker nicht auf dem gleichen Rechner läuft wie die MQTT Bindings, dann musst du in /etc/tinkerforge_mqtt.cmdline auch noch einstellen wo der Broker läuft. Dazu die --broker-host Zeile einkommentieren und localhost durch den Hostname oder die IP Adresse des Rechner ersetzten auf dem der MQTT Broker läuft. Alternativ versuch erstmal einfacher anzufangen. Brick Daemon, MQTT Bindings und MQTT Brocker auf dem Pi Zero laufen lassen. Da musst du nichts umstellen. Dann den mosquitto_sub und mosquitto_pub Befehl auf dem Pi Zero ausführen. Erst wenn das funktioniert das ganze auf zwei Raspberry Pis verteilen.

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.