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

[Knally]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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