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.
CANopen ist ein ziemlich komplexes Thema. Ich selber habe mal mit dem Protokollstack von IXXAT zu tun gehabt...das ist schon harte Kost. Die Idee ist ja schon gut, aber man darf den Aufwand nicht unterschätzen.
Da CANopen auf CAN Layer 2 (native CAN) basiert hast du kein Problem auch weiterhin die alten Maschinen anzusprechen, da du den native CAN ja weiter nutzen kannst. Zu beachten ist das du eine saubere CAN Treiber-Schicht hinstellst, auf die der CANopen Stack aufsetzt. Hab leider nicht mehr Zeit noch was zu schreiben...später mehr Gruß CaH
Erol Sengül wrote: > Nun überlegen wir uns, auf CANopen umzusteigen und evtl. sogar Stacks zu > erwerben, um den Programmierungsaufwand zu erleichtern. Dazu müßte man erstmal wissen, was bei Deiner jetzigen Lösung schwer ist. In der Regel hat man bei Implementierung eines Protokollstandards einen wesentlich höheren Programmieraufwand um diesen Standard an seine spezifischen Anforderungen anzupassen. Auch soll so ein Standard ja viele Applikationen abdecken. Er enthält also viele Funktionen, die Du garnicht brauchst, quasi ne Menge toter Code. Bzw. Du wirst einige Funktionen bereitstellen müssen, weil sie zum Standard gehören, auch wenn Du sie nicht benutzt. Einen Standard zu implementieren lohnt sich eigentlich nur, wenn man Fremdgeräte mit in seine Anlage einbinden will, bzw. eigene Geräte in Fremdanlagen nach diesem Standard. Peter
Peter Dannegger wrote: > Erol Sengül wrote: >> Nun überlegen wir uns, auf CANopen umzusteigen und evtl. sogar Stacks zu >> erwerben, um den Programmierungsaufwand zu erleichtern. > > Dazu müßte man erstmal wissen, was bei Deiner jetzigen Lösung schwer > ist. Schwer ist es momentan eigentlich nicht, da hast du recht. Eigentlich ist es nur eine Zeitfrage. D.h. wir dachten uns, dass man mit einem Standard-Stack es leichter hätte, Änderungen am Prgramm durchzuführen oder bei neuen Produkten alles immer wieder neu zu schreiben. Mit dem Toten-Code, gebe ich dir auch recht. Für meinen Versuch ein Heartbeat, SDO und PDO zu senden und zu empfangen habe ich insgesamt 38 C-Files und doppelt so viele H-Files. Für weitere Meinungen und Erfahrungen bin ich immer noch Ohr. LG E.S.
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
Bitte 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.