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.
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
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
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.
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
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! ;)
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
>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 ;-)
Hallo Matthias, ich würde ja einen Stack eher als LIFO implementieren ;-) Gruß Olaf
Da hast du natürlich Recht. Ich hab das auf die Schnelle mit den Schreib/Lesespeichern verwechselt...
>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
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
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.
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
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.