Climate Solutions Community

@Juergen-B du hast die Antwort gefunden. Es ist abhängig von der Länge der Datenpunktliste. Ich habe einfach mal die Liste von x680 auf 4 Einträge reduziert und komme damit auf eine Zeit von 100ms. Damit gilt es jetzt aus meiner Sicht zu prüfen, ob ein Dictionary oder ein Array für die Datenpunktliste in udsoncan verwendet wird, und wieso ein eventueller Zugriff auf den Key nicht innerhalb von O(1) durchgeführt werden kann. Ansonsten könnte man natürlich nur die relevanten Datenpunkte innerhalb des Konstruktors von Open3Eclass als Config-Liste übergeben, z. B. in dem man die Schnittmenge aus den existierenden und den angefragten DID's erstellt. Schaue ich mir heute Abend mal an.   Update: Ursache ist ein deepcopy der Datenpunktliste in der Funktion def check_did_config (python-udsoncan/udsoncan/common/dids.py) Zeile 179, welcher bei jedem make_request und interpret_response durchgeführt wird … da braucht man sich dann auch nicht mehr wundern und der arme kleine Pi Zero kommt für eine triviale Operation an seine Grenzen ... Mehr anzeigen

Guten Morgen @HerrP ,   naja DID 268 ist ja nicht "lang" ... zum Vergleich habe ich ECU x680 und x6cf mit der gleichen DID auf dem develop-Branch abgefragt:   ~/devBranch/open3e $ time python3 Open3Eclient.py -cnfg dev -r 0x680.[268],0x6cf.[268],0x680.[268],0x6cf.[268] -v  [udsoncan:read_data_by_identifier] total time: 2.466827392578125 0x680 268 FlowTemperatureSensor {"Actual": 30.0, "Minimum": 13.3, "Maximum": 72.5, "Average": 28.6, "Unknown": 0} [udsoncan:read_data_by_identifier] total time: 0.2308192253112793 0x6cf 268 FlowTemperatureSensor {"Actual": 30.0, "Minimum": 0.0, "Maximum": 0.0, "Average": 0.0, "Unknown": 0} [udsoncan:read_data_by_identifier] total time: 2.3276524543762207 0x680 268 FlowTemperatureSensor {"Actual": 30.0, "Minimum": 13.3, "Maximum": 72.5, "Average": 28.6, "Unknown": 0} [udsoncan:read_data_by_identifier] total time: 0.20518827438354492 0x6cf 268 FlowTemperatureSensor {"Actual": 30.0, "Minimum": 0.0, "Maximum": 0.0, "Average": 0.0, "Unknown": 0} closing 0x680 - bye! closing 0x684 - bye! closing 0x68c - bye! closing 0x6cf - bye!   real 0m9.959s user 0m8.915s sys 0m0.389s   Wieso jetzt x680 gegenüber x6cf zehnmal langsamer ist, obwohl die Datenstruktur dieselbe sein sollte … ist "interessant". ... Mehr anzeigen

Guten Morgen Juergen,   die Zeiten werden mittels time() vor und nach dem Aufruf der Methode read_data_by_identifier der Klasse udsonscan.client in der Klasse O3Eclass ermittelt: start_time = time.time() response = self.uds_client.read_data_by_identifier([did]) # return value and idstr end_time = time.time() print(f"[udsoncan:read_data_by_identifier] total time: {end_time-start_time}")  Die Idee mit candump war auch gut, da kann man gut sehen, dass die Zeiten auf dem Bus bei ca. 30ms liegen:    @raspberrypi:~ $ candump -tA can0 | grep " 6[89CD][0F] " (2024-01-30 07:46:16.433214) can0 680 [8] 03 22 01 0C 00 00 00 00 (2024-01-30 07:46:16.435172) can0 690 [8] 10 0C 62 01 0C 2C 01 85 (2024-01-30 07:46:16.452517) can0 680 [8] 30 00 0A 00 00 00 00 00 (2024-01-30 07:46:16.465353) can0 690 [8] 21 00 D5 02 1E 01 00 55 (2024-01-30 07:46:17.669447) can0 6CF [8] 03 22 01 0C 00 00 00 00 (2024-01-30 07:46:17.672819) can0 6DF [8] 10 0C 62 01 0C 2C 01 00 (2024-01-30 07:46:17.687733) can0 6CF [8] 30 00 0A 00 00 00 00 00 (2024-01-30 07:46:17.700151) can0 6DF [8] 21 00 00 00 00 00 00 55   und das obwohl die User-Zeiten bei 2,3s bzw. 0,2s für den Methodenaufruf liegen: @raspberrypi:~/open3e $ time python3 Open3Eclient.py -cnfg dev -r 0x680.[268],0x6cf.[268] -v --raw [udsoncan:read_data_by_identifier] total time: 2.308736801147461 0x680 268 FlowTemperatureSensor "2c018500d5021e0100" [udsoncan:read_data_by_identifier] total time: 0.1911451816558838 0x6cf 268 FlowTemperatureSensor "2c0100000000000000" closing 0x680 - bye! closing 0x684 - bye! closing 0x68c - bye! closing 0x6cf - bye!   real 0m7.313s user 0m6.736s sys 0m0.262s   und somit die "Ursache" aus meiner Sicht nicht im CAN-Bus, sondern in den Bibliotheken udsoncan und isotop zu suchen ist, oder?   Beste Grüße  Jens  ... Mehr anzeigen

Vielen Dank an @HerrP für dieses geniale Projekt.   Da ich bisher in diesem Beitrag noch nichts dazu gefunden habe, möchte ich von Euch gerne wissen, ob Ihr bei Euren Systemen auch schon unterschiedliche Antwortzeiten der ECU's beobachtet habt. Insbesondere die HPMU (0x680) benötigt extrem lange um zu antworten.   System: Vitocal 200s E.06 mit Softwarestand 2223, Rasperry Pi Zero W   @raspberrypi:~/open3e $ time python3 Open3Eclient.py -cnfg dev -r 0x680.[269,271,274],0x68c.[320,324],0x6cf.[268,1043] -v --raw [udsoncan:read_data_by_identifier] total time: 2.3658292293548584 0x680 269 ReturnTemperatureSensor "19018400a302110100" [udsoncan:read_data_by_identifier] total time: 2.391155958175659 0x680 271 DomesticHotWaterSensor "fd0142016302fd0100" [udsoncan:read_data_by_identifier] total time: 2.4855570793151855 0x680 274 OutsideTemperatureSensor "20000000ffff1f0000" [udsoncan:read_data_by_identifier] total time: 0.3289310932159424 0x68c 320 PrimaryHeatExchangerLiquidTemperatureSensor "06003efe1a04060000" [udsoncan:read_data_by_identifier] total time: 0.38820672035217285 0x68c 324 CompressorOutletTemperatureSensor "54023efedc05540200" [udsoncan:read_data_by_identifier] total time: 0.1858823299407959 0x6cf 268 FlowTemperatureSensor "260100000000000000" [udsoncan:read_data_by_identifier] total time: 0.23324298858642578 0x6cf 1043 AllengraSensor "ee3e2a0100" closing 0x680 - bye! closing 0x684 - bye! closing 0x68c - bye! closing 0x6cf - bye!   real 0m13.000s user 0m11.842s sys 0m0.479s   @raspberrypi:/# ip -details -statistic link show can0 2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10     link/can  promiscuity 0 minmtu 0 maxmtu 0      can state ERROR-ACTIVE restart-ms 0   bitrate 250000 sample-point 0.875   tq 250 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1  gs_usb: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..1024 brp-inc 1  clock 48000000   re-started bus-errors arbit-lost error-warn error-pass bus-off  0          0          0          0          0          0         numtxqueues 1 gso_max_size 65536 gso_max_segs 65535      RX: bytes  packets  errors  dropped missed  mcast        236877     68318    0       2014    0       0            TX: bytes  packets  errors  dropped carrier collsns      2496       312      0       0       0       0      Beste Grüße  Jens    ... Mehr anzeigen