Quelltext der Seite Entwicklung einer CANopen-Lift-Schnittstelle

Für Entwickler und Projektleiter im Bereich der Entwicklung die zum ersten mal vor die Aufgabe gestellt werden, eine CANopen-Lift-kompatible Schnittstelle zu implementieren, stellt sich oft die Frage nach dem Aufwand und die Vorgehensweise für eine solche Entwicklung. Hier sollen einige Erfahrungen dargelegt werden. 

== Wo erhält man eine Einführung in CAN/CANopen? ==
Eine sehr gute Einführung in das Thema CAN und CANopen erhält man bei den Schulungen, die regelmäßig von der CiA angeboten werden. Eine Liste über die kommenden Schulungen finden Sie auf der [http://www.can-cia.org/index.php?id=seminars CiA-Webseite].

== Woher bekomme ich die CANopen-Spezifikation und welche Kosten fallen dafür an? ==
Die aktuelle Spezifikation erhalten Sie immer über die CiA. Wenn eine Spezifikation den DS-Status erreicht hat, steht sie zum freien Herunterladen auf der [http://www.can-cia.org/index.php?id=6 CiA-Webseite] bereit. 

Spezifikationen, die sich noch im DSP-Status befinden und sich somit noch ändern können, stehen nur den Mitgliedern der CiA zur Verfügung, da diese auch über die internen Diskussionen der Arbeitsgruppen informiert sind. 

Die Version 2.0 der CiA-417 befindet sich im DS-Status und kann von der [http://www.can-cia.org/index.php?id=6 CiA-Webseite] herunter geladen werden. 

Die aktuelle Version 2.2 der CiA-417 befindet sich zzt. im DSP-Status und steht somit nur CiA-Mitgliedern zur Verfügung. 

Über die Vorteile und die Kosten der Mitgliedschaft finden Sie Informationen auf der [http://www.can-cia.org/index.php?id=37 CiA-Webseite].

== Sollte man einen fertigen CANopen-Stack kaufen (Kosten?) oder kann man nach der CANopen-Spezifikation den Stack selbst programmieren (Zeitaufwand?) ==
Zu diesem Punkt gibt es wohl keine generelle Empfehlung. Zu viele Randbedingungen müssen hier berücksichtigt werden.  

=== Anwendungsbereich ===
Ein Kriterium ist, die Anzahl und die Art der Geräte die Entwickelt werden sollen. 

Wenn ein Sensor oder eine Unit mit einem relativ einfachen virtuellem Gerät ausgestattet werden soll und es die Ressources des Prozessors zulassen, dann kann man einen Stack kaufen, die Funktionalität des Gerätes implementiren, das Ganze beim PlugFest testen und sich dem nächsten Projekt widmen. Nicht unterschätzen sollte man den Aufwand für die Einarbeitung in einen gekauften Stack, der auch vielen Funktionen enthält, die für CANopen-Lift nicht erforderlich sind. 

Wenn man viele unterschiedliche Geräte oder eine Steuerung, ein Gateway oder Diagnosetool entwickeln will, die auch das Netzwerkmanagement übernehmen, muss man sich sehr tief in die Funktionalitäten und Eigenheiten der Applikation einarbeiten und es liegt an dem Programmierer, ob er sich lieber in einen fremden Code einarbeitet oder selbst schreibt. Möglich ist auch hier beides. 

=== Zeitaufwand ===
Ich hoffe, hier gibt es einen regen Erfahrungsaustausch von Programmierern, die gekaufte oder eigene Stacks implementiert haben. 

Es gibt Programmierer, die die Spezifikation gelesen haben und nach 3 Monaten einen Prototypen mit selbst geschriebenem Stack inklusive der Funktionalität eines Sensors vorgestellt haben. Dann fehlen aber noch viele Kleinigkeiten, wie Autobauderkennung, Softwareupdate, virtuelles Menü (Terminal Mode) und die Kompabilität muss das nächste PlugFest zeigen. 

Andererseits gibt es auch Hersteller, die einen Stack gekauft haben, diesen in die eigenen Produkte implementieren und teilweise viel länger bis zur Marktreife eines Produkts benötigen. Es lässt sich aber nicht genau bestimmen, wieviel Zeit für die reine Implementierung des Stack und wieviel Zeit für die Entwicklung der eigentlichen Applikationssoftware des Gerätes benötigt werden. 

=== Kosten ===
Es gibt inzwischen mehrere Anbieter von CANopen-Lift-Stacks mit unterschiedlichen Funktionsumfängen und Lizenzmodellen. 

Die Kosten sollten bei den Anbietern für das jeweilige Produkt erfragt werden. 

Vielleicht berichten hier zukünftig einige Anwender von ihren Erfahrungen mit den jeweiligen Stacks.

== Abschätzung des Speicherbedarfs (Programm- und Datenspeicher bzw. nichtflüchtiger Datenspeicher) bei der Implementierung eines virtuellen Gerätes. ==


== Mit welchen Werkzeugen ist ein vernünftiges Debuggen / Testen meiner Software möglich? ==



[[Kategorie:Empfehlungen]]