www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Profibus, CANopen, DeviceNet?


Autor: Vince (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich würde gerne einen Linearmotor ansteuern und mir stehen dabei die 
Protokolle Profibus, CANopen ODER DeviceNet zur Verfügung. Wollte mich 
mal so umhören für welches ihr euch entscheiden würdet. Die Ansteuerung 
sollte über einen Mikrocontroller realisiert werden. Könnte ich für 
CANopen und DeviceNet einen aus der AT90CAN-Reihe verwenden? Diese µCs 
besitzen ja schon einen integrierten CAN-Controller.

MfG,
Vince

Autor: Blob! (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
es kommt natürlich auch darauf an wo das Gerät steht und wie schnell die 
Übertragung stattfinden muss!

DeviceNet würde ich deswegen nicht nehmen, da es eher in Amerika 
verbreitet ist, dort ist es das Gegenstück zu unserem europäischen 
CANopen. Hier in D wirst Du vermutlich mehr Geräte und besseren support 
für CANopen bekommen.

also hast Du die Wahl zwischen CANopen und Profibus.

Profibus ist deutlich schneller in der Übertragung: nämlich bis zu 
12Mbit - CANopen wird meistens nur bis 1Mbit/s unterstützt - dafür 
benötigsts Du für Profibus wiederrum zusätzliche Hardware (z.B. einen 
profibuscontroller von siemens spc3).

Läuft Dein Motor in EMV-verseuchter gegend würde ich pers. lieber auf 
CANopen zurück greifen - CANopen ist ein kollisionsfreies und 
Verlustfreies protokoll - muss es schnell gehen und Dir ist 
Geschwindigkeit und Echtzeit wichtig, greif zu Profibus!

Autor: Blob! (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag:
Bei CANopen hast du übrigens viel mehr konfigurationsmöglichkeiten weil 
Du eben den controller bereits im µC hast - bei einem ext. 
Profibuscontroller sind die meisten parameter fest vorgegeben!

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde CANopen nehmen.

Allerdings ist der CAN-Controller im Atmel nur CAN, nicht CANopen.
Also musst du das Protokoll selbst programmieren...

Autor: Robert Teufel (robertteufel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias Lipinsky wrote:

> Allerdings ist der CAN-Controller im Atmel nur CAN, nicht CANopen.
> Also musst du das Protokoll selbst programmieren...

War mir gar nicht bekannt, dass es auch CAN-Controller mit integriertem 
Software Protokoll gibt!?

Urspruengliche Frage: es kommt primaer auf deinen moeglichen max. 
Datenverkehr an, welches groessere System du angehen moechtest (z.B. 
Peripherie fuer Siemens waere im SPS Bereich sicher mit Profibus gut 
bedient) und wie kritisch die Kosten sind. CAN ist insgesamt billiger zu 
implementieren, allerdings per Hardware auf 1 Mbit/s limitiert. Profibus 
hat hoehere Performance aber eben auch teurer.

Zwischen DeviceNet und CANopen wuerde ich im Europaeischen Raum CANopen 
und im Amerikanischen Raum DeviceNet einsetzen

Robert

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>War mir gar nicht bekannt, dass es auch CAN-Controller mit integriertem
>Software Protokoll gibt!?


So war das auch nicht gemeint.

Ich wollte nur darauf hinweisen, dass die COntroller alle CAN-Layer2 
sind, während CANopen Layer8 ist.

Autor: Vince (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke erstmal für die Antworten.
EMV spielt bei mir keine so große Rolle. Da ich praktisch nur einen 
Master und einen Slave habe, fällt Echtzeitfähigkeit auch eher unter den 
Tisch.

Die Protokollimplementierung ist wahrscheinlich das größte Problem, da 
ich mit sowas noch keine großen Erfahrungen gemacht habe.
Werde aber trotzdem mal mein Glück mit CANopen und einem AT90CAN 
versuchen. Könntet ihr da irgendwelche hilfreichen Quellen empfehlen 
(außer den CiA-Specs)?

Autor: ... ... (docean) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Blob! wrote:
> muss es schnell gehen und Dir ist
> Geschwindigkeit und Echtzeit wichtig, greif zu Profibus!

Da nimmt man lieber sowas wie ProfiNET, Sercos oder Ethercat!!

Das ist schnell und echtzeitfähig!

Dagegen ist Profibus einen lahme Schnecke.

Autor: Fabian B. (fabs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
CANopen ist ein ganz schöner Protokollbrocken. Muß es eines dieser 
Systeme sein? Du könntest (wenn CAN) auch dein eigenes, deutlich 
einfachereres Protokoll fahren, oder falls du noch nicht viel Erfahrung 
mit solchen Systemen hast, denk mal über was ganz anderes nach.
Wie weit sind Master und Slave räumlich getrennt? Gibt es Anforderungen 
an Geschwindigkeit, Reaktionszeit? Wie wird der Motor schlussendlich 
angesteuert (gibt es einen Slave-Controller)?

Gruß
Fabian

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Da ich praktisch nur einen Master und einen Slave habe, fällt
>Echtzeitfähigkeit auch eher unter den Tisch.

Dann verstehe ich nicht, warum Du überhaupt einen der angesprochenen 
Busse einsetzen willst. RS232/485 wäre viel einfacher handzuhaben.

Autor: Vince (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Motor besitzt eine integrierte Steuerungseinheit, die je nach Typ 
über eines dieser Protokolle angesprochen werden kann. Master und Slave 
sollen räumlich sehr eng miteinander verbunden werden. Die Reaktionszeit 
sollte schon einigermaßen hoch sein. Die Größenordnungen hab ich mir 
aber noch nicht so wirklich überlegt.
Gruß,
Vince

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Die Größenordnungen hab ich mir aber noch nicht so wirklich überlegt.

Dann fang schnellstens damit an!

Autor: NurEinGast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Werde aber trotzdem mal mein Glück mit CANopen und einem AT90CAN
> versuchen. Könntet ihr da irgendwelche hilfreichen Quellen empfehlen
> (außer den CiA-Specs)?

http://www.canfestival.org/

Autor: Vince (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mal ne doofe Frage: Was genau ist ein CANopen-Stack und was genau macht 
CanFestival?

Der Motor benutzt das DS402-Profil. Könnt ich sowas über CanFestival 
implementieren?

Autor: Vince (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm, scheint mit CANopen wohl ziemlich komplex oder sehr teuer zu 
werden!

Autor: H. Jeske (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du selber eine Ansteuerung mit einem Controller bauen willst, 
solltest du dich für CAN entscheiden.
Profibus, Profinet bekommst du in kurzer Zeit nicht entwickelt.
Wenn du einen CAN Bus zum Laufen bekommst auf dem Controller, kannst du 
einen CAN Open-Slave, der CAN Open mit PDO Mapping unterstützt relativ 
schnell ansprechen. Der minimale Protokoll Overhead ist fast NULL.
Du kannst bei CAN Open den Motor so einstellen (per ParametrierTool) , 
dass er Messages empfängt und sendet (die dein Controller versteht)
und ein paar kleine 2Byte NMT-Messages brauchst du noch (NodeStart)
Minimal brauchst du nur 3 Messages.
DeviceNet ist auch aufwendiger, da dies noch eine Connect-Procedur 
erfordert.

Wenn du weiter interssiert bist, kann ich dir eine gute Software zum 
Testen empfehlen.
email: Hardy.Jeske@dunkermotoren.com

Autor: subitus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Matthias Lipinsky

CAN-Layer 8? Was ist denn das? Wenn du ISO-11989/OSI meinst: Wow!
Den kenne ich noch garnicht. Zumal man vom 7-Schichtenmodell spricht. 
;-)

@NurEinGast
Ein brauchbarer (für private Zwecke kostenfreier) CANopen-Stack 
(MicroCANopen) gibt es von der Embedded Systems Academy 
(http://www.microcanopen.com/). Er hat diverse Einschränkungen (bspw. 
nicht 100% CANopen-kompatibel - was aber für Eigenentwicklungen nicht 
unbedingt störend ist). Allerdings fehlt dem Stack die 
NMT-Master-Funktionalität (Netzwerkmaster für An/Abmeldungen der 
CANopen-Knoten) - jedoch wird Autostart der Knoten unterstützt. Der 
Stack ist zudem gut dokumentiert und im Falle des AT90CANxxx binnnen 
kurzer Zeit lauffähig. Für die Implementierung eines CANopen-Slaves u.U. 
ausreichend.

Bezüglich CANfestival habe ich so meine Erfahrungen gesammelt:
- er läuft auf dem AT90CANxxx - jedoch nicht stabil
- kein AutoBaud und natürlich auch kein Auto-Fallback auf die vom 
CANopen-Standard vorgesehenen mandatorischen 20kBit
- eingeschränkte Features des Stacks (und zudem eine unbekannte 
Featureliste)
- Dokumentation ist sehr (sehr) sparsam
Insgesamt kann man feststellen, dass das CANfestival-Projekt 
(http://www.canfestival.org/) der Franzosen (LIVIC: 
http://www.inrets.fr/ur/livic/) eher schläft (letztes Codeupdate ist 
über 2 Jahre alt). Wer schnell fertig werden will, sollte von 
CanFestival die Finger lassen - wer der OpenSource-Welt dienen will ist 
dort gut aufgehoben.

Ich schließe mich Hardy Jeske voll an: Von allen aufgezählten 
Feldbussystemen wird CAN für dich die erste Wahl sein: CAN ist flott 
implementiert (ein paar Grundlagen sind natürlich nötig) und bietet dir 
den Komfort einer sehr sicheren Datenübertragung bei einer gleichzeitig 
großen Flexibilität -und das für sehr wenig Geld. Die notwendigen 
Entwicklunstools (z.B. ein CAN-Monitor) sind bezahlbar (wenige 100 
Euro); CAN-Libraries i.d.R. kostenfrei.

Hin und wieder fällt das Argument "Echtzeit" - meist in Zusammenhang mit 
der Busgeschwindigkeit (siehe Beitrag von Blob!). Dabei heisst Echtzeit 
nicht "schnellstmöglich", sondern deterministisch - ein 
Echtzeitverhalten ist also unabhängig von der Geschwindigkeit - 
lediglich die (selber) gesetzte Zeitschranke lässt einen 
Beurteilungsspielraum offen, etwas über die Echtzeitfähigkeit 
auszusagen. Und Profibus ist nicht "echtzeitfähiger" als der CAN-Bus. 
Für harte Echtzeitanforderungen sollte man sich TT-CAN (Time Triggered 
Controller Area Network) genauer anschauen.

Wenn du nur CANopen-Slaves implementieren willst, kannst du auch auf 
fertige CANopen-Umsetzer zurückgreifen, z.B. 
http://www.systec-electronic.com/html/index.pl/pro...


Gruß,

subitus


-------------------------------------------------
http://www.subitus.de
-------------------------------------------------

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.