TIA Umsetzung Nockensteuerung mit S7-1500 (vergleichbar mit FM352)

Hallo,

ich bin auf der suche nach jemanden der praktische Erfahrung mit der Projektierung einer Nockensteuerung mit TIA hat, am besten in Verbindung mit Technologieobjekten. Allgemein gesagt, hapert es derzeit bei mir an der der Projektierung einer Nocke die zetilich unabhängig vom OB MC-Servo ist (die Ansteuerungszeit soll <0,3ms sein). Zum Einlesen der Sensorik (Drehgeber) und Ansteuerung der Aktoren kommen Technolgierkarten zum Einsatz
Ich möchte nicht von beginn an einen riesen Text verfassen den sowie so keiner lesen mag, dass Problem würde ich beschreiben wenn sich hier jemand findet.

vorweg schonmal ein paar grobe Information:
Hardware:
CPU: 1513F-1 PN - 6ES7 513-1FL01-0AB0
Technolgiekarte zum Einlesen eines Drehgebers: TM PosInput 2 - 6ES7 551-1AB00-0AB0
Technolgiekarte zum Ansteuerng der Aktoren: TM Timer DIDQ 16x24V - 6ES7 552-1AA00-0AB0

Software
Tia v14 upd2

Hallo,
die Zykluszeit des MC-Servo spielt hier eine untergeordnete Rolle, weil die CPU der TDQ nicht wie üblich dann das Schaltsignal sendet, wenn geschaltet werden soll, sondern bereits vorher zusammen mit der Information, wann geschaltet werden soll. Dadurch sind Schaltgenauigkeiten im µs Bereich möglich.
Die Baugruppen (TM xx) müssen taktsynchron angesteuert werden, was bedeutet, dass Du sie nicht im Zentralrack verwenden kannst, sondern dezentral hinter einer IM155-5PN HF (es reicht auch eine IM155-5PN ST) betreiben musst.
Für die Einstellung der Taktsynchronität schau hier: https://support.industry.siemens.com/cs/ww/de/view/109480489
Du solltest die TOs OutputCam für einen einzelnen Nocken oder CamTrack für mehrere Nocken (Nockenspur) verwenden.
Bei der Parametrierung des TM PosInput 2 musst Du "Verwendung mit Motion Control" verwenden, damit Du die Baugruppe mit dem TO verwenden kannst.

mfG
Dirk

Super Einstieg, vielen vielen dank !!!

Zum Thema Taktsynchronität .... ich hatte mir heute, in der Firma, ein kleines Testprojekt gebastelt, was ich mangels Hardware nur auf PLCSIM laufen lassen kann. Ganz grob habe ich folgendes zusammgeschustert:

Hardwarekonfig:
ich habe eine Syncdomaine angelegt und die Baugruppen "TM Timer DI/DQ" sowie die "TM PosInput2" auf einer ET200MP HF platziert und bei beiden Baugruppen den Haken Taktsynchronität gesetzt (Prozessabbild Ob MC Servo).

Technolgieobjekte:
TO_ExternalEncoder - Rundachse / Modulo 0-360° / ein Winkelgeber wird mittels SSI eineglesen
TO_Nocke - Wegnocke

Bausteine:
MC_Reset - zur TO Quittierung
MC_Power - zur Freigabe des TO_ExternalEncoder
MC_Home - zur Referenzierung des Winkelgebers
MC_OutputCam - zur Übergabe des Nockenweges und der Nockenfreigabe


Leider musste ich feststellen, dass ein frisch aufgesetztes Projekt läuft, die Technologieobjekte TO_Nocke + TO_Encoder waren Störungsfrei bis zu den Zeitpunkt als ich eine Nocke aus einen anderen Projekt eingefügt hatte (copy + paste). Nach dem Übertragen waren alle Nocken-Technolgieobjekte gestört mit der Meldung - Fehler 113: Taktsynchroner Betrieb nicht möglich - (das TO_Encoder war Störungsfrei). Eine weitere Beschreibung im Handbuch hilft auch nicht weiter, dort heißt es:
•Der konfigurierte Ausgang am Technologieobjekt
Nocken, Nockenspur bzw. der Eingang am
Technologieobjekt Messtaster kann nicht
taktsynchron verwendet werden.
Konfigurieren Sie die Peripherie in der
Gerätekonfiguration taktsynchron.
• Stellen Sie sicher, dass der Organisationsbaustein
MC_Servo [OB91] synchron zum Bussystem
aufgerufen wird.
Der MC-Servo lief, glaube ich, mit den Faktor 4 zum Domain-Bus und der Ausgang sollte auch richtig konfiguriert gewesen sein, da vor dem Einfügen der anderen Nocke keine Störung anstand ! Ich hab versucht den Fehler mit den MC_RESET (Parameter RESTART auf true) zu quittieren, leider ohne Erfolg, hast du vielleicht eine Idee was ich falsch mache ?

Außerdem hätte ich noch ein paar allgemeine Fragen zum besseren Verständniss:
-Du schreibst: "die Zykluszeit des MC-Servo spielt hier eine untergeordnete Rolle, weil die CPU der TDQ nicht wie üblich dann das Schaltsignal sendet, wenn geschaltet werden soll, sondern bereits vorher zusammen mit der Information, wann geschaltet werden soll. Dadurch sind Schaltgenauigkeiten im µs Bereich möglich", wie sieht es denn mit der Nockenlänge aus ? Kann ich davon ausgehen das Diese unabhängig vom MC-Servo Applikationszyklus ist ? Und kannst du sagen wo ca. die Minimalgrenze liegt ?

-Benötige ich eigentlich irgendwelche Funktionen aus der Time-based-IO Bibliothek, wie z.B. TIO_Sync ? Im Handbuch zur TM Timer DI/DQ wird recht oberflächlich auf Time-based-IO verwiesen.


PS: der Download in deinem Link ist leider down

Hallo Lockenfrosch,

ich habe mich vor 6 Wochen mit den gleichen Aufgabenstellung beschäftigt.

Da der Technologiebaustein „Nockensteuerung“ nur mit einem dezentralen Aufbau geht und zusätzlich noch erheblich Rechenzeit benötigt, habe ich mich für eine abgespeckte Lösung im Eigenbau entschieden.

Die „TM PosInput 2“ besitzt ja zwei Digitalausgänge die man auf einen Vergleichswert programmieren kann. Damit kann man auch im zentralen Rack ein Nockensteuerwerk realisieren.

Für meine Anwendung (Kamera für 8 Bilder pro Taktung eines Rundschalttellers) brauch ich nur die Flanke des Ausgangs. Mein min. Abstand zwischen zwei Nocken beträgt 15ms. In dieser Zeit lade ich den nächsten Vergleichswert für den Nocken (Zeitgesteuerter OB).
Als Geber benutzte ich ein SSI-Multiturn Geber.

Ich nehme an das mit der Ansteuerungszeit <0,3ms du die Wiederholgenauigkeit gemeint hast.
Diese wird auf jeden Fall, auch bei einer stark ungleichmäßigen Bewegung eingehalten.

Beim Technologiebaustein wird ja der Schaltpunkt über die Geschwindigkeit in der Zukunft berechnet was bei ungleichmäßigen Bewegungen zu einen Versatz führen kann.

Wenn das ein Zeitnocken mit der Länge von 0,3ms sein sollte, kann man über einen Zeitinterrupt auch diesen nachbilden.

Vielleicht kann dir dieser Lösungsansatz als Denkanstoß dienen.

Ein schönes Wochenende
Harald

Anhang anzeigen 109480489_FAQ_Isochrone_Mode_de.pdf

Lockenfrosch schrieb:

..., was ich mangels Hardware nur auf PLCSIM laufen lassen kann.

Zum Vergrößern anklicken....

Ob die PLCSIM taktsynchron arbeiten kann, weiss ich nicht, tendiere aber eher zu nein. Ich habe immer nur mit echter Hardware gearbeitet.

Lockenfrosch schrieb:

Leider musste ich feststellen, dass ein frisch aufgesetztes Projekt läuft, die Technologieobjekte TO_Nocke + TO_Encoder waren Störungsfrei bis zu den Zeitpunkt als ich eine Nocke aus einen anderen Projekt eingefügt hatte (copy + paste). Nach dem Übertragen waren alle Nocken-Technolgieobjekte gestört mit der Meldung - Fehler 113: Taktsynchroner Betrieb nicht möglich - (das TO_Encoder war Störungsfrei).

Zum Vergrößern anklicken....

Die einzige Idee, die mir da kommt, ist dass die kopierten Technologieobjekte eine andere Version als die bereits eingefügten haben (abgesehen davon, ob die PLCSIM das überhaupt kann)
Am besten löscht Du die TOs und Du fügst die TOs alle neu ein (kein Kopieren).

Lockenfrosch schrieb:

Außerdem hätte ich noch ein paar allgemeine Fragen zum besseren Verständniss:
-Du schreibst: "die Zykluszeit des MC-Servo spielt hier eine untergeordnete Rolle, weil die CPU der TDQ nicht wie üblich dann das Schaltsignal sendet, wenn geschaltet werden soll, sondern bereits vorher zusammen mit der Information, wann geschaltet werden soll. Dadurch sind Schaltgenauigkeiten im µs Bereich möglich", wie sieht es denn mit der Nockenlänge aus ? Kann ich davon ausgehen das diese unabhängig vom MC-Servo Applikationszyklus ist ? Und kannst du sagen wo ca. die Minimalgrenze liegt ?

Zum Vergrößern anklicken....

Die TDQ kann pro PROFINET-Zyklus zweimal schalten. Damit müssen Schaltzeiten bis hinunter zu 10µs möglich sein, das hängt aber auch von deiner Last ab, die muss auch so schnell reagieren können. Wenn Du 4 ms Buszykluszeit hast, kannst Du innerhalb der ersten ms ein und ausschalten, danach geht dann aber 3 ms nicht mehr, weil die Baugruppe erst im nächsten Buszyklus neue Schaltaufträge bekommen kann. Da aber das TO nur im MC_Servo-Takt arbeitet, musst Du eine Untersetzung auch noch einrechnen.

Lockenfrosch schrieb:

Benötige ich eigentlich irgendwelche Funktionen aus der Time-based-IO Bibliothek, wie z.B. TIO_Sync ? Im Handbuch zur TM Timer DI/DQ wird recht oberflächlich auf Time-based-IO verwiesen.

Zum Vergrößern anklicken....

Die Funktionen aus der Time-based IO Lib braucht man nur, wenn man selbst zeitgesteuerte Applikationen macht, das TO nimmt das dem Anwender komplett ab.

Lockenfrosch schrieb:

PS: der Download in deinem Link ist leider down

Zum Vergrößern anklicken....

Habe den Fehler gemeldet...und die Doku hier angehängt Anhang anzeigen 109480489_FAQ_Isochrone_Mode_de.pdf

mfG und schönes WE
Dirk

@Funky

Danke, interessante Alternative.

miami schrieb:

Die einzige Idee, die mir da kommt, ist dass die kopierten Technologieobjekte eine andere Version als die bereits eingefügten haben (abgesehen davon, ob die PLCSIM das überhaupt kann)
Am besten löscht Du die TOs und Du fügst die TOs alle neu ein (kein Kopieren).
Dirk

Zum Vergrößern anklicken....

Wahrscheinlich wird es an PLCSIM in Verbindung mit der TM Timer DI/DQ liegen, da ein konventioneller Ausgang mit Taktsynchronität funktioniert.

miami schrieb:

Die TDQ kann pro PROFINET-Zyklus zweimal schalten. Damit müssen Schaltzeiten bis hinunter zu 10µs möglich sein, das hängt aber auch von deiner Last ab, die muss auch so schnell reagieren können. Wenn Du 4 ms Buszykluszeit hast, kannst Du innerhalb der ersten ms ein und ausschalten, danach geht dann aber 3 ms nicht mehr, weil die Baugruppe erst im nächsten Buszyklus neue Schaltaufträge bekommen kann. Da aber das TO nur im MC_Servo-Takt arbeitet, musst Du eine Untersetzung auch noch einrechnen.
Dirk

Zum Vergrößern anklicken....

Wenn ich dich richtig verstehe beschreibst du die Schaltfrequenz bzw. die Schaltlänge wenn mit einen normalen Ausgang gearbeitet wird !?! Für mich wäre die Länge bei Verwendung mit einer TM Timer DI/DQ interessant. Ist es nicht so, dass diese Karte einen Zeitstempel für den ein und Ausschaltpunkt mitbekommt und dementsprechend den Aktor ansteuert und so kurze Zeiten realisierbar sind ?
Von meinen bisherigen Verständniss her beeinflusst der Applikationzyklus mehr oder weniger die Genauigkeit des Ein-/ Ausschaltzeitpunktes, da x-Zyklen (3?) vor der eingentlich Ansteuerung die Punkte berechnet werden. Bei konstanter Maschinengeschwindigkeit ist der Einfluss des Zykluses egal und gewinnt mit immer größer werdenden Schwankungen mehr Relevanz. So stelle ich mir zumindest das Systemverhalten vor, aber ob ich richtig liege... ?
Wie geanu der Buszyklus auf das Konstrukt wirkt ist mir noch relativ unklar.

miami schrieb:

die Doku hier angehängt Anhang anzeigen 35803
Dirk

Zum Vergrößern anklicken....

Danke !!!

Lockenfrosch schrieb:

Ist es nicht so, dass diese Karte einen Zeitstempel für den ein und Ausschaltpunkt mitbekommt und dementsprechend den Aktor ansteuert und so kurze Zeiten realisierbar sind ?

Zum Vergrößern anklicken....

genau so ist es

Lockenfrosch schrieb:

Von meinen bisherigen Verständniss her beeinflusst der Applikationzyklus mehr oder weniger die Genauigkeit des Ein-/ Ausschaltzeitpunktes, da x-Zyklen (3?) vor der eingentlich Ansteuerung die Punkte berechnet werden.

Zum Vergrößern anklicken....

Das TO wartet bis zum letzten möglichen Zyklus und sendet erst dann das Kommando (mit Zeitstempel) zu schalten. Das wird gemacht, um möglichst lange auf evt. Änderungen der Geschwindigkeit der Achse, von der die Nocken abhängt, reagieren zu können. Hast Du einen Zeitnocken, wird das Zurückschalten gleich mitgesendet, da die Zeit ja feststeht. Bei einem Wegnocken wartet das TO wieder bis zum letzten möglichen Zyklus, bis es das Kommando sendet.

Lockenfrosch schrieb:

Bei konstanter Maschinengeschwindigkeit ist der Einfluss des Zykluses egal und gewinnt mit immer größer werdenden Schwankungen mehr Relevanz. So stelle ich mir zumindest das Systemverhalten vor, aber ob ich richtig liege... ?

Zum Vergrößern anklicken....

Ja, wenn sich die Geschwindigkeit ändert wird es ungenauer. Um so mehr sich die Geschwindigkeit sich ändert, um so ungenauer wird es.
Die Frage ist, welche Massen im Spiel sind und um wie viel kann sich die Geschwindigkeit in einem Buszyklus (also in wenigen ms) ändern?

miami schrieb:

genau so ist es

Das TO wartet bis zum letzten möglichen Zyklus und sendet erst dann das Kommando (mit Zeitstempel) zu schalten. Das wird gemacht, um möglichst lange auf evt. Änderungen der Geschwindigkeit der Achse, von der die Nocken abhängt, reagieren zu können. Hast Du einen Zeitnocken, wird das Zurückschalten gleich mitgesendet, da die Zeit ja feststeht. Bei einem Wegnocken wartet das TO wieder bis zum letzten möglichen Zyklus, bis es das Kommando sendet.

Zum Vergrößern anklicken....

Das TO ist/sollte aber so intelligent sein und erkennen wenn die aus einen Wegnocken resultierende Ansteuerungszeit kleiner den Appliaktionszyklus ist und damit die Zeitstempel zusammen übertragen !? Sonst wäre das System ja vom Applikationszyklus abhängig und man müßte zwangsweise mit einen Zeitnocken arbeiten.

miami schrieb:

Die Frage ist, welche Massen im Spiel sind und um wie viel kann sich die Geschwindigkeit in einem Buszyklus (also in wenigen ms) ändern?

Zum Vergrößern anklicken....

Ich hatte die Geschwindigkeit schon mal getraced (Abtastung 4,5ms) und sonderlich gut sieht das nicht aus. Allerdings kommt ein nicht unerheblicher Teil der Schwankungen (die Peaks) von der suboptimalen Montage des Winkelgebers, da will der Anlagenbetreiber noch optimieren.

Lockenfrosch schrieb:

Das TO ist/sollte aber so intelligent sein und erkennen wenn die aus einen Wegnocken resultierende Ansteuerungszeit kleiner den Appliaktionszyklus ist und damit die Zeitstempel zusammen übertragen !? Sonst wäre das System ja vom Applikationszyklus abhängig und man müßte zwangsweise mit einen Zeitnocken arbeiten.

Zum Vergrößern anklicken....

Klar, wenn das Ausschalten im gleichen Zyklus erfolgen muss, werden beide Kommands (Ein und Aus) im vorherigen Zyklus übertragen.
Die TDQ unterscheidet eh nicht, ob Zeit- oder Wegnocken, die kennt nur Ein- und Ausschaltzeitpunkte.[/QUOTE]

miami schrieb:

Die TDQ unterscheidet eh nicht, ob Zeit- oder Wegnocken, die kennt nur Ein- und Ausschaltzeitpunkte.

Zum Vergrößern anklicken....

Macht sinn.

Lockenfrosch schrieb:

Ich hatte die Geschwindigkeit schon mal getraced (Abtastung 4,5ms) und sonderlich gut sieht das nicht aus. Allerdings kommt ein nicht unerheblicher Teil der Schwankungen (die Peaks) von der suboptimalen Montage des Winkelgebers, da will der Anlagenbetreiber noch optimieren.

Anhang anzeigen 35820

Zum Vergrößern anklicken....

Wenn die Messing bei konstanter Drehzahl erfolgte, wirst Du damit kaum glücklich werden, die Schwankungen betragen ja fast 50 %
Da kann ich dem SUB noch zustimmen, dem OPTIMAL aber nicht!

Die Messung ist bei konstanter Drehzahl erfolgt. Aktuell würde ich darauf setzen, dass die Schwankungen mehr oder weniger periodisch sind und das die Geschwindigkeit zum Nockeneinschaltpunkt jedesmal annähernd gleich ist. Und wie gesagt, der Winkelgebereinbau ist derzeit echt daneben, der eiert richtig mit einer Amplitude von ca 3-4mm, dazu ist er noch federnd gelagert, so dass er einiges an Maschinenvibrationen schlucken muss.

Ich hatte heute die Gelegenheit die ersten Gehversuche im echten Leben zu machen, allerdings mit ernüchternden Ergebniss. Die TM PosInput2 hat einen Fehler geschmissen wenn Sie dezentral verbaut war, unhabhängig davon ob Taktsynchronität aktiviert oder deaktiviert war. Leider hatte ich nicht genug Zeit um zu analysieren wo das Problem liegt...