MOVIDRIVE-Ansteuerung

Hi,

hat jemand schon mal nen MOVIDRIVE-Regler von SEW-Eurodrive aus LV heraus - insbesondere über CANopen - angesteuert?

Ich wäre für ein paar Anregungen/Beispiele dankbar...

Gruß
Achim

Anzeige

Habe ich noch nicht, aber unterscheidet sich das grundlegend von anderen Drives? Kann ich mir eigentlich nicht vorstellen, da doch speziell CANopen sehr genormt ist. Das ganze sollte doch mit dem Befehlssatz CiA (CAN in Automation, nicht, was ihr denkt) 402 zu machen sein...

Ich werde in den nächsten Tagen genau damit anfangen, wenn mein Controller endlich mal eintrifft. Der sollte schon längst da sein... Man könnte sich dann ja hier ein bisschen gegenseitig helfen.

Wie gesagt, ich nutze zwar einen Drive eines anderen Herstellers (Danaher Motion), aber das sollte sich grundlegend nicht unterscheiden.

Hast du überhaupt schonmal CANopen aus LV gemacht, oder brauchst du dafür bisschen Material?

' schrieb:Hast du überhaupt schonmal CANopen aus LV gemacht, oder brauchst du dafür bisschen Material?

NEIN und JAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA!

Das wär'n Ding...

Das Endergebnis werde ich wohl nur anwenden, mein Kollege soll sich damit befassen und mir dann "ready-to-use"- VI's geben, aber es brennt...

Ich bin aber total unbedarft was CANopen angeht. Ich hab heut mal die NI CANopen-Lib installiert und auch meine CAN-Karte PXI-8461 hab ich installiert...aber das war's auch schon. Wenn du Beispiele oder Tutorials hättest, wo man sich mal einlesen kann, wär das super! Ich habe nämlich mächtig Schwierigkeiten mit den Begrifflichkeiten und auch wie man vorgeht, um die Karte zu konfigurieren...

Gruß
Achim

Ist ja schonmal sehr gut, dass du die CANopen-Lib hast. Andernfalls wäre es aufwändig geworden...

Keine Sorge, ich habe auch erstmal eine Weile gebraucht, bis ich mit den ganzen Begriffen klar gekommen bin.
Ich habe eigentlich sehr sehr viel dazu im Internet gefunden. Anfangen bei Wikipedia bis hin zu irgendwelchen Uni-Seiten. Leider habe ich das meiste nur ausgedruckt, nicht gespeichert. Im Anhang findest du aber erstmal ein sehr gutes PDF (Adressräume) zum Themen-Einstieg. Das hat mir immens weitergeholfen.

Weiterhin solltest du (nachdem die Begriffe klar sind) einen Blick auf die Examples der CANopen-Lib werfen. Die sind wirklich sehr gut. Da wird alles einzeln erklärt. Als Ergänzung dann mein VI im Anhang, wo alle Einzelkomponenten, die man so brauchen könnte, verhanden sind. Es handelt sich dabei nur im die Kommunikation mit einem Temperatursensor (also 5 Stufen niedriger als ein Driver), aber das Prinzip von CANopen ist überall gleich. Nur die Anzahl der erforderlichen Kommandos ändert sich.

Als Kurz-Einstieg:
CANopen basiert auf zwei verschiedenen Kommunikationsobjekten: PDOs (Process Data Objects) und SDOs (Service Data Objects). PDOs werden eigentlich nur verwendet, um Messdaten und Kommandos zu verschicken. Also Dinge, die viel Platz benötigen und schnell gehen müssen. SDOs dienen der Konfiguration des Remote Node. Beide Objekte besitzen einen (unterschiedlich großen) Datenkopf mit Adressen, Pointer auf Einstellungen (Objektverzeichniseinträge genannt) usw. und einen Datenkörper, der die Nutzdaten enthält.
Weiterhin gibt es noch Emergency-Objekte (zur Fehlerübertragung), Sync-Objekte (zur Synchronisation) und Network Management Objekte (um RemoteNodes zu starten, stoppen usw.), die aber letztlich wieder SDOs sind.
Die NodeID ist die Nummer des RemoteNodes im CAN-Netzwerk (0 bis 127). Typischerweise wählt man 1 für nur einen Client.
COB-ID ist eine Nummer, die jedem Kommunikationsobjekt in den Datenkopf geschrieben wird. Sie legt die Bedeutung der Nachricht fest (ist es nun die Solldrehzahl, das Herstellungsdatum oder ein Synchronisationspuls) und ist gleichzeitig wichtig für die Priorität. Je kleiner diese Nummer, desto höher die Priorität der Nachricht. Wenn mehrere Nachrichten gleichzeitig in das Netzwerk geschickt werden, wird zuerst die weitergeleitet, die die höchste Priorität hat. Die anderen werden nach einem kurzen Delay erneut gesendet... Eben so lange, bis alle Objekte übermittelt wurden.
Das Objektverzeichnis ist jedem CAN-Gerät eigen, aber größtenteils durch CiA genormt (daher die Aussage, dass es keinen großen Unterschied macht, ober SEW oder Danaher Motion). Es enthält alle möglichen COB-IDs und ihre Bedeutung, die von diesem Gerät unterstützt werden.

Sehr gute Beschreibung ist auch in meinem Manual zum Drive enthalten. Siehe angefügtes PDF (Kommunikationsprofil). Dort hauptsächlich Kapitel 3, was sich mit den Grundlagen von CANopen beschäftigt. Alles ab Kapitel 4 solltest du aber auch zu deinem Drive dazu bekommen haben.



  Temperature_Sensor.vi (Größe: 88,74 KB / Downloads: 645)
(VI LV 8.5)

  CANopen_CiA_402_Adressr_ume.pdf (Größe: 561,8 KB / Downloads: 2392)


  S400_S600_CANopen_Kommunikationsprofil.pdf (Größe: 1,12 MB / Downloads: 1998)

Besten Dank erstmal...

Da machen wir uns mal drüber *grins*

Feedback kommt, kann aber dauern...hab hier mehrerererere Baustellen...

A.

Kenne das. Hundert Aufgaben und alles soll gleichzeitig und so schnell wie möglich fertig sein;)Dabei ist CAN ein eigenes Feld und kann einen ewig beschäftigen. Umso schwieriger, wenn man das "schnell mal eben" hinbekommen muss...

Anzeige

Habe aktuell ein ähnliches Problem. Bei mir geht es darum zwei Movidrives über Modbus anzusprechen.

Hat hier vielleicht schon jemand ein kleines Bedien-Vi dafür geschrieben?

In Hoffnung... ein blutiger Anfänger

Auch noch über Modbus...

Nur ein Tipp:
Verwende das IPOS des Reglers! Das ist die schönste und einfachste Sache (im Gegensatz zu den meisten Mitbewerbern von SEW). Dann musst Du nur die relevanten Zahlen "Rüberschaufeln" und im IPOS Programm schreibst Du dann die Routinen z.B. für Positionierungen etc!

Gruß!

' schrieb:Verwende das IPOS des Reglers! Das ist die schönste und einfachste Sache (im Gegensatz zu den meisten Mitbewerbern von SEW). Dann musst Du nur die relevanten Zahlen "Rüberschaufeln" und im IPOS Programm schreibst Du dann die Routinen z.B. für Positionierungen etc!

Das machen wir auch! Hat sich als sehr komfortabel herausgestellt, und auch der SEW-Mann der zur Inbetriebnahme bei uns wahr hat das empfohlen!

Jetzt aber mal ne Frage zur CANopen-Kommunikation. Wir haben das (SEHR mühsam!) hingekriegt und machen das prinzipiell so:

1. Programmstart: Init (Erzeugen Interface Object, Erzeugen + Starten Synch Object, Erzeugen PDO)
2. Programm läuft: Lesen/Schreiben PDO
3. Programmende: Aufräumen (Stop + Close Objects, Stop + Reset Node)

Siehe folgende Screenshots:

           

Wenn sich jetzt aber aus irgendeinem Grund meine Applikation aufhängt (z.B. wegen einem noch nicht abgefangenen Fehler...das kommt zur Entwicklungszeit ja schon mal vor...), wird evtl. der Punkt "Aufräumen" nicht ausgeführt. Wenn ich die CANopen-Kommunikation dann mit dem nächsten Programmstart ebenfalls wieder starten will, hängt sich die Karte bzw. die Kommunikation auf. Mir bleibt dann nur ein Rechner-Neustart...und das NERVT!


Gibt es evtl. irgendwo ne Funktion, mit der ich die Karte komplett zurücksetzen kann, so dass sie quasi "jungfräulich" ist? Auf der CANopen-Palette bzw. auch auf der CAN-Palette ist da nix zu finden...

Gruß
Achim

Hehe, siehe da... Gut zu wissen, dass es anderen auch noch so geht. Habe das ebenfalls durch. Wir hatten auch Vertreter von NI + Technical Support im Haus, die wurden auch gleich damit genervt - du wussten ebenfalls nicht weiter.

Ich weiß nur soviel: "CANopen Close" reicht zum Beenden. Einfach ein solches VI an die Referenz hängen, die du mit "CANopen Interface Create" erstellst. Du brauchst weder ein Close für alle Objekte, noch ein Beenden-VI für z.B. Sync-Pulse... Damit kannst du den ganzen Case streichen. Hänge einfach ein CANopen Close HINTER deine State-Machine, so dass es immer am Ende ausgeführt wird. Damit konnte ich das Problem beheben. Einzige Einschränkung: Du solltest das Prog nicht über den Stop-Button in der Symbolleiste beenden, sondern immer schön bis zum Ende ausführen. Und evtl. kann es sein, dass du den Error-In nicht an "CANopen Close" anschließen darfst. Ich glaube mich nämlich zu erinnern, dass das VI nicht seine Aufgabe erfüllt, wenn ein Error in der Leitung hängt - auch, wenn der Error intern nur durchgeschliffen wird... Wieso auch immer