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
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!
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!
Ich würde CANopen nehmen. Allerdings ist der CAN-Controller im Atmel nur CAN, nicht CANopen. Also musst du das Protokoll selbst programmieren...
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
>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.
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)?
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.
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
>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.
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
>Die Größenordnungen hab ich mir aber noch nicht so wirklich überlegt.
Dann fang schnellstens damit an!
> 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/
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?
Hmm, scheint mit CANopen wohl ziemlich komplex oder sehr teuer zu werden!
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
@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/product_canopen_io_devices Gruß, subitus ------------------------------------------------- http://www.subitus.de -------------------------------------------------
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.