mikrocontroller.net

Forum: PC-Programmierung Umstieg auf CANopen


Autor: Erol Sengül (supere)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sebastian B. (mircobolle)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erol Sengül wrote:
> Nun überlegen wir uns, auf CANopen umzusteigen und evtl. sogar Stacks zu
> erwerben, um den Programmierungsaufwand zu erleichtern.
Sicherlich sinnvoll, wenn ihr eure Produkte schnell auf den Markt 
bringen wollte.

> Nun stellen sich die Fragen:
> 1. Welche Vorteile und Nachteile ergeben sich dadurch?
Ganz klarer Vorteil: canOpen ist ein Standard-Protokoll. D.h. falls eure 
Produkte eine Schnittstelle zu anderen CAN Geräten darstellt ist eine 
Integration problemlos möglich.
Nachteil: canOpen ist ein High-Layer Protokoll und bringt damit 
natürlich Overhead mit sich.

> 2. Wie kann man die Kommunikation zu den älteren Maschinen ohne CANopen
> gewähren?
2 Nachrichtenformate von canOpen sind SDOs und PDOs. PDOs können 
sporadisch und unbestätigt versendet werden (bis zu 8 Byte Daten). Mit 
SDOs wird ein bestätigter Datenaustausch relaisiert (mit segementierten 
Daten > 8 Byte).

> 3. Was muss man beachten?
siehe canOpen Spezifikation. Beschäftige dich mal mit SDOs, PDOs und dem 
Object Directory. Im Objektverzeichnis werden alle Einträge definiert 
auf die von Aussen zugegriffen werden kann. Es definiert sozusagen die 
Schnittstellen des canOpen Geräts.

MFG

Autor: Erol Sengül (supere)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: high-side (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey Erol,

Was für einen canOpen Master hast du?
Ich meine hast du die Nachrichtenfilterung selbst in der hand?

falls ja, kannst du auf die nachrichten natürlcih entsprechende 
reagieren.

ABER:
Identifier-Verteilung
Grundsätzlich werden bei der Kommunikation über CANopen Identifier mit 
11 Bit Länge
(Standard Frames) verwendet. Die somit zur Verfügung stehende Menge von 
möglichen
Identifiern ist durch das sogenannte Pre-defined Connection Set in 
diverse
Bereiche aufgeteilt. Die Identifier-Verteilung ist so ausgelegt, daß in 
einem CANopen-
Netzwerk maximal 128 Geräte vorhanden sind: ein NMT-Master und bis zu 
127 NMTSlaves.

Wenn deine IDs in einen dieser bereiche fällt bist du nicht mehr canOpen 
konform !!!

Cheers.

Autor: Erol Sengül (supere)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
high-side wrote:
> Hey Erol,
>
> Was für einen canOpen Master hast du?
Ich habe noch keinen CANopen Master. Wir haben momentan ein 
Kommunikationsbox (ComBox), dass als Schnittstelle zwischen Maschine und 
Peripherie fungiert. Diese soll dann so umprogrammiert werden, dass es 
als Master funktioniert.
> Ich meine hast du die Nachrichtenfilterung selbst in der hand?
> falls ja, kannst du auf die nachrichten natürlcih entsprechende
> reagieren.

Heißt das, dass ich mittels einer Nachrichtenfilterung auch unsere 
älteren Maschinen bedienen könnte?
Diese ANchrichtenfilter, gibt es die auch schon fertig, oder muss man 
die auch komplett selbst programmieren?
>
> ABER:
> Identifier-Verteilung
> Grundsätzlich werden bei der Kommunikation über CANopen Identifier mit
> 11 Bit Länge
> (Standard Frames) verwendet. Die somit zur Verfügung stehende Menge von
> möglichen
> Identifiern ist durch das sogenannte Pre-defined Connection Set in
> diverse
> Bereiche aufgeteilt. Die Identifier-Verteilung ist so ausgelegt, daß in
> einem CANopen-
> Netzwerk maximal 128 Geräte vorhanden sind: ein NMT-Master und bis zu
> 127 NMTSlaves.
>
> Wenn deine IDs in einen dieser bereiche fällt bist du nicht mehr canOpen
> konform !!!
>
Eben das ist mein Problem, teilweise gibt es überschneidungen zischen 
den alten IDs und den CANopen IDs. Wenn ich aber die IDs der alten 
Geräte umprogrammiere, dann könnte es doch gehen oder?

> Cheers.
Prosit

Autor: Blob! (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn Du den Master selbst im Griff hast, wäre doch das einfachste beim 
Anlauf einen Software-check auszuführen.

Du Frägst alle Geräte ab (oder hast sie statisch einprogrammiert) womit 
Du dann erfährst welches Gerät sich CiA-conform mit CANopen-Protokoll 
meldet und welche noch mit Eurem Firmeninternen CAN-Protokoll 
angesprochen werden müssen!


Kleiner Tipp: Geräte welche Normkonform sind senden im Einschaltmoment 
nach dem Hochlaufen eine Bootup-Message - kommt diese Nachricht weiß 
Dein Master dass er diese Node-ID mit CANopenprotokoll ansprechen muss, 
kommt sich nicht, muss der Master eben das alte Protokoll heran ziehen!

Ich würde darin eigentlich kein Problem sehen - das grösste Problem wird 
wohl sein, dass Du den ganzen Käse 2x programmieren musst: 1x CANopen 
und 1x Firmeninternes Protokoll. Aber auch das dürfte kein Problem sein 
wenn Deine Mastersoftware halbwegs modular aufgebaut ist! ;)

Autor: Erol Sengül (supere)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, ich bins mal wieder!
Ich suche Leute, die mir bei meiner Diplomarbeit behilflich sein 
könnten.
Ganz speziell Leute, die sich mit CANopen gut auskennen. Um was es da 
geht kann man dem Thread oben entnehmen.
Leider habe ich trotz vieler Recherchen immer noch immense Probleme. 
Ausserdem gibt es in der Firma, in der ich meine Diplomarbeit absolviere 
auch keine Zweibeiner, die mir behilflich sein könnten.
Somit steht meine Diplomarbeit auf der Kippe.
Nur vorab: Ich will meine Arbeit nicht einem aufdrücken und machen 
lassen!
Ich will es so weit wie möglich selber schaffen aber ohne Schützenhilfe 
komme ich leider nicht mehr weiter.
Also, wenn einer Interesse hat mir zu Helfen, der möge sich bitte bei 
mir melden. Selbstverständlich bin ich auch bereit, mit meinen 
bescheidenen Studentenmitteln finanzielle Belohnung zu entrichten.

Meine Email: esenguel (a) web.de

Viele Grüße
Erol

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Nun überlegen wir uns, auf CANopen umzusteigen und evtl. sogar Stacks zu
>erwerben, um den Programmierungsaufwand zu erleichtern.

Ach? Man kann einen Stack kaufen?

WIr programmieren die immer als FIFOs selbst... ;-)


>Also, wenn einer Interesse hat mir zu Helfen

Wenn es immer mal paar Fragen sind, kannst du die doch hier psoten.

Aber nicht vergessen, das Forum als Quelle anzugeben ;-)

Autor: Olaf Dreyer (Firma: O.D.I.S.) (dreyero)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Matthias,

ich würde ja einen Stack eher als LIFO implementieren ;-)

Gruß

Olaf

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da hast du natürlich Recht. Ich hab das auf die Schnelle mit den 
Schreib/Lesespeichern verwechselt...

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ach? Man kann einen Stack kaufen?
>WIr programmieren die immer als FIFOs selbst... ;-)

 natürlich ;) schau doch mal bei Port oder vector nach - ob sich das 
rechnet ist aber eine andere Frage. CAN ist jetzt nicht soo aufwendig 
als das man das nicht selbst machen könnte

Autor: Erol Sengül (supere)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey Jungs,
kommt doch wieder runter. Ich habe eine ernsthafte Frage gestellt und 
bekomm statt dessen nur "gespött".
Ich sage dazu nur eins:
Was du nicht selbst erleben willst, dass füge niemandem zu!

Ich hoffe, dass ihr die geistige Reife dafür habt!

MfG

Erol

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich wollte das am Anfang dieser Diskussion nicht in den Raum werfen, 
weil es ja offensichtlich doch einige Experten auf diesem Gebiet hier 
gibt, aber meiner Ansicht nach ist CANOpen ausgesprochen schwierig zu 
implementieren und keineswegs eine Erleichterung in der 
Softwareentwicklung. Wir haben in der Firma im Zuge einer Kundenanfrage 
das Thema zwar nur theoretisch betrachtet, sind aber zu dem Schluß 
gekommen, daß bei CAN nur ein proprietätes Protokoll vom Aufwand her 
vertretbar ist. Das Ende vom Lied war dann übrigens, daß die 
Entscheidung auf Modbus statt CAN fiel, und selbst Modbus-RTU hat ein 
paar Fallen für den Programmierer.

Autor: high-side (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das Problem an der Sache ist ja nicht ein "einfaches" CAN Protokoll zu 
implementieren. Das ist in etwa dasselbe wie sich selbst ein "sauberes" 
RS232 Protokoll zur Kommunikation mit dem PC zu schreiben.

Der entscheidende Punkt von CANopen ist die Standardisierung! Wenn dein 
Gerät CANopen konform ist kannst du beliebige Tools, welche CANopen 
unterstützen anschließen und dann diverese Diagnose Dienste ausführen.. 
Netzwerkmanagement testen... und das wohl entscheidenste du kannst die 
Umgebung simulieren in die dein Gerät später eingebettet werden soll...

Natürlich kann man das auch alles per Hand selbst programmieren, aber 
mit welchem Aufwand und dann ist die Frage ober der Aufwand von den 
Kosten / Entwicklung her gerechtetfertigt ist.

Genau dies ist der Grund warum Entwicklungsabteilungen fertige Stacks zu 
kaufen.
1.) weil sie getestet sind und funktionieren
2.) weil sie die Standards einhalten
3.) weil es Tools gibt mit denen man die Umgebung simulieren kann.

Ciao

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.