Umstieg auf CANopen sinnvoll?

[Erol S. (supere)]

Hallo alle zusammen,

ich habe eine allgemeine Frage. Kurz zur Situation: Ich arbeite in einem
mittelständischen Betrieb (Mitarbeiter ca. 200), der Marktführend in
seiner Branche ist und seine Produkte weltweit verkauft.
Bisher wurde der Informationsaustausch zwische Maschine und PC mit Hilfe
eines CAN-Busses hergestellt. Dabei wurden alle Codes von Hand
geschrieben.
Nun überlegen wir uns, auf CANopen umzusteigen und evtl. sogar Stacks zu
erwerben, um den Programmierungsaufwand zu erleichtern.
Nun stellen sich die Fragen:
1. Welche Vorteile und Nachteile ergeben sich dadurch?
2. Wie kann man die Kommunikation zu den älteren Maschinen ohne CANopen
gewähren?
3. Was muss man beachten?
4. Welche weiteren Infos sind auch noch wichtig für mich?

Ich bitte um zahlreiche Antworten, um mir ein genaueres Bild machen zu
können.
Vielen Dank für eure Antworten schon im voraus.

E. S.

[roffez (Gast)]

CANopen ist ein ziemlich komplexes Thema. Ich selber habe mal mit dem 
Protokollstack von IXXAT zu tun gehabt...das ist schon harte Kost.
Die Idee ist ja schon gut, aber man darf den Aufwand nicht 
unterschätzen.

[CaH (Gast)]

Da CANopen auf CAN Layer 2 (native CAN) basiert hast du kein Problem 
auch weiterhin die alten Maschinen anzusprechen, da du den native CAN ja 
weiter nutzen kannst.
Zu beachten ist das du eine saubere CAN Treiber-Schicht hinstellst, auf 
die der CANopen Stack aufsetzt.

Hab leider nicht mehr Zeit noch was zu schreiben...später mehr

Gruß
CaH

[Peter D. (peda)]

Erol Sengül wrote:
> Nun überlegen wir uns, auf CANopen umzusteigen und evtl. sogar Stacks zu
> erwerben, um den Programmierungsaufwand zu erleichtern.

Dazu müßte man erstmal wissen, was bei Deiner jetzigen Lösung schwer 
ist.

In der Regel hat man bei Implementierung eines Protokollstandards einen 
wesentlich höheren Programmieraufwand um diesen Standard an seine 
spezifischen Anforderungen anzupassen.

Auch soll so ein Standard ja viele Applikationen abdecken. Er enthält 
also viele Funktionen, die Du garnicht brauchst, quasi ne Menge toter 
Code.

Bzw. Du wirst einige Funktionen bereitstellen müssen, weil sie zum 
Standard gehören, auch wenn Du sie nicht benutzt.


Einen Standard zu implementieren lohnt sich eigentlich nur, wenn man 
Fremdgeräte mit in seine Anlage einbinden will, bzw. eigene Geräte in 
Fremdanlagen nach diesem Standard.



Peter

[Erol S. (supere)]

Peter Dannegger wrote:
> Erol Sengül wrote:
>> Nun überlegen wir uns, auf CANopen umzusteigen und evtl. sogar Stacks zu
>> erwerben, um den Programmierungsaufwand zu erleichtern.
>
> Dazu müßte man erstmal wissen, was bei Deiner jetzigen Lösung schwer
> ist.
Schwer ist es momentan eigentlich nicht, da hast du recht.

Eigentlich ist es nur eine Zeitfrage. D.h. wir dachten uns, dass man mit 
einem Standard-Stack es leichter hätte, Änderungen am Prgramm 
durchzuführen oder bei neuen Produkten alles immer wieder neu zu 
schreiben.

Mit dem Toten-Code, gebe ich dir auch recht. Für meinen Versuch ein 
Heartbeat, SDO und PDO zu senden und zu empfangen habe ich insgesamt 38 
C-Files und doppelt so viele H-Files.

Für weitere Meinungen und Erfahrungen bin ich immer noch Ohr.

LG

E.S.

[Erol S. (supere)]

Hallo an alle und nachträglich ein gutes neues Jahr!

Ich befasse mich weiterhin mit den Vor-und Nachteilen mit der Umstellung 
auf CANopen.
Eine Frage konnte ich noch nicht richtig aus meinen Quellen rauslesen:

Meine alte Maschine sendet CAN Nachrichten mit fest definierten CAN-IDs.
Die CAN-IDs bestehen aus der MAC-ID und der Message-ID.
Wenn jetzt ein CANopen-Master kommt, wie kann dieser die Nacrichten bzw. 
Objekte der älteren Maschine erfassen?
Im CANopen sehen doch die CAN-IDs ganz anders aus als in CAN, oder irre 
ich mich?
Gibt es denn so etwas(Hardware oder Software), dass aus den Native-Can 
Nachrichten brauchbare CANopen Nachrichte erzeugt?

Vielen Dank im voraus.

Erol

PS: PEACE FOREVER

[Severino R. (severino)]

Crossposting :-(
Beitrag "Umstieg auf CANopen"