Hallo,
wir arbeiten gerade daran, den RevPi Core (und seine Module) zur Standardumgebung für unsere industrielle Steuerungssoftware zu machen.
Hierbei bereitet mir die CAN-Schnittstelle erhebliches Kopfzerbrechen. Ich benötige zwingend einen möglichst rohen Zugang zu CAN-Bussen, eine Nutzung von CANopen ist keine Option. Natürlich kann ich z.B. via USB einen PCAN anschließen, was ich zwar momentan für Tests mache aber in der produktiven Schaltschrankumgebung keine Option ist.
Daher meine Frage: Ist es möglich, den CANopen Gateway mit rohem CAN-Traffic zu betreiben? Gibt es ggf. eine andere fertige Lösung hierfür?
Falls die Möglichkeit noch nicht besteht, wäre ich bereit hier Entwicklungsarbeit beizusteuern.
Meiner Einschätzung nach wäre es mit dem im Gateway verbauten STM32F205RET6 ein leichtes, einen Raw-Mode über die PiBridge abzubilden. Im einfachsten Fall könnte man dies durch ein Bereitstellen der rohen Pakete in Form einer ausles- und quittierbaren Eingangswarteschlange und einer entsprechenden Ausgangswarteschlange zum Senden mit wenig Aufwand umsetzen.
Vielen Dank,
MfG,
Martin
Roher CAN-Traffic?
Hallo Martin,
es ist leider nicht möglich, mit dem Gateway CAN Protokoll zu fahren. Das Gateway arbeitet ausschließlich mit dem CANopen Protokoll (wir weisen im Shop sehr ausführlich und deutlich auf diese Tatsache hin, da es elider immer wieder Kunden gibt, die den Unterschied gar nicht kennen).
CAN mit einem modularen Gateway zu fahren ist keine so glückliche Idee, denn unser PiBridge Bus arbeitet strickt zyklisch. CAN ist ein Message basiertes Protokoll, ausgelegt auf Event basierten Datenaustausch. Um auf einem zyklischen Bus ein offenes CAN zu implementieren würde eine Art Mailbox-System mit Flags im Prozessabbild notwendig sein, über welche das Eintreffen und Abarbeiten von Messages signalisiert wird. Selbst wenn man das dann implementiert hat, würden zusätzlich komplette neue Bibliotheken notwendig, um die unter C oder Python bereitstehenden CAN-Libraries mit dieser Schnittstelle verfügbar zu machen.
Wir haben daher einen ganz anderen Lösungsweg gewählt:
Unser neuer RevPi Connect, der Ende Q1 dann voraussichtlich lieferbar sein wird, hat ja neben der PiBridge auf der anderen Seite eine "ConBridge". Das ist ein message basierter back plane bus mit SPI und UART. Und für diese Systemschnittstelle wird es dann schon Ende März ein BlueTooth Modul und zur Hannovermesse dann ein M-Bus wireless und ein CAN Modul geben. Hierbei ist dann der CAN Controller direkt im Linux Kernel eingebunden und alle open source libraries für CAN werden deshalb mit diesem Modul laufen.
Ich hoffe das hilft, auch wenn es keine "Sofort-Lösung" ist. Wir wissen aber von mehreren Kunden, dass ein großer Bedarf für natives CAN mit unserem RevPi besteht und wollten daher gleich eine solide und unkomplizierte Lösung auf den Markt bringen. Wenn das zeitlich für Euch zu spät kommt, dann bleibt aktuell nur die Möglichkeit eines CAN Interfaces auf USB. Ich habe auch gehört, dass es CAn auf Ethernet geben soll, weiß aber nicht, wie das dann mit den bekannten CAN Bibliotheken zusammengehen soll.
es ist leider nicht möglich, mit dem Gateway CAN Protokoll zu fahren. Das Gateway arbeitet ausschließlich mit dem CANopen Protokoll (wir weisen im Shop sehr ausführlich und deutlich auf diese Tatsache hin, da es elider immer wieder Kunden gibt, die den Unterschied gar nicht kennen).
CAN mit einem modularen Gateway zu fahren ist keine so glückliche Idee, denn unser PiBridge Bus arbeitet strickt zyklisch. CAN ist ein Message basiertes Protokoll, ausgelegt auf Event basierten Datenaustausch. Um auf einem zyklischen Bus ein offenes CAN zu implementieren würde eine Art Mailbox-System mit Flags im Prozessabbild notwendig sein, über welche das Eintreffen und Abarbeiten von Messages signalisiert wird. Selbst wenn man das dann implementiert hat, würden zusätzlich komplette neue Bibliotheken notwendig, um die unter C oder Python bereitstehenden CAN-Libraries mit dieser Schnittstelle verfügbar zu machen.
Wir haben daher einen ganz anderen Lösungsweg gewählt:
Unser neuer RevPi Connect, der Ende Q1 dann voraussichtlich lieferbar sein wird, hat ja neben der PiBridge auf der anderen Seite eine "ConBridge". Das ist ein message basierter back plane bus mit SPI und UART. Und für diese Systemschnittstelle wird es dann schon Ende März ein BlueTooth Modul und zur Hannovermesse dann ein M-Bus wireless und ein CAN Modul geben. Hierbei ist dann der CAN Controller direkt im Linux Kernel eingebunden und alle open source libraries für CAN werden deshalb mit diesem Modul laufen.
Ich hoffe das hilft, auch wenn es keine "Sofort-Lösung" ist. Wir wissen aber von mehreren Kunden, dass ein großer Bedarf für natives CAN mit unserem RevPi besteht und wollten daher gleich eine solide und unkomplizierte Lösung auf den Markt bringen. Wenn das zeitlich für Euch zu spät kommt, dann bleibt aktuell nur die Möglichkeit eines CAN Interfaces auf USB. Ich habe auch gehört, dass es CAn auf Ethernet geben soll, weiß aber nicht, wie das dann mit den bekannten CAN Bibliotheken zusammengehen soll.
Unser RevPi Motto: Don't just claim it - make it!
Hallo,
Ich habe derartige Warteschlangen-Systeme in der Vergangenheit bereits implementiert (zum durchreichen von Paketen auf uC-Ebene über gemeinsame Speicher) und es wäre für unseren unmittelbaren Anwendungsfall akzeptabel. An anderer Stelle hatte ich schon Möglichkeiten, CANopen-Adapter von SPS-Systemen im Raw-Mode für derartiges zu zweckentfremden, daher meine Frage bezüglich des CAN Gate.
Den PCAN-Ethernet DR (2-Kanal-CAN der sich über UDP-Pakete ansteuern lässt) habe ich als kurzfristige Lösung im Schaltschrank-Prototyp (als Ersatz für den aktuell bei Tests genutzten PCAN-USB) zur Hand, ist aber aus Architektur-Sicht bei uns nicht wünschenswert aber vorübergehend eine funktionsfähige Option.
Vielen Dank für die schnelle Hilfe und die großartigen Produkte, ihr macht meiner Meinung nach einen phantastischen Job!
MfG,
Martin
Ich habe derartige Warteschlangen-Systeme in der Vergangenheit bereits implementiert (zum durchreichen von Paketen auf uC-Ebene über gemeinsame Speicher) und es wäre für unseren unmittelbaren Anwendungsfall akzeptabel. An anderer Stelle hatte ich schon Möglichkeiten, CANopen-Adapter von SPS-Systemen im Raw-Mode für derartiges zu zweckentfremden, daher meine Frage bezüglich des CAN Gate.
Das klingt nach exakt der Lösung, die wir benötigen, auch an vielen anderen Stellen. Falls da Tester gebraucht werden, stünde ich als early adopter (gerne auch halbgare Muster) zur Verfügung. Das würde mir fast unmittelbar ermöglichen, endlich viele unserer Steinzeit-SPS-Lösungen zu ersetzen.volker wrote: ↑21 Feb 2018, 20:56Unser neuer RevPi Connect, der Ende Q1 dann voraussichtlich lieferbar sein wird, hat ja neben der PiBridge auf der anderen Seite eine "ConBridge". Das ist ein message basierter back plane bus mit SPI und UART. Und für diese Systemschnittstelle wird es dann schon Ende März ein BlueTooth Modul und zur Hannovermesse dann ein M-Bus wireless und ein CAN Modul geben. Hierbei ist dann der CAN Controller direkt im Linux Kernel eingebunden und alle open source libraries für CAN werden deshalb mit diesem Modul laufen.
Ich hoffe das hilft, auch wenn es keine "Sofort-Lösung" ist. Wir wissen aber von mehreren Kunden, dass ein großer Bedarf für natives CAN mit unserem RevPi besteht und wollten daher gleich eine solide und unkomplizierte Lösung auf den Markt bringen. Wenn das zeitlich für Euch zu spät kommt, dann bleibt aktuell nur die Möglichkeit eines CAN Interfaces auf USB. Ich habe auch gehört, dass es CAn auf Ethernet geben soll, weiß aber nicht, wie das dann mit den bekannten CAN Bibliotheken zusammengehen soll.
Den PCAN-Ethernet DR (2-Kanal-CAN der sich über UDP-Pakete ansteuern lässt) habe ich als kurzfristige Lösung im Schaltschrank-Prototyp (als Ersatz für den aktuell bei Tests genutzten PCAN-USB) zur Hand, ist aber aus Architektur-Sicht bei uns nicht wünschenswert aber vorübergehend eine funktionsfähige Option.
Vielen Dank für die schnelle Hilfe und die großartigen Produkte, ihr macht meiner Meinung nach einen phantastischen Job!
MfG,
Martin
Dabke Martin für das Lob.
Wir haben übrigens inzwischen den Chip definiert, den wir einsetzen werden: HI-3110
Wir haben übrigens inzwischen den Chip definiert, den wir einsetzen werden: HI-3110
Unser RevPi Motto: Don't just claim it - make it!
