Jump to content

photron

Administrators
  • Content Count

    2733
  • Joined

  • Last visited

  • Days Won

    12

Everything posted by photron

  1. About the extra 5 seconds of data: From the output file it seems that there are full zero output line every full second when the fusion mode is changed. The extra 5 seconds of data don't have that. Also the recorded data has the expected sample timing of 10 milliseconds. To get this extra 5 seconds would require that the ipcon.disconnect() call is delayed by 5 seconds. But I don't see how that should happen. Could you record the value of the callbackTimer directly before and after the ipcon.disconnect() call to see when it's called and how long it takes in relation to the extra 5 seconds
  2. Das Problem ist mit der aktuellen Brick Daemon Version 2.4.2 behoben und es sollten keine Workaround mehr notwendig sein. Die beste Lösung ist natürlich weiterhin die Firmware des HAT Bricks auf 2.0.2 oder neuer zu aktualisieren. Aber bei der Kombination Kernel 5.4, HAT Brick Firmware < 2.0.2 und Brick Daemon 2.4.2 tritt das Problem nicht mehr auf.
  3. Brick Daemon 2.4.2 Properly shutdown subsystems on Ctrl+C instead of abruptly exiting on Windows Rotate persistent log file on Windows and limit its total size to 25 MB Add commandline options to override log and config file location on Windows Colorize Log Viewer live log messages on Windows Reword Log Viewer messages to be less ambiguous on Windows Add build option to work without a device file manager such as udevd on Linux Allow to handle more then 6 USB devices on Windows Use BCM2835 library for SPI connected Bricklets on Raspberry Pi to imp
  4. Brick Daemon 2.4.2 Subsysteme werden ordentlich anstatt abrupt beendet bei Ctrl+C auf Windows Logdatei wird rotiert und auf 25 MB Gesamtgröße beschränkt auf Windows Kommandozeilenoptionen für Log und Config-Datei hinzugefügt auf Windows Log Viewer Live log Nachrichten werden farblich hervorgehoben auf Windows Log Viewer Nachrichten besser verständlich neuformuliert auf Windows Compile-Option hinzugefügt um ohne Device Manager wie udevd auszukommen auf Linux Unterstützung für mehr als 6 USB Geräte auf Windows Verwendet BCM2835 Bibliothek für SPI v
  5. Es passiert da denke ich folgendes: Dein Programm wird gestartet, aber brickd hat noch nicht alle Bricklet gefunden. Dadurch sendet dein Programm jetzt die rotary_encoder_v2_set_count_callback_configuration Anfrage, diese wird aber in brickd verworfen, weil die UID noch nicht bekannt ist. Deswegen hilft es auch wenn du in deinem Programm am Anfang kurz wartest, weil du dann erst rotary_encoder_v2_set_count_callback_configuration aufrufst, wenn brickd alle Bricklets gefunden hat. Im Fehlerfall sollte rotary_encoder_v2_set_count_callback_configuration aber nicht 0 sondern -1 (Timeout) ausge
  6. Das bedeutet aber nicht, dass alleine dadurch die Antwort verloren gehen kann, sondern nur, dass, falls die Antwort ankommt, sie jetzt per Broadcast an alle geschickt würde, statt gezielt an den Anfragenden.
  7. Du könntest über die API des RED Bricks das tun was Brick Viewer im Wizard intern tut. Wenn du dich aber vor Linux nicht scheust, dann ist es einfacher über einen systemd Service zu gehen, genau wie du das schon getan hast.
  8. Brick Viewer 2.4.16 Reduce Qt requirement to 5.11 to fix crash on macOS Downloads: Windows, Linux, macOS
  9. Brick Viewer 2.4.16 Qt Abhängigkeit auf 5.11 reduziert um Crash auf macOS zu beheben Downloads: Windows, Linux, macOS
  10. Brick Viewer 2.4.15 Support für IMU Bricklet 3.0 und Industrial Dual AC Relay Bricklet hinzugefügt Fehlerbehandlung und Fehlermeldung verbessert Support für Integrated GPU auf macOS hinzugefügt Downloads: Windows, Linux, macOS
  11. Brick Viewer 2.4.15 Add support for IMU Bricklet 3.0 and Industrial Dual AC Relay Bricklet Improve error handling and reporting Support running on integrated GPU on macOS Downloads: Windows, Linux, macOS
  12. Brick Logger 2.1.4 Add support for IMU Bricklet 3.0 and Industrial Dual AC Relay Bricklet Downloads: Windows, Linux, macOS, RED Brick
  13. Brick Logger 2.1.4 Support für IMU Bricklet 3.0 und Industrial Dual AC Relay Bricklet hinzugefügt Downloads: Windows, Linux, macOS, RED Brick
  14. Bindings: C/C++ 2.1.30, C# 2.1.28, Delphi/Lazarus 2.1.29, Go 2.0.9, Java 2.1.29, JavaScript 2.1.31, LabVIEW 2.1.27, Mathematica 2.1.27, MATLAB/Octave 2.0.29, MQTT 2.0.12, Perl 2.1.28, PHP 2.1.27, Python 2.1.27, Ruby 2.1.27, Rust 2.0.16, Saleae 2.0.4, Shell 2.1.28, Visual Basic .NET 2.1.27 Add support for IMU Bricklet 3.0 and Industrial Dual AC Relay Bricklet [All] Fix inline documentation syntax errors [Perl] Log API bindings version on start-up [MQTT] Fix timeout error handling [MQTT] Improve Python 2 compatibility [MQTT] Fix array handling in RS232 2.0 an
  15. Bindings: C/C++ 2.1.30, C# 2.1.28, Delphi/Lazarus 2.1.29, Go 2.0.9, Java 2.1.29, JavaScript 2.1.31, LabVIEW 2.1.27, Mathematica 2.1.27, MATLAB/Octave 2.0.29, MQTT 2.0.12, Perl 2.1.28, PHP 2.1.27, Python 2.1.27, Ruby 2.1.27, Rust 2.0.16, Saleae 2.0.4, Shell 2.1.28, Visual Basic .NET 2.1.27 Support für IMU Bricklet 3.0 und Industrial Dual AC Relay Bricklet hinzugefügt [Alle] Syntaxfehler in der Inline Dokumentation behoben [Perl] API Bindings Version wird beim Start ausgegeben [MQTT] Timeout-Fehlerbehandlung repariert [MQTT] Python 2 Kompatibilität verbessert [MQTT
  16. Entweder du hast nicht ein ganzes Programm gezeigt, oder du rufst einfach deine channel_number() Funktion nicht auf.
  17. Das über eine Datenbank zu vereinheitlichen ist eine gute Idee. Deine Regeln sind aber komplexer formuliert als sie müssten. Da würde ich die Zustände/Stellwerte der Ausgänge mit zu den Eingaben der Regeln nehmen. Das erlaubt dir dann Sensor 0 > 30C° und Sensor 14 < 50°C and Systemmodus = “no Errors” then Schalte Motor1 ein bis Sensor 0 < 10°C so zu formulieren if Sensor0 > 30C° and Sensor14 < 50°C and Systemmodus = “no Errors” and Motor1 aus then schalte Motor1 ein if Sensor0 < 10°C and Motor1 an then schalte Motor1 aus Dadurch kannst du dieses
  18. photron

    LED Strip

    Also, du hast in Brick Viewer den richtigen Chip Type ausgewählt. Ich habe gerade auch eine Rolle frisch aus den Lager getestet, um zu sehen, dass wir da auch das richtige verkaufen. Was wir tun, die Rolle funktioniert einwandfrei. Du hast das Channel Mapping auf BGR stehen, es müsste aber GRB sein, dass kann aber nur falsche Farben erklären, teste trotzdem ob das was ändert. Auf deinem Foto ist nicht zu erkennen, ob du Daten- und Minusleitung richtig angeschlossen hast. Dein Adapterkabel zwischen Bricklet und LED Strip scheint 2 grüne Leitungen zu haben. Du könntest Daten und Minus
  19. Die Anfrage sieht also auf dem Oszilloskop identisch aus, egal ob aus Matlab oder aus Brick Viewer gesendet, sprich der Sensor kann das nicht unterscheiden. Aber es kommt in Brick Viewer und Matlab nur eine Antwort an, wenn Brick Viewer die Anfrage gestellt hat, aber nicht wenn Matlab die Anfrage stellt. Das verwirrt mich weiterhin sehr. Interessant wäre jetzt noch zu sehen, was mit der Antwort laut Oszilloskop ist. Ob der Sensor sie wirklich nicht sendet. Ich nehme an auf dem RS485 Bricklet ist die aktuelle Firmware 2.0.5 drauf. Falls nicht, updated bitte mal über Brick Viewer.
  20. photron

    LED Strip

    Die Datenleitung ist nach dem Reset 4.8V, weil das Bricklet dann noch nichts sendet und die Leitung High hält. Sobald du in Brick Viewer das Bricklet etwas senden lässt, sendet das Bricklet dann dauerhaft Daten auf der Datenleitung und dein Multimeter misst da einen Mittelwert von 1.25V, so weit so gut. Darauf dass die 1.25V sich nicht ändern würde ich nichts geben, dass heißt nicht, dass das Bricklet kaputt ist, sondern nur dass ein Multimeter hier nicht das richtig Werkzeug ist. Da kommst du nur mit einem Oszilloskop oder Logic Analyzer weiter, um zu erkennen ob das Bricklet da das richtige
  21. photron

    LED Strip

    Klinkt alles nach Wackelkontakt bzw schlechtem Kontakt, vor allem wenn du schon sagst DATA sähe mit dem Multimeter komisch aus. Ich würde als nächstes mal die Lötverbindung zwischen Anschlusskabel und Strip überprüfen/nachlöten.
  22. Sehr komisch. Da habe ich keine gute Idee zu. Das initiale Programm sollte einfach funktionieren, abgesehen von den 4 Writes direkt nacheinander. Für mein Verständnis: Aus Brick Viewer heraus funktioniert alles wie erwartet. Wenn die Anfrage gesendet wird kommt eine passenden Antwort darauf. Wenn ihr das aber aus eurem Programm heraus macht kommt keine Antwort. Wenn aber euer Programm läuft und ihr parallel dazu in Brick Viewer die Anfrage sendet, dann kommt eine passenden Antwort in eurem Programm und in Brick Viewer an. Habe ich das so richtig verstanden? Was passiert wenn Bri
  23. Okay, um einmal meine Verwirrung zu klären. Der Sensor den du da verwendest sprichst Modbus ASCII und das was du da schickst sieht auch nach korrektem Modbus ASCII aus, daher auch die 7 Bit. Die Modbus Funktionen des Bricklets sind für Modbus RTU, meinen Ratschlag das zu nutzen kannst du ignorieren, das funktioniert nicht. Es sieht auf den ersten Blick so aus als hättest du dein Vorgehen von Brick Viewer korrekt in dein Programm übertragen. Eine Unterschied könnte noch sein, dass du in Brick Viewer zwischen den 4 Anfragen die du schickst etwas Zeit vergeht, weil du händisch die Anfrage we
×
×
  • Create New...