Hallo Forum,
ich bin momentan dabei einen Motor-Controller, der (laut Manual...) das
CANopen "Drives and Motion Control Profile (DSP402)" implementiert, mit
einem Mikrocontroller anzusteuern. Nach länglicher Literaturstudie
glaube ich das CANopen System verstanden zu haben. Der Controller hat
die Node ID 1.
Ich habe ihn zunächst mit einem gekauften USB-CAN Interface verbunden
(1MBaud/Sec [=Default vom Controller], beide Seiten 120Ω terminiert),
und sehe sofort die regelmäßige Übermittlung des SYNC Frames (Leere
Nachricht auf CAN-ID 0x80), des Hearbeat Frames mit dem State code
5="Operational" (Nachricht mit Inhalt 5 auf CAN-ID 0x701), und einer
Reihe vermutlich herstellerspezifischer undokumentierter Frames
(möglicherweise für eine Art Auto-Discovery für andere Geräte dieses
Herstellers).
Um nun irgendetwas am Controller konfigurieren zu können, muss ich ja
über SDOs eine Kommunikation aufbauen. Zunächst wollte ich einfach den
Device Type, 0x1000 im Object Dictionary, auslesen. Und leider scheitert
es direkt daran:
Ich sende eine Nachricht "0x80 0x10 0x00 0x00 0x00 0x00 0x00 0x00" auf
CAN-ID 0x601 (= Server-SDO vom Node 1) für "Initiate SDO Upload". Der
Controller gibt dabei ein ACK ab, d.h. setzt dominanten Pegel im ACK-Bit
des Telegramms, d.h. sein CAN-Modul muss die Nachricht korrekt erhalten
haben. Leider war das schon alles - es gibt keinerlei Reaktion darauf,
keine "Initiate SDO Upload Response" und kein Error Frame.
Ich hatte nun vermutet dass man den Controller evtl. zuerst in den
Preoperational State setzen muss, damit er ansprechbar wird, und habe
dazu eine Module Control NMT Service Nachricht gesendet, d.h. "0x80
0x01" auf CAN-ID 0, aber ohne Erfolg - der Controller sendet weiterhin
über den Hearbeat, dass er im Status 5="Operational" ist.
Da ich ja den u.a. SYNC vom Controller sehe und dieser auch meine
Nachrichten ACK't denke ich dass die CAN-Kommunikation an sich
funktioniert, und es nur am Inhalt selber hapert...
Die "HOWTO"-Instruktionen im Manual fangen direkt an mit "konfigurieren
sie Objekt ID sowieso auf dies und jenes" - aber das bekomme ich ja
schon nicht hin...
Vermutlich habe ich irgendetwas in der CANopen-Spezifikation übersehen,
dass man vorher irgendetwas anderes senden muss bevor man über SDOs
kommunizieren kann - nur was? Weiß jemand was da noch fehlt?
Dein Tool sollte SDO-Kommunikation beherschen(SDO zu Fuß emulieren ist
nicht so trivial)
Für den Start kannst wahrscheinlich die Endstufe auch über PDOs
einschalten, was deutlich einfacher geht nur mit rohe CAN-Frames
Hi,
SDO Kommunikation funktioniert nur in Preoperational. Also mit NMT auf
Preoperational setzen.
Lesen des Modultyps Objekt 0x1000 mit 0x40 nicht mit 0x80. 0x80 wäre ein
SDO Abbruch.
Lies noch mal die CANOpen spec durch.
Gruß,
Schorschi.
Schorchi schrieb:> SDO Kommunikation funktioniert nur in Preoperational.
Nö.
> Lies noch mal die CANOpen spec durch.
Wäre eine Idee:
NMT state Operational --> Object dictionary access via SDO is possible.
Ansonsten 0x40 für den Request und den Object Index LSB first, also
"0x40 0x00 0x10..."
Hi,
ja es kommt auf die SDO-Kommunikation drauf an.
Der Standardheader kann auch im Operational gelesen werden.
Aber eine Konfiguration sollte nur in Preoperational durchführbar sein.
Außer es ist eine gewollte Funktionsweise.
"0x40 0x00 0x10..." passt.
Gruß,
Schorschi.
Peter Z. schrieb:> Hallo, bist du sicher das du beim Object Dictionary erst das MSB senden> musst? Probier es mal anders rum... 0x00 und dann 0x10
Sicher nicht, aber ich meine irgendwo im Standard stand das so.
Alex schrieb:> Dein Tool sollte SDO-Kommunikation beherschen(SDO zu Fuß emulieren ist> nicht so trivial)
Eventuell könnte ich an das CANopen Plugin des Tools rankommen. Der
Mikrocontroller muss es dann aber eh auch können... Den Programmteil
zur SDO-Kommunikation habe ich schon fertig, nur dass er nicht
funktioniert ;-)
> Für den Start kannst wahrscheinlich die Endstufe auch über PDOs> einschalten, was deutlich einfacher geht nur mit rohe CAN-Frames
Leider nein, da die PDO's per Default-Config nicht auf die dazu
notwendigen Objects gemappt sind; außerdem muss man eine ganze Reihe
Parameter einstellen, die sich gar nicht alle auf PDO's mappen lassen.
Schorchi schrieb:> SDO Kommunikation funktioniert nur in Preoperational. Also mit NMT auf> Preoperational setzen.Syliosha schrieb:> Man sollte den State auf Pre-Operational setzen. Da im Operational> Zustand, SDO nur möglich sind. Sie können genauso gut ignoriert werden.
Laut Standard (S. 66, Kapitel 5.3.2.2.3) sollte SDO auch im Operational
funktionieren. Aber wie gesagt, das hatte ich ja schon probiert, und das
Gerät ignoriert ja auch die NMT Anfragen zum State ändern...
> Lesen des Modultyps Objekt 0x1000 mit 0x40 nicht mit 0x80. 0x80 wäre ein> SDO Abbruch.
Oohps, der CCS ist 3 ja Bits... Das ist schonmal ein guter Tip :-)
> Lies noch mal die CANOpen spec durch.
Wenn sie lesbare wäre. ...
Schorchi schrieb:> Aber eine Konfiguration sollte nur in Preoperational durchführbar sein.
Macht Sinn. Allerdings schon komisch dass der Controller direkt im
Operational loslegt...
Schorchi schrieb:> "0x40 0x00 0x10..." passt.
Okay vielen Dank, das werde ich dann mal so probieren :-)
Du könntest dir auch mal die Implementierung in canfestival ansehen, als
Anregung. Ist keine tolle Implementierung, aber es funktioniert:
http://dev.automforge.net/CanFestival-3/file
die Dateien src/sdo.c und include/sdo.h
Syliosha schrieb:> Man sollte den State auf Pre-Operational setzen. Da im Operational> Zustand, SDO nur möglich sind. Sie können genauso gut ignoriert werden.
Das wäre dann kein Standard konformes Gerät.
SDO muss im PREOP und OPERATIONAL gehen, nur nicht im STOPPED,
dem dritten 'Standard' Kommunikationszustand eines CANopen Knotens.
Ja, CANopen überträgt mehrbyte Daten wie den Index ( 2 Byte) im little
endian format, low- dann high-byte.
Es ist mühselig im Standard die richtigen Kommandobytes für ein initate
SDO Kommando zu suchen. Es gibt auch Demo Versionen von CANopen
konfigurationstools die zumindest solche einfachen Kommndos durchführen
lassen.
Heinz
So, ich konnte jetzt wieder mit dem Controller weiterarbeiten, und
tatsächlich funktioniert es mit den richtigen Kommando-Bytes (0x40).
Dass so ein kleiner Verzähler so viel Arbeit generiert... Und in der Tat
funktioniert das auch im OPERATIONAL Mode. Vielen Dank für die Hilfe...
:-)
Hi,
ist schon etwas ungewöhnlich, wie dein Antrieb sich verhält.
Du schriebst, er sendet Sync. Im allgemeinen machen dies die Master.
Du schriebst, er reagiert nicht auf NMT Kommandos. Auch dies gilt häufig
für die NMT Master.
Ich fände es etwas merkwürdig, dass der Antrieb ein Master ist. Doch das
würde das Verhalten erklären. Für deine weiteren Experimente würde ich
aber schauen, wie ich den Antrieb in den Slave mode bekomme. Du willst
ja das Netzwerk steuern. Geht bestimmt, da es eigentlich der Normalfall
ist.
Anm: Als Master wäre es dann auch wieder Standardkonform, dass er im
OPERATIONAL ist.
Desweiteren sind bei 402 Geräten eigentlich die PDOs so eingestellt, das
was geht.
Mich würde aber mal interessieren, was für ein Antrieb dies ist?
bye
Steffen
