TA: Diskussionen zu Firmware-Updates

Es gibt 78 Antworten in diesem Thema, welches 16.592 mal aufgerufen wurde. Der letzte Beitrag () ist von IKT-Solar.

  • Hallo,


    Erst einmal vielen Dank für die Auskunft.

    Ich meinte ein Elektro CAD.

    WSCAD ist mir vom Namen her schon bekannt.

    Selbst habe ich mit verschiedenen CAD Systemen gearbeitet,

    Mit ELTIME habe ich 1987 angefangen, dann mal 1 Jahr mit ELCADSY,

    dann wieder neuere Version von ELTIME, dann war AUCOTEC mit ELCAD dran,

    zuletzt mit EPLAN bis Version 5.4 oder 5.7 danach P8.

    Diese Systeme sind aber für einen Rentner zu teuer, deshalb meine Frage.

    Ich suche ein bezahlbares CAD mit dem man nach der aktuellen Norm

    gemäß Anlage und Ort Bezeichnung zeichnen kann.


    mfg

    HJH

  • Hallo


    Es gibt ein neues Firmware Update für den CMI (06.12.)


    Und siehe da ... Es gibt etwas zum Modbus ....


  • Ja, Alfred.


    Ob es des Rätsels Lösung ist, weiß ich ja noch nicht einmal ...

    Das Firmwareupdate steht zum Download auf der Internetseite.

    TA schweigt immer noch zu meiner Problematik, weil es ja aktuell auch nicht relevant ist.

    Läuft mit der älteren Firmware V 1.26 !!!


    Bei meinem Bruder habe ich das Update von hier aus der Kälte (heute Morgen -36 C) eingespielt.

    Bei mir machen ich das erst, wenn ich daheim bin ....


    mfg Cord

  • ...kannst du getrost " einspielen " ...ich habe es seit der Nacht bereits auf 11 System gemacht. Alle laufen bis jetzt problemlos ;)

    schöner wäre es, wenn TA Tapps und Designer bringen würden, denn in Tapps klappt zb im Simulator nicht die neuen Funktionen für zb CORA HKT und da ich welche habe, ist es etwas mühsam und wäre schönen erst zu simulieren und dann auf die CAN-MTx2 zubringen....na ja, bis Weihnachten ist ja noch etwas Zeit ;)

  • Hallo IKT-Solar


    Das Update in den CMI einspielen geht schon , aber die Firmware der UVR 610 Modbus werde ich von V1.26 erst auf V1.31 updaten,

    wenn ich Zuhause bin, denn bislang ist mir die UVR dann im 5 Sekundentakt neu gestartet.


    mfg Cord

  • Hallo


    Bin Zuhause angekommen und habe mich meinem Firmware Problem gewidmet.



    CMI hat neuste Firmware bekommen


    Dann habe ich meinem Knoten 39 von Firmwarestand V 1.26 auf V 1.31 abgeändert .... Alle 5 Sek startete der Knoten 39 neu ... war ja vorher auch schon so


    Dann kompletter Reset und Firmware zurück auf Stand V 1.26

    Programm wieder auf die UVR übertragen .... Modbus Slaveadresse von 1 auf 2 geändert

    Firmwareupdate eingespielt .... keine Neustarts mehr

    In NodeRed die Slaveadresse abgeändert ... Daten kommen an und es gibt bislang keine Neustarts mehr.


    Fazit:

    funktioniert nicht :


    Knoten 38 Master Adresse 1

    Knoten 39 Slave Adresse 1



    funktioniert :


    Knoten 38 Master Adresse 1

    Knoten 39 Slave Adresse 2



    mfg Cord

  • Hallo Cord,


    super, wenn den Fehler gefunden hast und wieder alles funktioniert so wie es soll.

    Vielen Dank für die Rückmeldung. Denn damit hapert es noch hier im Forum.


    Du warst sicher der Meinung, wenn du mit jedem der zwei UVR610 einen getrennten Modbus betreibst,

    dann wird das wohl nicht stören, da die Modbusdaten sich auf den ersten Blick nicht in die Quere kommen.


    Weisst ja nachher ist man immer schlauer.

    Aber wenn man genauer drüber nachdenkt, dann weiss man, dass die beiden UVR610 zwar über die beiden Modbusse nicht miteinander verbunden sind,

    aber sehr wohl im Hintergrund über den gemeinsamen Can-Bus (TA-Backbone).


    Du machst das zwar nicht, aber wenn du z.B. Daten vom Modbus-Eingang1 von der UVR610-1(Geräteadresse1) zum Modbus-Ausgang1 von der UVR610-2(Geräteadresse1)

    über den Can-Bus im Hintergrund übertragen möchtest, dann gibts schon ein Geräte-Adressen Konflikt,

    weil beide einen Modbus-Eingang1/Ausgang1 mit der gleichen Geräte-Adresse 1 besitzen würden.

    Vielleicht wäre mit so einem Beispiel der Geräte-Adressen Konflikt schon früher aufgefallen?


    Mit TAPPS kann man das nicht so einfach rausfinden, denn du programmierst ja damit immer nur eines von vielen UVR610-Geräten.

    TAPPS weiss ja nicht, dass du nochmal ein UVR610 mit der gleichen Geräteadresse1 im Modbus betreibst.


    Inzwischen werden die TA-Systeme durch das Verknüpfen von Heizung mit PV zu Energiemanagementsystemen immer grösser mit immer mehr Geräten.

    Aber von TA sollte so ein mögliches Problem erkannt worden sein. Die testen ja alles auf Herz und Nieren.

    Du hast ja ausführlich dein Problem dort geschildert.


    Beim MODBUS-SLAVE im UVR610 "Man kann neuerdings auch einen "gemeinsamen Adressbereich" einstellen ..."

    Das hat nichts mit der Geräteadresse zu tun, sondern mit den Speicheradressen der verschiedenen 16-Bit Modbus-Registeradressen.

    Gemeinsam nutzen heisst auch überschreiben von einzelnen 16-Bit Modbus-Registeradressen ermöglichen, damit kann man auch Programmieraufwand sparen/optimieren.


    Ein Frage noch zu deinem Energiemanagementsystem:

    Bei der Datenübertragung vom Hybridwechselrichter Effekta werden auch Batteriedaten von den Pylons über Homeassiatent oder Node-Red eingelesen.

    Wie sind die Batterien mit dem Hybridwechselrichter verbunden? Über Pylon-Can-Bus?

    Werden die Batterie/Hybridwechselrichter-Daten über Homeassiatent mit Interface-Modul oder direkt mit Node-Red-flow eingelesen?

    Welche Batteriedaten werden von den Pylons eingelesen?


    Kannst ja auch einen eigenen Thread mit deinem Energiemanagementsystem aufmachen, dann weichen wir hier nicht allzusehr vom Firmware-Thema ab.


    Gruß

    Jürgen

    Atmos D15P mit A25; LambdaCheck; UVR1611 mit CAN-I/O44, BL-NET und CMI ;
    2x1000l Puffer mit 2x10m² VRK und glykolfreie Solarthermie(Ost-West); WW-FWS; zentrale Wasserenthärtung;

    PV 3,2 kWp EEG; PV-Insel 6 kWp mit Victron MultiPlus-II 48/5000/70-50 und 8 x PylonTech LiFePo4 Modul 48V 2,4 kWh US2000 mit BMS; Victron Cerbo-GX;

    Herkules SE 5000 DF DIESEL Elektrostart Stromerzeuger Generator 2x220V-1x380V, Dauerleistung 4.200 Watt, 11 Stunden Dauerbetrieb, Tankinhalt 13,3 l

  • Hallo Jürgen


    Ja bin heilfroh dass es nun funktioniert.

    Ich habe TA auch informiert, dass dieses Thema geschlossen werden kann.

    Diesmal haben Sie sich bei der Fehlersuche nicht so ins Zeug gelegt.


    Aber gut ... hatte ja auch geschrieben, dass es nicht eilig ist.


    Das mit dem gemeinsamen Adressbereich hatte ich auch auf die Adressregister bezogen,

    aber ich habe auch keinerlei Doku gefunden.


    Zum Thema immer größere vernetzte Anlagen:

    Ich warte dass der CMI Nachfolger endlich auf den Markt kommt.

    Der soll wesentlich mehr können ... Evtl. kann ich dann auf Nodered und 1 Raspberry verzichten.



    Ich mache heute Abend mal ein Energiethema auf ...



    mfg Cord

  • Frohe Weihnachten


    Die Freude war nur kurz ...

    Stabil läuft es nun schon wieder nicht mehr ... liegt aber vermutlich an Node Red


    Ich mache dazu einen neun Thread auf

  • Ich habe einen neuen Beitrag aufgemacht:


    Aber das Problem waren Modbus Adressen > 62 !!!!


    Firmware V1.27 lief mit Adresse 64 !!!

    Firmware V 1.30 + V1.31 liefen nicht mit Adresse 64 !!!!!




    TA hat sich soeben wie folgt gemeldet :


  • Hallo


    Der Entwickler von TA hat mir soeben eine Beta Version der Firmware UVR 610 Modbus zugesendet,

    die Modbusadressen >= 64 zulassen soll.

    Ich möchte es gerne testen, aber ich bin wieder weit weg von Daheim

    und meine Frau unterwegs ...

    Aber ab Morgen soll es ja wärmer werden bei uns Zuhause ...



    aber für Interessierte bzw. Betroffene stelle ich es hier gerne zur Verfügung :


    mfg Cord

  • Zusatzinfo zu der Betaversion :



    Habe mich aufrichtig für den tollen Service bedankt


    mfg Cord

  • Hallo Cord,


    habe die V132BetaA auf UVR610 draufgespielt und mit Modbus-RTU getestet.


    Den Testfall mit dem Modbus-Eingang-11, dem ich z.B die Adresse 71 (grösser 64) zugeordnet habe,

    konnte ich mit einem python-script erfolgreich beliebig oft durchführen.


    Mit Node-Red lief die Übertragung zur Adresse 71 (grösser 64), zum Modbus-Eingang-11 ebenfalls erfolgreich.


    ...

    DEBUG:pymodbus.transaction:SEND: 0x1 0x6 0x0 0x47 0x25 0x81 0xe3 0x2f

    DEBUG:pymodbus.framer.rtu_framer:Changing state to IDLE - Last Frame End - 1704986351.923675, Current Time stamp - 1704986351.926693

    DEBUG:pymodbus.framer.rtu_framer:Waiting for 3.5 char before next send - 4.01 ms

    DEBUG:pymodbus.client.sync:New Transaction state 'SENDING'

    DEBUG:pymodbus.transaction:Changing transaction state from 'SENDING' to 'WAITING FOR REPLY'

    DEBUG:pymodbus.transaction:Changing transaction state from 'WAITING FOR REPLY' to 'PROCESSING REPLY'

    DEBUG:pymodbus.transaction:RECV: 0x1 0x6 0x80 0x54 0x52 0x6c 0xef 0xfe

    DEBUG:pymodbus.transaction:Changing transaction state from 'PROCESSING REPLY' to 'TRANSACTION_COMPLETE'

    ...


    Gruß

    Jürgen

    Atmos D15P mit A25; LambdaCheck; UVR1611 mit CAN-I/O44, BL-NET und CMI ;
    2x1000l Puffer mit 2x10m² VRK und glykolfreie Solarthermie(Ost-West); WW-FWS; zentrale Wasserenthärtung;

    PV 3,2 kWp EEG; PV-Insel 6 kWp mit Victron MultiPlus-II 48/5000/70-50 und 8 x PylonTech LiFePo4 Modul 48V 2,4 kWh US2000 mit BMS; Victron Cerbo-GX;

    Herkules SE 5000 DF DIESEL Elektrostart Stromerzeuger Generator 2x220V-1x380V, Dauerleistung 4.200 Watt, 11 Stunden Dauerbetrieb, Tankinhalt 13,3 l

  • Moin Jürgen

    Ich habe gestern die Firmware erfolgreich und ohne Probleme übertragen ...


    mfg Cord

  • Hallo


    noch ein Nachtrag :


    Modbusadresse "0" funktioniert leider auch nicht.


    Ich habe den Entwickler von TA nochmal angeschrieben


    mfg Cord

  • Hallo


    das war ein Eigentor ...


    Zuerst habe ich mal in Node Red geschaut, ob ich zufällig die Adresse "0" doppelt beschreibe

    Dem war nicht so.


    Ich beschreibe den digitalen Ausgang (Modbusadresse mit der Adresse "0") in der UVR.

    Für mich war logisch das Ein und Ausgänge in verschiedenen Speicherbereichen liegen.

    Sollte also kein Problem sein.


    Das hat mir der Support von TA auch bestätigt und es auch selbst nochmals mit meiner Programmierung geprüft.


    Ich habe daraufhin den digitalen Ausgang gelöscht und schon kamen die analogen Werte auf der Adresse "0" wieder an.


    Somit konnte der Fehler nur in Node Red liegen.


    Und dann habe ich den Haken gesehen : Delay to activate Input !!!




    Damit überschreibt er in meinem Fall den analogen Eingang in der UVR mit dem digitalen Ausgang mit der Adresse "0"

    Das habe ich nicht gewusst ...


    Also Haken aus und schon funktioniert es ...


    Dann habe ich mich beim TA Support gemeldet und mich für die entstandene Mühe und meinen Fehler entschuldigt.


    Die Rückantwort von TA hat nicht lange gedauert .... Hut ab !!! und alle Daumen hoch !!!




    schönes Wochenende ...mfg Cord

  • Hallo


    Es gibt neue Firmware ... in Bezug auf Modbus/ CAN BUS / DL Bus usw. hat es Änderungen gegeben


    mfg Cord

  • Hallo


    Es gibt neue Firmware ... in Bezug auf Modbus/ CAN BUS / DL Bus usw. hat es Änderungen gegeben


    mfg Cord

    ja, es gibt ( positive Neuerungen ) zb das Thema CORA - ID ist nun in Onlingrafiken wählbar, was positiv ist zb bei FTS - Tausch ...also man kann nicht nur den Type ändern ....


    NEGATIV - Designer : früher konnte man mit " rechter Maustaste " kopieren , anschließend " einfügen....es wurde die Seitengröße der copierten Seite zb beibehalten. Nun LEIDER nicht mehr, sodas man hier wieder Hand anlegen muss... ebenso die " rechte Maustaste " einfügen " ist weg.de ;) ....mal schauen, was mir noch auffällt....


    VG


    Andreas

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!