Jump to content

photron

Administrators
 Profil anzeigen  Aktivitäten des Benutzers anzeigen

  • Gesamte Inhalte

    3.049

  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    39

 Inhaltstyp 

Posts erstellt von photron

    Announcements

    in General Discussion

    Geschrieben

    Bindings: C/C++ 2.1.34, C/C++ for Microcontrollers 2.0.4, C# 2.1.32, Delphi/Lazarus 2.1.33, Go 2.0.15, Java 2.1.33, JavaScript 2.1.35, LabVIEW 2.1.31, Mathematica 2.1.31, MATLAB/Octave 2.0.33, MQTT 2.0.17, Perl 2.1.32, PHP 2.1.31, Python 2.1.31, Ruby 2.1.31, Rust 2.0.21, Saleae 2.0.8, Shell 2.1.33, Visual Basic .NET 2.1.31

    • Add support for Industrial Dual AC In Bricklet [All]
    • Add FFC shutter mode and normalization to Thermal Imaging Bricklet API [All]
    • Fix System.AppDomain.Unload timeout, avoid crash [LabVIEW]
    • Fix System.AppDomain.Unload timeout [C#, Mathematica, VB.NET]
    • Fix error response check [Go]
    • Fix single chunk streams [Go]
    • Handle empty payload in streamed function calls [MQTT]
    • Remove wrong stream error handling [JavaScript]
    • Add IPv6 support, raises PHP requirement to 7.2.0 [P,HP]
    • Don't leak socket on connect error [Python]
    • Add IPv6 support [Python]
    • Show dropped bytes [Saleae]
    • Fix get-identity call [Shell]
    • Fix --execute with modern Python versions [Shell]
    • Support authentication secret, listen address and port for Arduino ESP32 [µC]
    • Don't count callbacks as unexpected packets [µC]
    • Fix byte offset when splitting packet to be sent [µC]
    • Correctly mark packet as processed if received in setter [µC]
    • Correctly stop waiting for packet when timeout is elapsed [µC]
    • Use correct sequence number when resending proxy packets [µC]
    • Validate header length of received packets [µC]
    • Report local function calls as unsupported instead of timing out [µC]
    • Fix IP address handling with current Arduino ESP32 [µC]

    Download: C/C++, C/C++ for Microcontrollers, C#, Delphi/Lazarus, Go, Java, JavaScript, LabVIEW, Mathematica, MATLAB/Octave, MQTT, Perl, PHP, Python, Ruby, Rust, Saleae, Shell,

    Veröffentlichungen

    in Allgemeine Diskussionen

    Geschrieben

    Bindings: C/C++ 2.1.34, C/C++ for Microcontrollers 2.0.4, C# 2.1.32, Delphi/Lazarus 2.1.33, Go 2.0.15, Java 2.1.33, JavaScript 2.1.35, LabVIEW 2.1.31, Mathematica 2.1.31, MATLAB/Octave 2.0.33, MQTT 2.0.17, Perl 2.1.32, PHP 2.1.31, Python 2.1.31, Ruby 2.1.31, Rust 2.0.21, Saleae 2.0.8, Shell 2.1.33, Visual Basic .NET 2.1.31

    • Support für Industrial Dual AC In Bricklet hinzugefügt [Alle]
    • FFC Shutter Mode und Normalization zur Thermal Imaging Bricklet API hinzugefügt [Alle]
    • System.AppDomain.Unload Timeout behoben und dadurch LabVIEW-Abstruz vermieden [LabVIEW]
    • System.AppDomain.Unload Timeout behoben [C#, Mathematica, VB.NET]
    • Überprüfung der Antwort im Fehlerfall korrigiert [Go]
    • Single-Chunk-Streams repariert [Go]
    • Leerer Payload in gestreamtem Funktionsaufruf wird korrekt behandelt [MQTT]
    • Falsche Stream-Fehlerbehandlung entfernt [JavaScript]
    • IPv6-Support hinzugefügt, benötigt PHP 7.2.0 [P,HP]
    • Socket-Resource-Leck durch Verbindungsfehler korrigiert [Python]
    • IPv6-Support hinzugefügt [Python]
    • Ignorierte Bytes werden angezeigt [Saleae]
    • get-identity Aufruf repariert [Shell]
    • --execute mit modernen Python-Versionen korrigiert [Shell]
    • Support für Authentication-Secret, Listen-Adresse und -Port für Arduino ESP32 hinzugefügt [µC]
    • Callbacks werden nicht mehr fälschlicherweise als unerwartete Pakete gezählt [µC]
    • Byte-Offset beim Aufteilen zu sendender Pakete korrigiert [µC]
    • Packet wird korrekt als verarbeitet markiert, falls es in einem Setter empfangen wurde [µC]
    • Warten auf Pakete beim Ablauf des Timeouts wird korrekt abgebrochen [µC]
    • Verwendung der korrekten Sequenznummer beim Weiterleiten von Proxy-Paketen [µC]
    • Header-Länge empfangener Pakete wird überprüft [µC]
    • Lokale Funktionsaufrufe werden direkt als nicht-unterstüzt abgebrochen anstatt in einen Timeout zu laufen [µC]
    • IP-Adress-Behandlung bei Verwendung der aktuellen Arduino ESP32 Bibliothek korrigiert [µC]

    Download: C/C++, C/C++ for Microcontrollers, C#, Delphi/Lazarus, Go, Java, JavaScript, LabVIEW, Mathematica, MATLAB/Octave, MQTT, Perl, PHP, Python, Ruby, Rust, Saleae, Shell, Visual Basic .NET

    Problem with multiple Master bricks

    in General Discussion

    Geschrieben

    @fridolin11 Your problem seem to have a different cause.

    On 2/26/2024 at 5:15 PM, fridolin11 said:

    Is the fix mentioned by photron already implemented in the version of brickviewer which I am using (2.4.25)?

    There was no fix in Brick Viewer, but a change in Brick Daemon to handle the message burst created by the enumeration of the whole system.

    There is no need to test any old version that might have been mentioned in this thread. Please only test the latest versions of Brick Daemon and Brick Viewer. I assume that is what you already have installed.

    From the brickd.log I can see that you get a lot stalled USB read transfers making the communication with the Bricks and Bricklets unreliable.

    On 2/26/2024 at 5:27 PM, fridolin11 said: 
    2024-02-26 16:24:46.094358 <W> <usb_transfer.c:428> Read transfer 0x19678f8 (handle: 0x1967570, submission: 0) for Master Brick [6tdoWM] aborted by stall condition

    As long as you continue to see this kind of message in brickd.log the problem persists. You can open brickd.log in a console/terminal like this to get a live view: 

    tail -f /var/log/brickd.log

    Then try plugging and unplugging the Bricks from USB and see what messages you get.

    Do the stall messages only appear when you connect two Bricks to USB? Is one Brick alone okay?

    In the Raspberry Pi 2 era many problems where caused by insufficiant power supplies. How do you power the Raspberry Pi 4? Could you try a "stronger" power supply?

    Du you directly connect the Bricks to the Raspberry Pi, or is there another USB hub in between? Does it make a difference if you remove any USB hub? You can also try to add a powered USB hub.

    Auto startet Ladevorgang nicht mehr mit aktuellster EM/Charger Firmware und EVCC (Hyundai IONIQ)

    in WARP Charger

    Geschrieben

    Der Neustart wird durch einen Crash im SunSpec Scan ausgelöst. Dabei geht es um den Scan beim Start des WEM, nicht um den Scan, der über das Webinterface ausgeführt werden kann.

    @andyknownasabu Aus deinen Logs kann ich sehen, dass dein Wechselrichter schlecht erreichbar ist. In unserem Scan Code war ein Bug, der zu einem Crash führte, wenn das SunSpec Gerät beim Scan mitten drin für eine gewisse Zeit nicht mehr geantwortet hat. Du muss genau diese Stelle zeitlich getroffen haben. Den Fix dafür habe ich gerade committet und der wird in der nächsten Firmware-Version drin sein, die vermultich noch heute veröffentlicht wird.

    https://github.com/Tinkerforge/esp32-firmware/commit/fa5d6e1da5a920653c5fa2fffd3f9a3855a74044

    Der Fehler war schon immer im Code, sorry. Warum der Crash bei dir erst jetzt auftritt ist mir unklar. Teste bitte die nächste Fimrware-Version. Ich gehe sehr stark davon aus, dass das Problem damit behoben ist.

    SunSpec - kompatible Smart Meter

    in WARP Charger

    Geschrieben

    On 1/29/2024 at 10:08 PM, eweri said:

    So hier kommen jetzt meine ersten Ergebnisse - der Scan bleibt irgend wann hängen und dann kann man auch wenn man das Fenster schließt nicht noch einmal Scannen. Man muss die WARP neustarten damit man einen weiteren Versuch starten kann.

    Teste mal bitte die angehängte Firmware. Diese behebt in unseren Tests beide Probleme. Die Ursache lag in der Art und Weise, wie dein Smart Meter reagiert, wenn eine Modbus Deviceaddrese angefragt wird, die das Smart Meter nicht kennt. Damit ging die Firmware nicht richtig um und dann blieb der Scan hängen und konnte auch nicht mehr abgebrochen werden.

    warp_firmware_2_2_1_65c63107_merged.bin

    Zwei Stromzähler möglich

    in WARP Charger

    Geschrieben

    @Smoki Kurze Einführung in SunSpec.

    Die Daten werden als eine Kette von Blöcken dargestellt. Die Kette beginnt mit zwei Registern die die 32bit SunSpec ID 0x53756E53 enthalten. Daran erkennen wir, dass SunSpec unterstüzt wird. Wir laufen alle Modbus-Geräteadressen (1 - 247) durch und versuchen die SunSpec ID zu finden. Wenn die ID vorhanden ist, dann lesen wird die Kette der Blöck aus. Jeder Block beginnt mit der Model ID (ein Register) und der Blocklänge (ein Register). Dadurch können wir uns an der Kette der Blöcke dranlang hangeln ohne alle Blöck verstehen zu müssen. Sondern wir können die Model ID und die Blocklänge lesen, sehen ob das ein Model ist das uns interesiert und dann um die Blocklänge weitergehen, um dann das nächste Model zu lesen. Die Kette der Blöcke endet mit einem Model mit ID 0 und Blocklänge 0.

    Unser Scan geht alle Blöcke durch und zeigt dir dann die an die zählerartige Daten beinhalten. In deinem Fall Model 103 und 122. Dabei lesen wir die Daten des 122 Models gerade noch nicht aus, dass ist das was das "Nicht unterstützt" besagt.

    Das Problem in das du jetzt läufst betrifft Model ID 160. Das ist ein Model, das wiederholte Unterblöcke beinhaltent. Dessen Blocklänge hängt also von der Konfiguration deines Wechselrichters ab. Wir lesen jetzt hier im Scanvorgang 160 als Model ID und 48 als Blocklänge aus, was 8+2x20 entspricht, wie MatzeTF das oben erläutert. Danach überspringen wir dann die 48 Register, um die nächste Model ID zu lesen und bekommen einen ILLEGAL_ADDRESS Modbusfehler von deinem Wechselrichter. MatzeTF hatte sich das bei dir genauer angesehen und festgestellt, dass wir da wegen der falschen Blocklänge mitten in den Block des 160er Models lesen, was nicht erlaubt ist. Von den Daten her sieht es so aus, als wenn dein Wechelrichter 6 Module angeschlossen hat und daher einen 160er Block mit 6 wiederholten Unterblöcken melden sollte. Er liefert auch 6 wiederholte Unterblöcke, aber die Blocklänge passt nicht dazu. Gemeldet wird eine Blocklänge von 48 (8+2x20), richtig wäre aber wohl eine Blocklänge von 128 (8+6*20). Wenn MatzeTF händsich das 160er Model mit einer Blocklänge von 128 ausliest, dann funktioniert es und nach dem 160er Model folgt das 0er End Model in der Blockkette.

    Sprich dein Wechselrichter meldet nach unserem Verständnis nach das 160er Model mit falscher Blocklänge. Im 160er Model steht unter dem N Wert die Anzahl der wiederholten Unterblöcke. Aber auch hier steht in deinem Fall 2, was zur Blocklänge 48 passt, aber nicht zu den wiederholten Unterblöcken die dann wirklich vorhanden sind. Die Daten des 160er Models sind hier inkonsistent in einer Weise, die wir nicht retten können. Das sieht für uns nach einem Fehler im Wechslrichter aus denn nur SMA selbst beheben kann.

    Das 64870er Model ist ein Vender Specific Model von SMA. Wir melden dann verwirrenderweise "Unknown" für. Ich ändere das auf "Vender Specific" für die nächste Version.

    • Like 1

    Originale Firmware mit Bricklet 'Nachbau' / Bootloader / Firmware / CPU Tausch

    in Software, Programmierung und externe Tools

    Geschrieben

    Deine Erkenntnisse sind soweit korrekt. Es werden abhängig vom Bricklet verscheidene Mikrocontroller aus der XMC 1100/1300/1400er Serie verwendet. Diese Details sind aber nicht relevant in deinem Fall.

    On 11/24/2023 at 11:51 AM, OutdoorRob said:

    Mein Nachbau besitzt einen 'leeren' XMC1100. Wie wird der initiale Bootloader auf den µC programmiert?

    Ein Master Brick ab Hardware Version 3.0 kann unseren Bootloader auf einen leeren XMC flashen. Das kann allerdings dann nicht Brick Viewer, sondern du braucht das write_bootloader_and_firmware_to_comcu_bricklet.sh Script von hier https://github.com/Tinkerforge/flash-test

    Du brauchst dazu einen PC mit Linux und brickd (z.B. Ubuntu). Du schließt dein Bricklet an Port D einens Master Bricks 3.x an, schließt diesen Master Brick an den PC an und führst das write_bootloader_and_firmware_to_comcu_bricklet.sh Script aus. Dem gibts du als einziges Parameter den Pfad zur *.zbin Datei der Firmware für dein Bricklet mit. Diese kannst du unter https://www.tinkerforge.com/de/doc/Downloads.html herunterladen. 

    ./write_bootloader_and_firmware_to_comcu_bricklet.sh bricklet_io16_v2_firmware_2_0_2.zbin

    Ich habe das jetzt recht knapp beschrieben. Falls das zu knapp war kann ich das auch in mehr Details beschreiben. Aber wenn du dich mit Linux auskennst, sollte das eigentlich reichen. Ansonsten frag bitte einfach.

     

     

    • Thanks 1

    Order of CAN-Frames are mixed up

    in Software, Programmierung und externe Tools

    Geschrieben

    This is not a common problem. It's the first time I hear about it. But I might have a hunch, about what might cause this.

    When the problem occurs, do you see a change in the CAN error counters of the Bricklet (function get_error_log)?

    By default the Bricklet uses 8 hardware write buffers. Does it make a difference if you reduce the number of write buffers to 1 (function set_queue_configuration, parameter write_buffer_size = 1)?

    Does your script reset the Bricklet on start?

    WARP Energy Manager Beta-Firmware mit SunSpec-Unterstützung

    in WARP Charger

    Geschrieben

    git pull und teste bitte nochmal. Der Fehler dort ist ein anderer. An der Stelle wird Modell 160 gelesen, das 128 Register lang ist. Modbus erlaubt es aber nur 125 Register an einem Stück zu lesen. Das habe ich jetzt repariert. Mit -s wird der Block von Modell 160 nicht geladen, sondern übersprungen, daher tritt dieser Problem mit -s nicht auf.

    Das hat aber leider alles nichts mit dem originalen Problem zu tun. Das Script kann die Daten lesen, der Energy Manager nicht. Ich such mal weiter nach dem Unterschied.

    WARP Energy Manager Beta-Firmware mit SunSpec-Unterstützung

    in WARP Charger

    Geschrieben

    @poohnet Wir kommen näher. Das discover.py Script liest alle Werte einzeln. Der Energy Manager liest die Werte blockweise. Ich habe das discover.py Script jetzt umgestellt auf blockweises Lesen. Aktualisier mal bitte deinen git Clone und lass das Script nochmal laufen. Ich vermute, dass SMA es nicht erlaubt die Daten blockweise zu lesen. Das discover.py Script hat jetzt eine -s/--single-value-read Option, um das vorherige Verhalten wieder zu bekommen. Ich erwarte, dass das aktuelle discover.py Script ohne -s bei dir nicht funktiioniert, aber mit -s funktioniert. Kannst du das bestätigen?

    WARP Energy Manager Beta-Firmware mit SunSpec-Unterstützung

    in WARP Charger

    Geschrieben

    @poohnet Komisch! Kannst du bitte diese Script ausführen:

    https://github.com/Tinkerforge/esp32-firmware/blob/feature-meters-7/software/src/modules/meters_sun_spec/discover.py

    Du brauchst dazu pymodbus >= 3.5.x, am einfachsten über pip installieren. 

    python3 discover.py -H <sunny-boy-addresse> -d 126

    Das Script liest jeden Wert einzeln, anstatt den ganzen Common Model Block in einem Rutsch zu lesen.

    WARP Energy Manager Beta-Firmware mit SunSpec-Unterstützung

    in WARP Charger

    Geschrieben

    @poohnet Dann teste mal bitte den aktuelle Stand des features-meters-7 Branch (Commit: meters-sun-spec: Avoid reading common model block padding). Vielleichthilft das. Der Common Model Block kann laut Spec 65 oder 66 Register lang sein. Alles was wir hier zum Testen haben hat de 65er Variante. SMA hat aber die 66 Variante. Der Code geht damit richtig um, denke ich, aber vielleicht mag SMA nicht, dass ich das eine Padding Register mit lese. Das habe ich gerade geändert.

×
×
  • Neu erstellen...