@DaleZum Thema Datenrate: Aus meiner Sicht ist die Menge an Daten auf dem Bus eher nicht das Problem. Der CAN-Bus selbst und die verwendeten Protokolle sind robust und so ausgelegt, dass es sehr zuverlässig funktioniert. Relevant ist eher die Anzahl der Daten pro Abfrageintervall. Diese Datenmenge hängt sehr davon ab, welche Datenpunkte abgefragt werden. Manche Datenpunkte bestehen aus einem einzigen Datenbyte (da kommt dann noch der Protokoll-Overhead dazu), andere aus bis zu knapp 200 Datenbytes. Diese werden dann in viele einzelne CAN-Frames aufgeteilt (zu je max. 7 Datenbytes) und in einem bestimmten Zeitraster gesendet. Das kann dann schon mal 500 ms oder länger dauern. Wenn Du also sehr viele (lange) Datenpunkte abfragst, kann das länger als 10 Sekunden dauern. Machst Du das alle 10 Sekunden, wird sich innerhalb von open3e eine endlose Warteschlange aufbauen. Zusätzliche Anfragen über den Listener-Mode würden (stark) verzögert ausgeführt werden. Zum Thema Datensparsamkeit: Für diesen Ansatz gibt es ja E3onCAN. Das verursacht überhaupt keinen zusätzlichen Datenverkehr auf dem CAN-Bus, sondern hört nur zu. Deshalb liefert es nur Daten, wenn die Geräte von sich aus Daten senden. Das passiert typisch bei (per CAN) vernetzten E3-Geräten. Das Hauptgerät ist ohne Vernetzung auf dem internen Bus sehr gesprächig, aber nicht auf dem externen. E3onCAN und open3e können problemlos parallel betrieben werden. E3onCAN liefert dann die Daten, die sich oft ändern unmittelbar nach der Änderung, z.B. Sensorwerte. Mit open3e fragt man Daten ab, die sich selten ändern oder von E3onCAN nicht geliefert werden.
... Mehr anzeigen
