Konsistente Datenübertragung zum Umrichter

mnuesser

Level-1
Beiträge
1.022
Reaktionspunkte
165
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

in meinen Projekten setze ich zumeist auf konsistente Datenübertragung bei den Umrichtern,
aber ist das überhaupt notwendig? Wann können denn mal Inkonsistenzen Auftreten?

Achja, Anschluß als DP-Teilnehmer...
 
Moin.
Hört sich nach Siemens SPS an. SFC 14 & 15 verwenden. Es passiert das ein dword zerhackt wird und nicht Komplet in einem Rutsch übertragen wird. Dann stimmen die soll oder istwerte nicht mehr
Kenne ich nur von Siemens. Aber ich kenne nicht alle Steuerungen Beckhoff , Bosch Rexroth. Und Schneider machen das richtig


Sent from my iPhone using Tapatalk
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ist noch eine Frage wie die Daten über den Feldbus übertragen werden. Es gibt hier meistens zwei Möglichkeiten: Prozessdatenkanal oder den Parameterkanal.
Prozessdatenkanal(PDO): Hier werden die Soll- und Istwerte Zyklisch zwischen den Teilnehmern ausgetauscht. Ist von Vorteil wenn der Drehzahlollwert Konsistent übertragen wird. Wobei der Motor kaum etwas ändern kann wenn die Daten dann im nächsten SPS-Zyklus stimmen. Man hat ja noch Rampen und ein gewisses Massenträgheitsmoment.
Parameterkanal(SDO): Hier können dann alle Parameter im Umrichter von der SPS aus geändert werden. Hier sollte auf jeden Fall der ganze Wert in einem Zyklus geschrieben werden, da es sonst tatsächlich zu komischem Verhalten führen kann.

Kenne das Problem auch nur Seiten SIEMENS.
 
Aus der Beckhoff-Welt ist mir das Problem unbekannt. Ein Feldbus, der nicht dafür sorgen kann, dass die Daten konsistent sind ist meiner Meinung nach öllig ungeeignet für Echtzeitaufgaben.

Mit freundlichen Grüßen
Thorsten Ostermann
 
Kenne das Problem auch nur Seiten SIEMENS.

... also ich kenne das Problem nicht. :cool:
Man verwendet bei z.B. SFC14/15 wenn man mehr als ein Doppelwort konsistent übertragen will, oder man arbeitet mit Lade-/Transferoperationen, falls ein Doppelwort konsistent reicht.
Wenn man z.B. einen Temperaturwert lesen will, dann braucht das nicht konsistent zu einem Zustandswort sein. Wenn man aber einen Start-Befehl für eine Positionierung sendet, dann sollte man eben schon sicher sein, dass der Lagesollwert konsistent ist.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Bei anderen Steuerungen wie LENZE, Beckhoff etc. stellt man sich diese Frage gar nicht :D
Mit diesem Problem bin ich nur bei SIEMENS konfrontiert worden. Man muss ja erst auf die Idee mit den SFC14/15 kommen.
 
Man muss ja erst auf die Idee mit den SFC14/15 kommen.

... da gibt es genügend Applikationbeispiele bei SIEMENS, wo entsprechende Beispielprogramme und Dokumentation hinterlegt sind.
Wenn man nun eine Standard- S7 verwendet, dann ruft man z.B. im zyklischen OB1 die SFC`s auf und diese übertragen konsistent die Daten und der Antrieb liest es dann wieder ein. Soweit alles gut.

Es gibt aber auch noch die Variante mit dem OB61. Dort kann man den OB- Zyklus / Buszykluszeit (egal ob Profibus oder -net) und die antriebinternen Zeitscheiben eines SINAMICS S120 synchronisieren (also schon mit der Standarad- S7 (also man braucht da noch keine T-CPU oder gar eine SIMOTION).
Beispiele wo man das gut gebrauchen kann:
1. Beim Vernieten wird jede ms Drehmomentistwert und Lageistwert protokolliert. Im Vergleich mit einer Hüllkurve wurde entschieden, ob die Vernietung in Ordnung ist oder nicht.
2. Eigene Sollwertinterpolation in der SPS
3. SPS- Logik synchron zu den Antriebszeitscheiben etc.

Wobei im Normalfall SFC14/15 ausreicht.
Ich selbst arbeite gerne mit dem FB283, da man die zyklische und azyklische Kommunikation im Bauch hat (mit Sonderaufträgen wie Störpuffer lesen, Verfahrsätze schreiben etc., wobei dieser auf die SINAMICS - Antriebsfamilie aufsetzt).

Ich kann mir schon vorstellen, dass "meierrog" mit anderen Steuerungen auch gute Erfahrungen gemacht hat. Ist immer von Vorteil wenn Steuerung und Antrieb aus einem Hause kommen (egal ob LENZE, Beckhoff oder SIEMENS), weil dann das Gesamtsystem am besten aufeinander abgestimmt ist (wie z.B. verfügbare Beispielprogramme, Systemdiagnose, Busanbindung, Routingfunktionalität, gemeinsame Fernwartung, Fehlermeldungen im Klartext fürs HMI, ...)
 
Zuletzt bearbeitet:
Moin

Bei Bosch Rexroth gibt es fertige Beispiele für die verschiedenen Steuerungen und Bussysteme Bei Inhalten alles was gebraucht wird und können erweitert werden


Sent from my iPhone using Tapatalk
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Inkonsistente Daten könnten z.B. entstehen, wenn du Parameter an einen Teilnehmer überträgst und dieser Parametersatz aus mehr als 4 Bytes besteht. Beispielsweise eine 64 Bit Gleitkomma- oder Ganzzahl ließe sich mit zwei PAD Zugriffen nicht konsistent übertragen. Sobald das erste PAD geschrieben wird, gehen unter Umständen die ersten 4 Bytes schon an den Teilnehmer während im zweiten PAD noch der Wert vom letzten Zyklus steht.

Ein DWord kann mit PAD/PED auf jeden Fall immer konsistent geschrieben/gelesen werden, mehr geht nur mit den entsprechenden SFC.

Wahrscheinlich benötigen das andere Steuerungen nicht, weil diese die Daten der Busteilnehmer immer im Prozessabbild liegen haben. Das Verhalten kann man bei Siemens auch einstellen, man muss nur das Prozessabbild entsprechend groß einstellen sodass die gewünschten Teilnehmeradressen im Abbild liegen, und dann nur mit EW/ED anstatt PEW/PED auf die Daten zugreifen. Dann sind die Daten immer konsistent ohne dass man groß was dafür tun muss.

Die direkte Peripherieadressierung bietet eine zusätzliche Flexibilität, indem man auch mehrmals pro Zyklus aktuelle Werte erhalten kann.
 
Zurück
Oben