# CANopen Signal wird von Steuerung nicht "genommen" (TIA Portal/ PN-CAN Link/ Igus D1)



## Knally (17 Februar 2020)

*CANopen Signal wird von Steuerung nicht "genommen" (TIA Portal/ PN-CAN Link/ Igus D1)*

Hallo,

ich möchte einen Schrittmotor via CAN (CANopen) steuern. Das ganze soll im "Profile Position" Modus erfolgen. Ich habe es geschafft via CAN-Bus die Steuerung in die Zustände Pre-Operational, Operational, Ready to Switch On (usw.) mittels des Controlwords zu bekommen. Dementsprechend bekomme ich auch die korrekten Statuswords als Antwort der Motorsteuerung an die SPS zurück.

Aus für mich unersichtlichen Gründen nimmt die Steuerung das Objekt 607A (Target Position) jedoch nicht entgegen, welches ich zur Vorgabe der Soll-Position der Motorsteuerung mitgeben muss. Demzufolge zeigt das Statusword auch immer "Target Reached" an. Und es lässt sich kein Fahrbefehl durch setzen des Bits 4 (und Bit 6 für eine relative Bewegung) starten. Da ich ja auch das Control- und Statusword richtig via PDO Mapping eingerichtet habe und ich da alles sinngemäß zurückbekomme, denke ich nicht, dass dies an meinem Mapping/Hardware Konfiguration liegt. Das Mapping habe ich so vorgenommen, wie es in der EDS der Motorsteuerung (Igus Dryve D1) default-seitig vorgegeben ist. Das Signal für die Target Position (607A) habe ich auch so auf dem CAN Bus mittels Analysetool. Sonstige Parameter für den Positioniermodus wie Profile Velocity, Acceleration usw... sind ebenfalls in der EDS Datei eingetragen. 

Woran könnte das liegen, dass die Steuerung die Target Position nicht "übernimmt"/ im OD abspeichert und infolgedessen auch kein Fahrbefehl mittels Controlword gesetzt werden kann?
Einen Fehler auf Seite der Hardwarekonfiguration/Mapping kann ich mir eigentlich nicht mehr vorstellen, da ja ich das jetzt schon mehrmals neu eingerichtet hatte.

Die Hardware ist mittels TIA Portal projektiert (TIA V 15.1)
Die Motorsteuerung Igus D1 zum Ansteuern eines Schrittmotors
Als Schnittstelle zwischen SPS (ET200SP 1512SP F-1 PN ) und der Motorsteuerung verwende ich den Siemens PN/CAN Link ( über den ich ja wie angesprochen Controlword usw. senden kann)

Die Target Position 607A sende ich mittels COB-ID 302 an die Steuerung ( vom Mapping her analog zu dem C-Word, nur statt Datentyp Unsigned 16 Bit halt eben wie vorgegeben Integer 32 Bit) Und im TIA Portal PDO Mapping habe ich als Übertragungsart "Applikationsspezifische Ereignissteuerung" mit Ereignistimer 0 ms/ Sperrzeit 0 ms eingestellt. (funktioniert ja auch beim c-Word)
Ich bin etwas ratlos, da es eigentlich so funktionieren müsste... Hatte da jemand auch schonmal Probleme bei Motorsteuerungen die mittels CAN angesteuert werden ?
Das geiche Problem hatte ich auch bei einer Nanotec Steuerung C5-E-1-09 (dort wird Target Position) ebenfalls nicht übernommen (Mapping Fehler kann ich hier ebenfalls bestreiten..)

Für Hilfe und Ratschläge bin ich überaus dankbar.


----------



## Senator42 (17 Februar 2020)

kannst du die "Target Position 607A" mit dem igus dryve schreiben und lesen. und vielleicht damit auch "fahren" ?
Das mapping kann man nur im pre-operational ändern. die mappingdaten sind ja auch wieder SDOs. sind die wirklich im controller?

den Fahrbefehl mittels Controlword, hier nimmst du auch die richtigen Bits, da ist ja auch LB und HB "vertauscht".

"Die Target Position 607A sende ich mittels COB-ID 302"   ist 302 ein PDO oder SDO?


----------



## Senator42 (17 Februar 2020)

> Das geiche Problem hatte ich auch bei einer Nanotec Steuerung C5-E-1-09  (dort wird Target Position) ebenfalls nicht übernommen (Mapping Fehler  kann ich hier ebenfalls bestreiten..)



und woran lag es dort?


----------



## JoopB (17 Februar 2020)

Letztes Jahr habe ich mit diesem Ignus driveD1 und einer S7 1215F CPU ein Projekt mit 2 Achsen (X und Y) gemacht. Die Motoren waren mit einem Inkrementalgeber ausgestattet. Für die maximale Bewegung wurden 2 induktive Näherungsschalter bereitgestellt, die direkt mit dem Antrieb verbunden waren.
Ich habe die Kommunikation über Modbus-TCP gemacht und die Stopps, Geschwindigkeit und Beschleunigung werden über den Bus weitergeleitet. Die aktuellen Positionen werden über den Bus von den Laufwerken gelesen. All dies ist nicht in Echtzeit, aber für diese Anwendung war das kein Problem. Ich habe anfangs einige Beispielprojekte von IGUS erhalten (1 Projekt mit 1 Achse und ein Projekt mit 3 Achsen). Ich habe einige Tests damit durchgeführt, aber mit einigen Anweisungen ist die Zykluszeit der SPS nicht viel zu lang. Nach einer guten Untersuchung des Programms stellte ich fest, dass zu einem bestimmten Zeitpunkt, als eine Antwort von dryveD erwartet wurde, eine Schleife im Programm vorhanden war, die erst endete, als die Antwort einging. Wenn das Laufwerk, z. Wenn keine Spannung vorhanden war oder das Ethernet-Kabel nicht angeschlossen war, wurde die SPS angehalten, da die Zykluszeit überschritten wurde. Ich habe dann einige Schritt-Programme mit einem CASE in SCL geschrieben, wobei ein bestimmter Schritt aktiv blieb, bis die Antwort von den DryveD (s) empfangen wurde. Die Zykluszeit der SPS bleibt nun 1-3 ms, während ich mit dem ursprünglichen Programm von IGUS-Peaks von mehr als 50 ms ein wenig mit den Einstellungen auf der Website des dryveD spielen musste. Der Schnellstopp erfolgt über einen DI7, der positive Endschalter steht auf DI8, der negative auf DI9 und der Freigabe auf DI10.


----------



## Knally (18 Februar 2020)

Hallo Senator und JoopB,

ich habe das Problem gefunden!

"kannst du die "Target Position 607A" mit dem igus dryve schreiben und lesen. und vielleicht damit auch "fahren" ?"
-  Die Target Position wird tatsaechlich richtig beschrieben ( habe ich  dann mittels Drittprogramm bei dem man "online" OD EintrÃ¤ge lesen kann,  gesehen. Im Web Browser des Igus Dryve wird die Soll-Position jedoch  erst nach Start des Fahrbefehls richtig aktualisiert ( = target  position). Ist halt etwas irreführend.

"Das mapping kann man nur  im pre-operational Ã¤ndern. die mappingdaten sind ja auch wieder SDOs.  sind die wirklich im controller?"
- Also Mapping ist tatsÃ¤chlich  nicht das Problem (ich habe mich da an die von mir im EDS File gesetzten  IDs gehalten bei der Konfig. im TIA. Problem ist aber, dass benötigte  Parameter für den Profile Position Mode nicht richtig initialisert  werden beim Laden der Hardwarekonfiguration/Starten CAN Manager. Das  betrifft sowohl die in der EDS file gesetzten Default werte als auch die  im TIA Portal unter "Neuer Eintrag" im OD des Igus eingestellten Werte.  Wenn ich nÃ¤mlich mittels dem Drittprogramm nach der Initialisierung die  ODs lese steht da weder der in der eds file gesetzte default wert noch  der "neue Eintrag". Da steht dann teilweise einfach 0 und damit löst der  Fahrbefehl nicht aus. Die für den PP Mode benötigten Parameter sind:

6081 Profile Vel.
6083 Profile Acc
6092.01 Feed Constant Feed
6092.02 Feed Constant Shaft Rev.

Die  sind auf jeden Fall nötig damit der Fahrbefehl gestartet werden kann (  ohne die Par. passiert gar nix, auch keine Error Meldung und sonstiges.)  Tricky an der Sache war eben, dass ich die ja sowohl als Default Wert  im EDS und in der TIA HW Konfig gesetzt hatte. Erschwerend kommt hinzu  dass die Parameter weg sind, wenn der Strom weg ist. (also SDO  Schreibzugriff ist bei der Initialisierung des CAN-Managers und der  Slaves irgendwie suboptimal was das korrekte Setzen der benötigten OD  Parameter angeht). Laut Support werden die Parameter mit den kommenden  Updates aber permanent gespeichert.
Ich gehe jetzt hin und mache ein  PDO Mapping für die Parameter, sodass ich bei jedem SPS Start die  Parameter dann mittels PDO einmalig setze. (frei von irgendwelchem SDO  und Hardwarekonfigs laden)

"den Fahrbefehl mittels Controlword, hier nimmst du auch die richtigen Bits, da ist ja auch LB und HB "vertauscht""
-  da muss man noch aufpassen dass man "relativ" fährt, wenn man vorher  kein Homing durchgeführt hat ( Bit 6 im ControlWord = 1, und zwar schon  vor dem eigentlichen Fahrbefehl) sonst reagiert der Motor auch nicht.

Für  mich interessant ist noch die Frage, ob die Parameter bei der  Initialisierung doch "sinngemäss" gesetzt werden können (nur was falsch  eingestellt ? andere Programme ?)

@JoopB
Zykluszeiten und Co.  konnte ich noch nicht nÃ¤her testen. Ich habe die Ãœbertragung jedenfalls  so eingerichtet, dass ich die Daten von der Steurung ( im Wesentlichen  Ist-Position/Geschwindigkeit) zyklisch bekomme und somit auf  Programmseite nicht in eine undefinierte Warteschleife gerate.

Viele Grüße 

Knally


----------



## Knally (18 Februar 2020)

Nachtrag:

in dem Moment wo ich bei dem PN/CAN Link von dem Zustand "Pre-Operational" (0000 0001) zu "Operational" (0000 0101) mittels Controlword wechsle, werden die OD Einträge 6081, 6083 und 6084 zu 0 gesetzt. (was nicht meinem Default Wert und auch nicht meinem eingetragenen Wert entspricht)


----------



## JoopB (19 Februar 2020)

Ich habe kein PN/CAN Link 
Ich habe keine PN / CAN-Verbindung verwendet, sondern kommuniziere direkt über TCP-Modbus.
  In OB1 wird mit dem TCON-Baustein eine Verbindung zu den Achsen hergestellt
Ich habe auch einen FB mit einem Case zum Senden der Befehle programmiert. Ich kann aus diesen Bausteinen keine Quele generieren, da sie sichere Bausteine enthalten. Ich habe jetzt meine FB in eine Textdatei gepackt, damit Sie sehen können, wie ich die Befehle an die Assen sende. Die Schrittnummer für eine bestimmte Bestellung wird in einem anderen FB über die INOUT Nr. Gesendet
In diesem anderen FB wird dann gewartet, bis diese Nummer wieder bei 0 ist, um einen weiteren Befehl zu geben.


Wenn Sie mir Ihre E-Mail-Adresse über eine PN geben, kann ich Ihnen das IGUS- und mein Programmbeispiel per E-Mail senden.
Gruss,
Joop


----------

