Positionsdaten eines Winkelgebers sowohl über PROFINET/PROFIsafe als auch über Inkrementalschnittstelle zurückführen

[Markus114]

Zuviel Werbung?
-> Hier kostenlos registrieren

Guten Tag zusammen,

ich habe einen etwas speziellen Fall: Mein Winkelgeber soll wie der Titel schon sagt "Positionsdaten sowohl über PROFINET/PROFIsafe als auch über eine Inkrementalschnittstelle zurückführen".
Ich verwende bereits das Technologieobjekt "Positioning Axis", das über das PROFIdrive- Standardtelegramm 81 mit dem SPS- Controller kommuniziert (Für die sicherheitsgerichtete Kommunikation, zum Beispiel für das Auslösen bei zu hoher Geschwindigkeit).
Für die dynamischere Rückführung soll zusätzlich ein inkrementelles Signal direkt von dem Winkelgeber zur Control Unit des Servo- Umrichters gehen.

Wie kann man das umsetzen?

Ich habe eine Vermutung: Ich muss ein zweites Technologieobjekt namens "External Encoder" verwenden. Habe das auch schon ausprobiert, aber ich weiß nicht, was ich unter "Datenaustausch Geber" auswählen soll (Dachte mir wird da das inkrementelle Modul aus der Hardwarekonfiguration des Winkelgebers angezeigt, aber aber mir wird nur das Telegramm 81 angezeigt).

Wäre echt dankbar, wenn mir jemand da weiterhelfen könnte.


Mit freundliche Grüßen: Markus

 

[NBerger]

Sorry aber Twelegramm 81 ist ein reines Gebertelegramm da ist nichts sicherheitsgerichtet. Das wäre dann Telegramm 30/31...

Auch kann ein TO ExternalEncoder nicht zur Positionsregelung verwendet werden.
Wie soll den der Stellwert übergeben werden, Analog?

Was ist das denn für eine CU, Siemens? Z.B. G120 mit CU310 oder ein S120 mit CU320...

 

[Markus114]

Zuviel Werbung?
-> Hier kostenlos registrieren

So soll das ganze schematisch dargestellt aussehen:




Das PROFIsafe- Telegramm 30 und das PROFIdrive- Telegramm 3 verwende ich bei der Kommunikation zwischen der Control Unit und dem SPS- Controller (Rot markiert).
Irgendwie muss ich es ja auch Gleichzeitig hinbekommen den Ist- Wert des Winkelgebers direkt über die Inkrementalschnittstelle zurückzuführen (Ist dynamischer) und ich dachte, dass ich eventuell dafür ein zweites TO "External Encoder" verwenden muss. Das TO wäre nicht für die Regelung, sondern nur für die Rückführung. Der Soll- Wert kommt vom SPS-Controller über das TO "Positioning Axis".
Das, was du gesagt hast stimmt: Telegramm 81 ist nur für das PROFINET- Protokoll. Das wäre mein zweites Problem. Total vereinfacht gesagt frage ich mich wie ich die gelbe Linie zwischen Winkellgeber und SPS hinkriegen soll und die blaue Linie zwischen Winkelgeber und CU.

Bei der Control Unit handelt es sich um eine SINAMICS S120 CU310-2 PN. Ich habe keinen Motor mit integriertem Winkelgeber, sondern der Winkelgeber wird extern angeflanscht.

-Markus

 

[NBerger]

Ich verstehe nicht warum du mit dem Geber auf die CU und SPS willst.
Das macht doch nur Ärger... und ist völlig sinnlos.

Warum nicht, wie üblich, den Geber auf die CU und mit der SPS nur auf die CU zugegriffen.
Auch das Safety gewinnt nichts durch deine geplante Verschaltung.

Eine bessere Pervormance/Dynamik würdest du doch eher durch ein Taksynchrones Telegramm gewinnen mit entsprechend kleinem Servo-Takt (1500'er).

 

[Markus114]

Ich verwende bereits eine IRT- Kommunikation (Isochronous realtime) für eine bessere Performance/Dynamik.

Die Informationsübertragung über eine Inkrementalschnittstelle läuft rein elektrisch ohne Protokoll ab. Daher gibt es keine Verzögerungen durch Zyklus- und Verarbeitungszeiten, weshalb eine Informationsübertragung über eine Inkrementalverbindung insgesamt schneller ist als eine Verbindung über das PROFINET- Protokoll. Das ist mitunter der Sinn, warum es eine Inkrementalschnittstelle bei einer Control Unit gibt.

Die Besonderheit des verwendeten Winkelgebers, der in dem von mir zu erstellenden Anwendungsbeispiel verwendet wird (PROFINET mit PROFIsafe- Schnittstelle, sowie Inkrementalschnittstelle in einem einzigen Winkelgeber) soll in dem Anwendungsbeispiel "Vermarktet" werden.

Aber wie kriegt man sowas hin? Mit zwei Technologieobjekten? Ich habe auch schon gehört, dass bei einer TCPU mehrere WInkelgeber in das TO Positioning Axis eingefügt werden können. Aber habe keine TCPU.

-Markus

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die Besonderheit des verwendeten Winkelgebers, der in dem von mir zu erstellenden Anwendungsbeispiel verwendet wird (PROFINET mit PROFIsafe- Schnittstelle, sowie Inkrementalschnittstelle in einem einzigen Winkelgeber) soll in dem Anwendungsbeispiel "Vermarktet" werden.

Aber wie kriegt man sowas hin?

Ihr wollt etwas vermarkten, von dem ihr keine Ahnung habt?

 

[Markus114]

Könnte bitte jeder, der ein Kommentar schreibt, nur konstruktive Beiträge geben?

 

[NBerger]

Telegramm 3 geht nicht taktsynchron da wäre dann schon mal Telegramm 5 notwendig

Könnte bitte jeder, der ein Kommentar schreibt nur konstruktive Beiträge geben?

Sorry, aber hier hat DeltaMikeAir nun mal recht...

Zurück zum Thema:
Dein Vorhaben bringt keinen Dynamikgewinn, eher unklarheiten durch unterschiedliche Werte in der SPS. Welchem Wert soll man denn nun trauen/verwenden und warum, warum soll das denn besser sein wo soll da ein Vorteil liegen?
Ein sicheres Gebersignal wird nicht sicherer nur weil man es auf zwei Wegen weiterreicht.

Solche Konstrukte würde ich im leben nicht einsetzen.

 

[Markus114]

Zuviel Werbung?
-> Hier kostenlos registrieren

-"Sorry, aber hier hat DeltaMikeAir nun mal recht..." - Ich finde, man kann sich auch sachlich zu einem Thema äußern. Du kannst das ja schließlich auch, wofür ich dankbar bin, aber das scheint leider nicht die Stärke von jedem zu sein.
-Ja ich weiß, dass Telegramm 3 nicht für einen taktsynchronen Betrieb geeignet ist. Ich habe das Telegramm 3 ja auch nur vorübergehend drin. Später soll DSC im Technologieobjekt verwendet werden, weshalb dann das Telegramm 105 in Kombination mit "MC-Servo" zum Einsatz kommt. Mit diesem Telegramm habe ich aber momentan noch ein Problem, weshalb ich Telegramm 3 vorübergehen drin habe.
-Auf den Vorteil der Inkrementalschnittstelle bin ich bereits eingegangen (Noch detaillierter: Über PROFINET habe ich Übertragungszeiten von 1 ms, über die Inkrementalschnittstelle geht das deutlich schneller)
-"Ein sicheres Gebersignal wird nicht sicherer nur weil man es auf zwei Wegen weiterreicht": Das habe ich nie behauptet. Natürlich kann man immer nur einen Wert gleichzeitig regeln. Im Anwendungsfall wäre die SPS nicht für die Regelung da, sondern nur, um im Fehlerfall die Safety Integrated Functions der CU auszulösen. Die Regelung wäre, wie hier im TO dargestellt über die Inkrementalschnittstelle und DSC:

 

[NBerger]

Bitte informiere dich erst mal richtig. Vielleicht wäre auch eine Schulung bei Siemens ratenswert.

Im gesammten unterliegst du da einigen Fehlschlüssen...

 

[Markus114]

Kannst du mir sagen in welchen Punkten ich Fehlschlüssen unterliege?
Dann würde ich mich nochmal selbst genauer darüber informieren. Ich müsste erstmal wissen was ich falsch mache/falsch sehe, um mich dann im nächsten Schritt darüber zu informieren. Das wäre für mich echt hilfreich. Danach werde ich auch nicht mehr deine Zeit beanspruchen.

 

[NBerger]

Zuviel Werbung?
-> Hier kostenlos registrieren

A.) Sprich bitte nicht über dinge die du nicht hast:

Ja ich weiß, dass Telegramm 3 nicht für einen taktsynchronen Betrieb geeignet ist. Ich habe das Telegramm 3 ja auch nur vorübergehend drin. Später soll DSC im Technologieobjekt verwendet werden, weshalb dann das Telegramm 105 in Kombination mit "MC-Servo" zum Einsatz kommt.

B.) Wer sagt denn sowas?

Auf den Vorteil der Inkrementalschnittstelle bin ich bereits eingegangen (Noch detaillierter: Über PROFINET habe ich Übertragungszeiten von 1 ms, über die Inkrementalschnittstelle geht das deutlich schneller)

1.Das hängt a von deinem Bustakt ab, kann also auch deutlich schlechter sein.
2. Wieso geht das mit der Inkremantalschnittstelle deutlich schneller? Auch hier hängst du am SPS-Zyklus ggf. an einem Zeit OB

C.) Das ist defenitiv falsch... Telegramm 105 bildet mit der CU einen Regelkreis!!!

m Anwendungsfall wäre die SPS nicht für die Regelung da

 

[maxder2te]

Anhang anzeigen 71252
So soll das ganze schematisch dargestellt aussehen:
Anhang anzeigen 71250

Anhang anzeigen 71253

Das PROFIsafe- Telegramm 30 und das PROFIdrive- Telegramm 3 verwende ich bei der Kommunikation zwischen der Control Unit und dem SPS- Controller (Rot markiert).
Irgendwie muss ich es ja auch Gleichzeitig hinbekommen den Ist- Wert des Winkelgebers direkt über die Inkrementalschnittstelle zurückzuführen (Ist dynamischer) und ich dachte, dass ich eventuell dafür ein zweites TO "External Encoder" verwenden muss. Das TO wäre nicht für die Regelung, sondern nur für die Rückführung. Der Soll- Wert kommt vom SPS-Controller über das TO "Positioning Axis".
Das, was du gesagt hast stimmt: Telegramm 81 ist nur für das PROFINET- Protokoll. Das wäre mein zweites Problem. Total vereinfacht gesagt frage ich mich wie ich die gelbe Linie zwischen Winkellgeber und SPS hinkriegen soll und die blaue Linie zwischen Winkelgeber und CU.

Bei der Control Unit handelt es sich um eine SINAMICS S120 CU310-2 PN. Ich habe keinen Motor mit integriertem Winkelgeber, sondern der Winkelgeber wird extern angeflanscht.

-Markus

So wie ich das verstehe ist das ein Profisafe Winkelgeber mit zusätzlichem Inkrementalgeberausgang. So wie ich den Markt der Profisafe-Geber kenne arbeitest du bei TWK, TR oder Kübler, IRT unterstützen nur TR und Kübler. TR hat die oben genannte Kombi schon am Markt, Kübler drängt da hin.

Die Inkrementalspuren dienen doch lediglich der Drehzahlregelung und haben lediglich den Sinn, dass man für die Drehzahlrückführung keinen zusätzlichen Motorgeber braucht, sondern den Safety-Geber verwenden kann.

Ich hab mit den TR CDS582M im Labor Versuche gemacht welche die Dynamik der Inkrementalspuren mit dem Geberwert über Profinet-IRT vergleicht, als Referenz saß auf der selben Welle noch ein weiterer Inkrementalgeber.
Die Inkrementalgeber wurden per ET200SP TM Count im Fast Mode eingelesen über Profinet IRT.

Ihr dürft jetzt raten wie groß der Unterschied der Inkrementalspuren zu den Werten per Profinet-IRT vom Geber war: nicht messbar.

Man muss dazu wissen dass der Geber zusätzlich zum Safety-Telegramm auch noch die einzelnen (optischen) Spuren im IRT-Takt liefern kann, und das natürlich mit einer anderen Abtastzeit als das Safety-Telegramm.

Ich glaube nicht dass der TE von TR kommt. Ich habe aber auch noch nicht verstanden worum es dir geht und was die Fragestellung ist. Höhere Dynamik wirst du mit keinem Konstrukt, die Inkrementalspuren von der CU an die PLC weiterzureichen, nicht bekommen. Und ich gebe zu bemerken, wenn mir jemand ohne detaillierte Ahnung sowas als Anwendungsbeispiel mit höherer Dynamik verkaufen will wird er als Lieferant raus fliegen.