-> Hier kostenlos registrieren
Servus zusammen,
ich plane gerade im Rahmen einer Abschlussarbeit die Steuerungstechnik für eine mobile Maschine, bei der eine Kommunikation zwischen Gerätschaften auf Grundlage des CAN2.0A (Standard-ID) und CAN2.0B (Extended-ID) stattfinden soll. Grob aufgezeichnet wird es wahrscheinlich wie folgt aussehen...
Geplant hatte ich ursprünglich die Kommunikation wie abgebildet auf jeweils verschiedenen CAN-Schnittstellen laufen zu lassen, also die CANopen-, HMI- und J1939-Kommunikation getrennt von einander, wegen der verschiedenen Protokolle. Allerdings habe ich gesehen, dass mir nur zwei CAN-Schnittstellen zur Verfügung stehen, da ich sonst neue Komponenten benötige.
1. Könnte man ggf. den J1939 und den CANopen auf eine Schnittstelle zusammenlegen? Dann hätte ich ja den Standard-Identifier und den Extended-Identifier auf einem Bus. Falls das funktioniert: Wie läuft das dann mit der Priorisierung?
2. Macht es generell überhaupt Sinn die CAN-Kommunikation wie oben abgebildet voneinander getrennt zu betreiben oder ist das überhaupt nicht nötig? Ich fand es auf den ersten Blick irgendwie "sauberer"
3. Bei dem HMI-Gerät handelt es sich um ein Display der Firma Topcon (ehem. Wachendorff), welches auf einem embedded-Linux-OS läuft und sich per CoDeSys 3 programmieren lässt. Macht es eventuell Sinn die ganze Logik auf das Display zu schieben und die PLC wegzulassen?. Ich habe mal gehört, dass diese Linux-HMI-Geräte wohl - anders als eine "normale SPS" - nicht zyklisch, sondern ereignisgesteuert arbeiten, d.h. nur auf Knopfdruck reagieren und mir zusätzlich noch durch Ladezeiten von Bilddateien u.U. Laufzeitprobleme entstehen können. Dementsprechend sei wohl eine Kapselung der Logik vom HMI sinnvoll. Hat da evtl. jemand Erfahrungen in dem Bereich?
Freue mich auf Eure Antworten.
Danke!
ich plane gerade im Rahmen einer Abschlussarbeit die Steuerungstechnik für eine mobile Maschine, bei der eine Kommunikation zwischen Gerätschaften auf Grundlage des CAN2.0A (Standard-ID) und CAN2.0B (Extended-ID) stattfinden soll. Grob aufgezeichnet wird es wahrscheinlich wie folgt aussehen...
Geplant hatte ich ursprünglich die Kommunikation wie abgebildet auf jeweils verschiedenen CAN-Schnittstellen laufen zu lassen, also die CANopen-, HMI- und J1939-Kommunikation getrennt von einander, wegen der verschiedenen Protokolle. Allerdings habe ich gesehen, dass mir nur zwei CAN-Schnittstellen zur Verfügung stehen, da ich sonst neue Komponenten benötige.
1. Könnte man ggf. den J1939 und den CANopen auf eine Schnittstelle zusammenlegen? Dann hätte ich ja den Standard-Identifier und den Extended-Identifier auf einem Bus. Falls das funktioniert: Wie läuft das dann mit der Priorisierung?
2. Macht es generell überhaupt Sinn die CAN-Kommunikation wie oben abgebildet voneinander getrennt zu betreiben oder ist das überhaupt nicht nötig? Ich fand es auf den ersten Blick irgendwie "sauberer"
3. Bei dem HMI-Gerät handelt es sich um ein Display der Firma Topcon (ehem. Wachendorff), welches auf einem embedded-Linux-OS läuft und sich per CoDeSys 3 programmieren lässt. Macht es eventuell Sinn die ganze Logik auf das Display zu schieben und die PLC wegzulassen?. Ich habe mal gehört, dass diese Linux-HMI-Geräte wohl - anders als eine "normale SPS" - nicht zyklisch, sondern ereignisgesteuert arbeiten, d.h. nur auf Knopfdruck reagieren und mir zusätzlich noch durch Ladezeiten von Bilddateien u.U. Laufzeitprobleme entstehen können. Dementsprechend sei wohl eine Kapselung der Logik vom HMI sinnvoll. Hat da evtl. jemand Erfahrungen in dem Bereich?
Freue mich auf Eure Antworten.
Danke!