Hallo zusammen,
ich versuche aktuell, eine UVR16x2 direkt über den CAN-Bus mit einem Raspberry Pi (MCP2515 / SocketCAN) zu koppeln – ohne CMI. Ziel ist es, die CAN-Analogwerte (Temperaturen etc.) auf dem Pi/IP-Symcon zu empfangen.
Setup:
UVR16x2
Raspberry Pi 3 + MCP2515 CAN HAT
Bitrate: 50 kbit/s
CAN-H / CAN-L korrekt verkabelt, Abschluss ~60 Ohm
Gemeinsamer GND vorhanden
UVR Knoten-ID = 1
In TAPPS sind 12 CAN-Analog-Ausgänge konfiguriert (Intervall 1 min)
Beobachtungen:
Der Pi fungiert als aktiver CAN-Knoten (SocketCAN, python-can, candump)
Heartbeat funktioniert:
Der Pi sendet zyklisch CAN-ID 0x701 (Heartbeat, CANopen-Style)
Die UVR reagiert darauf:
Antwort auf 0x401 → 0x402
Zusätzlich ist sporadisch ein System-/Statusframe auf ID 0x004 sichtbar
Das zeigt:
Physikalischer CAN funktioniert
UVR „sieht“ den Pi als Teilnehmer
Ein grundlegender Handshake scheint stattzufinden
Problem:
Trotzdem kommen keine Sensordaten / CAN-Analogwerte:
Keine TPDOs auf den erwarteten IDs
(z. B. 0x201 / 0x281 / 0x301 bei Node 1, wie in TA-Doku beschrieben)
Auch nach längerer Laufzeit, Reboot der UVR etc. keine Messwert-Frames
Fragen an die Runde:
Hat jemand praktische Erfahrung, eine UVR16x2 direkt mit einem Raspberry Pi (ohne CMI) über CAN zu betreiben?
Reicht ein Heartbeat allein aus, oder ist ein weiterer Initialisierungs-/MPDO-Schritt notwendig, damit die UVR ihre TPDOs freigibt?
Gibt es bekannte zusätzliche Requests (z. B. Objekt-/Einheitenabfrage), die ein CMI normalerweise sendet?
Oder sendet die UVR ihre CAN-Analogwerte grundsätzlich nur, wenn ein CMI oder eine zweite UVR im Netz ist?
Mir geht es nicht um Firmware-Reverse-Engineering, sondern um das korrekte CAN-Protokollverhalten, das die UVR erwartet, bevor sie Messwerte sendet.
Ich freue mich über jeden Hinweis aus der Praxis – gern auch Stichworte oder Erfahrungen wie „geht nur mit CMI“ vs. „geht mit Pi, aber man muss X/Y tun“.
