photron

Brick Viewer 2.4.20 Unnötige Zeilenendeneinstellungen werden im Hex-Modus des RS485 Bricklet Plugins ausgeblendet Thread im Data-Logger-Timer wird wiederverwendet um langsames Speicherleck zu vermeiden Löschen der Data-Logger-Geräteliste beim Laden einer Config repariert Langsames Speicherleck im Data-Logger-Data-Tab repariert Firmware-Versions-Spalte zum Health Monitor hinzugefügt udev-Regel-Kompatibilität unter Linux verbessert Unterstützung für RTC-Treiber-Einstellung zum HAT-Brick-Plugin hinzugefügt Unterstützung für Simple-Mode zum NFC-Bricklet-Plugin hinzugefügt Benötige PySerial Version auf 3.0 erhöht Unterstützung für das Flashen von ESP32 (Ethernet) Bricks hinzugefügt Downloads: Windows, Linux, macOS

Du setzt mit dem Monoflop das Value auf true, oder? Wenn das hängenbleibt dann, musst du es schaffen den Master Brick so abzuschießen, das der Pin der das Relais schaltet im true Zustand hängen bleibt und dadurch das Relais geschaltet bleibt. Das passt aber nicht dazu, dass du sagst der Stapel startet neu. Denn dann sollte das Relais wieder in den Standardzustand false zurückgehen. Da kann ich dir jetzt leider auch nicht viel mehr zu raten als die Störung durch die 230V Seite zu beseitigen, sorry.

Tritt das Problem auch auf, wenn du den EPN510 vom Dual Relay Bricklet trennst? Oder muss der EPN510 wirklich geschaltet werden, damit das Problem auftritt? Was schaltet der EPN510 auf seiner Lastseite? Wie sieht deine Kabelführung aus? Hast du 230V Leitungen parallel zu Bricklet Kabeln liegen, so dass Störungen auf den 230V Leitungen sich auf die Bricklet Kabel übertragen können. Das könnte ein EMV Problem sein, dass also das schalten der Last eine Störung erzeugt die verlässlich den Stapel abschießt. Alternativ verursacht das Schalten der Last einen Spannungseinbruch der soweit durchschlägt, dass die Versorgung des Stapel kurzzeitig wegbricht, auch wenn du da ein 24V Netzteil dazwischen hast.

Klingt alles so als sollte das funktionieren können.

Ich nehme mal an du verwendet das Gefälle im Seil zum Herabrollen lassen des Wagens durch Schwerkraft. Sprich in dem Fall muss der Motor den Wagen bremsen durch langsames abwickeln der Schnur. Beim Heraufrollen zieht der Motor dann den Wagen über das Gefälle hinweg hoch. Da das Gefälle ja sehr gering ist trägt das Seil den Großteil des Gewichts des Wagens und der Zug auf der Schnur sollte gering sein. Da ist es fast egal was du an Motor nimmst, würde ich schätzen, so lange dieser nicht grundsätzlich zu schwach ist und mit ausreichend Kraft langsam genug laufen kann. DC Getriebemotor ist sicher keine falsche Wahl. Interessant sind da vielleicht auch andere Fragen. Muss der Motor immer unter Strom stehen, um den Wagen in der seiner Position zu halten? Oder hast du bei einem DC Getriebemotor genug Reibung im Getriebe, so das das Gewicht des Wagens die Schnur nicht abwickeln kann auch wenn der Motor stromlos ist? Oder ist das ein Schneckengetriebe? Wie ist es mit der Geräuschentwicklung? Ist das Surren eines DC Getriebemotor ein Problem? Aus welchem Material ist der Geist? Kann sich das mit Wasser vollsaugen im Regen? Wie schwer ist das ganze dann?

Das sollte nicht passieren. Mit den Zahlen/Versionen kann ich nichts anfangen. Die aktuelle WARP1 Firmware ist Version 1.2.4.

Also ist das eine Wechselwirkung zwischen Cumulocity Agent und Brick Daemon? Wenn du also den Cumulocity Agent deinstallierst anstelle von Brick Daemon dann läuft es auch it HAT Brick? Nein, dazu kannst du aber irgendeine Modbus TCP Bibliothek verwenden z.B. PyModbus. Für Modbus TCP brauchst du keine extra Hardware, da das einfach über die normale Netzwerkschnittstelle geht.

Das ist die Frage hier! Wenn du in der Config nicht die spidev Zeile drin hast, dann verwendet Brick Daemon den BCM2835 Treiber um mit dem HAT Brick und den Bricklets zu kommunizieren. Wenn du die spidev Zeile drin hast, dann verwendet Brick Daemon stattdessen den spidev Treiber. Warum das jetzt einen Unterschied macht ist mir gerade unklar. Eigentlich ist der BCM2835 Treiber besser, da mit diesem der Durchsatz höher ist. Das ist alles mit Kernel 5.10.60, oder? Interessant wäre zu sehen ob das mit 5.10.17 besser wird. Es kann sein, dass eine Kernel Änderungen das Problem auslöst, muss aber nicht. Bleiben die Fehlerzähler gleich, oder steigen die kontinuierlich? Im Health Monitor kannst du die Werte auch in einer Datei speichern. Mach das bitte mal und häng die Datei hier an. Wir pflegen den Tinkerforge Support in Cumulocity nicht, sondern das macht Cumulocity selbst. Cumulocity scheint einfach alle deine Bricks und Bricklets nicht zu unterstützen: Device Identifier 111 ist der HAT Brick Device Identifier 290 ist das Sound Pressure Level Bricklet Device Identifier 292 ist das Motion Detector Bricklet 2.0 Device Identifier 297 ist das Air Quality Bricklet Das hat also nichts mit dem HAT Brick Problem zu tun, sondern einfach damit, dass der Cumulocity Support für Tinkerforge unvollständig ist. Das ist hier auch nachzulesen: https://cumulocity.com/tinkerforge/ (in der Fussnote) https://cumulocity.com/guides/device-tutorials/tinkerforge/

Kann beides sein. Daher die Fragen ob du mit frischer SD Karte oder anderem Raspberry Pi testen kannst. Es kann auch sein, dass der HAT Brick selbst einen Schaden hat. Hast du die /etc/brickd.conf Änderung auf spidev gemacht? Laut Log wird immer noch der BCM2835 Treiber verwendet.

Laut Log treten da massive Kommunikationsprobleme zwischen Raspberry Pi und HAT Brick auf. Wie kommst du auf Kernel 5.10.60? Wenn ich ein frisches Raspberry Pi OS Image mit dem Image Tool auf eine SD Karte dann bekomme ich Kernel 5.10.17. Hast du den Kernel mit rpi-update aktualisiert? Bei mir tritt das Problem nicht auf. Weder mit Kernel 5.10.17 noch mit 5.10.60. Hast du eine weitere SD Karte zur Hand auf der du ein frisches Raspberry Pi OS aufsetzen kannst? Oder hast du ein anderes Raspberry Pi zur Hand mit dem du testen kannst?

rtrbt ist gerade im Urlaub. Ich habe aber mal den Generator durchlaufen lassen, kann aber nicht garantieren ob das auch zu deiner Version passt. Probier die beiden Dateien mal aus. bricklet_industrial_dual_ac_relay.c bricklet_industrial_dual_ac_relay.h

Hast du am HAT Brick noch Bricklets angeschlossen, oder ist das HAT Brick alleine? Falls Bricklets angeschlossen sind, macht es dann einen Unterschied, wenn du diese absteckst? Welche Kernel Version läuft auf dem Raspberry Pi? Das kannst du mit folgenden Kommando abfragen: uname -a Brick Daemon kann auf zwei verschiedene Arten mit dem HAT Brick kommunizieren. Standardmäßig wird auf dem Raspberry Pi der BCM2835 Backend verwendet. Das kannst du an dieser Zeile sehen: 2021-09-20 13:40:58.661002 <I> <bricklet_stack_linux.c:129> Using BCM2835 backend for Bricklets (Raspberry Pi detected) Du kannst brickd aber zwingen den spidev Backend zu verwenden. Dazu musst du die Datei /etc/brickd.conf bearbeiten und folgende Zeile anhängen: bricklet.spi.driver = spidev Um die Änderung zu übernehmen musst du dann brickd neustarten, oder das ganze Raspberry Pi neustarten. Das Kommando für den brickd Neustart ist: sudo systemctl restart brickd Wenn die Änderung geklappt hat sollte folgende Zeile im Log stehen: Using spidev backend for Bricklets (forced by config) Macht es dann einen Unterschied, wenn du auf das spidev Backend wechselst?

Korrekt!

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.