DP Kommunikation überwachen

Vatter

Level-1
Beiträge
12
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Leute,
Ich hab da ein kleines Prob :confused: beim Ansteuern eines FU´s.
Folgendes soll passieren :
Die Ein- und Ausgänge des FU´s werden über Profibus und SFC14 und SFC15 in einen DB geladen und zurück geschrieben. Jetzt bekomm der FU den Fahrbefehl auf eine Position X. Wenn das Signal "Position erreicht" vom FU zurück kommt, wird die nächste Zielposition in den DB geschrieben. Und jetzt kommts.... Da das Signal "Position erreicht" immer noch da ist, wird der nächste Schritt übersprungen und sofort die nächste Position geschrieben. Auch die Verzögerung über einen Zyklus nutzte nichts.
Wie kann ich erfahren, wann der FU die neue Position erfahren hat? Dabei ist zu bedenken, dass es durch dynamische Prozesse dazu kommen kann, dass "Pseudo-Fahrwege" herauskommen. Dann geht das Signal "Pos. erreicht" gar nicht weg. Ich müßte also warscheinlich mehrere Zyklen des DP abwarten? Wie könnte das gehen?
Dank im Voraus
Vatter
 
Wie hoch ist denn die Zykluszeit? Was für einen umrichter hast du dran? Synamics? Oder was von SEW mit ipos?
Kannst du das Signal "Pos. Erreicht" nicht einfach über eine pos. Flanke auswerten? Bekommst du nicht auch die Ist Position im Prozessdatenwort zurück? Werte das doch mit aus...?!
Wäre jetzt so meine idee.
 
Ich schließe mich den Beiträgen von jackjones und crash an, als weitere Anregungen fallen mir noch ein:

1. Den Ablauf eines solchen Positioniervorgangs könnte man auch mit einer kleinen Schrittkette abwickeln
2. Bei manchen Antrieben kann man mit Beendigung des Verfahrsatzes eine Schalt-/Hilfsfunktion ausgeben lassen

Grüße von HaDi
 
Zunächst ma Danke,
das mit dem direkten Vergleich von Soll-und Istwert habe ich bei meinem letzten Projekt schon realisiert, und das funzt auch. :ROFLMAO: Es ist nur ärgerlich, dass ein Signal Pos. erreicht existiert, welches ich so eigentlich nicht nutzen kann.
Ich war nun in der Hoffnung, daß der Umrichter die Arbeit macht. Allerdings müßte ich dazu meine neue Position ausgeben, und das Lesen des "Pos. erreicht" so lange verzögern, bis sicher ist, dass der Umrichter dieses Bit neu berechnet und geschrieben hat. Eine Zeitverzögerung ist aber immer dann doof, wenn z.B. sofort bei erreichen der Position der einen Achse die Achse 2 anlaufen soll (quasi eine Fahrt mit 2 Achsen um einen Winkel x).
Das Auswerten des Signals als Flanke hat sich nicht bewährt, weil es im Ablauf vorkommen kann, dass die neue Sollpos. = der Istpos. ist. Dann gibt es keine Flanke.
Und die eigentliche Steuerung des Schreibens der Positionen steuere ich über Step7-Graph, ist ja auch bequem. Noch schöner wäre aber eben einfach dieses "Pos. erreicht" in die Translation zu nehmen und feddich. Aber dann eben .....(s.o.).:confused:
Zu den verwendeten Bauteilen:
S7-300 und Umrichter SEW Movidrive MDX60B mit erweiterter Buspositionierung.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
S7-300 und Umrichter SEW Movidrive MDX60B mit erweiterter Buspositionierung.

Habe ich vor einiger Zeit auch eingesetzt und habe, wie die Kollegen oben schon vorgeschlagen, zusätzlich zu dem Signal "Position erreicht" einen Vergleich von
Soll- und Ist-Position durchgeführt.
Sollte ja auch ncht das große Problem darstellen (zumindest nicht in FUP, o.ä. [zu Graph kann ich da keine Aussage machen]).

Gruß smartie
 
ich würde zusätzlich soll und istposition vergleichen.
Normalerweise darf eine Überwachung "auf Position" nur über die Istposition und einen Soll-Ist-Vergleich (mit Positionsfenster +/-) gemacht werden. Das Signal "In Position" ist bei fast allen Antrieben sehr problematisch.
Bei uns die Überwachung NUR über einen Soll-Ist-Vergleich mit Positionsfenster. Das Signal "Position erriecht" wird generell bei keinem Antrieb verwendet!
Wir verbauen pro Jahr mehre 100 Servo-Antriebe, und sind mit dem Konzept bisher immer gut gefahren.
 
Zuletzt bearbeitet:
1. Ist- Sollwert vergleichen

Es gibt aber machmal auch Situationen (Antriebe) da bekommt man keine Position zurück (leider)!
2.

Schritt n+1 Start des Antriebes
Schritt n+2 In_Position muß False werden
Schritt n+3 In_Position = True --> fertig

Problem: Ist der Antrieb schon auf der gewünschten Pos, kann die Schrittkette hängenbleiben, was man verhindern muß.

Leider bilden viele Hersteller das Signal In_Position unterschiedlich.
Darauf muß man achten, es gibt folgende, mit bekannte,Varianten:

1. Solange Start-Signal anliegt, ist IN_Position auf False, Start stehenlassen, bis In_Position False, dann Start auf False, Antrieb fährt, bis In_Position = True
2. In_Position geht eine bestimmte Zeitspanne (50ms) auf False, wenn Start gegeben wurde. Start kann stehenbleiben oder Start mit Flanke
3. In_Position ist solange auf True, wie im Servo Soll=Istposition (natürlich ein Fenster)

Variante 2 m.E. ist die Beste, man kann den Antrieb auch nochmals auf die Position starten, auf welcher er bereits steht, die Schrittkette läuft trotzdem bei obigem Schema (2.) normal durch.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Danke Leute,
also offenbar gibt es zu der Variante des Ist-/Sollwert-Vergleichs im Programm keine echte Alternative. Ich dachte nämlich schon, ich wär zu dämlich dieses In_Position richtig auszuwerten.
Vielen Dank für Eure Hilfe.
 
1. Solange Start-Signal anliegt, ist IN_Position auf False, Start stehenlassen, bis In_Position False, dann Start auf False, Antrieb fährt, bis In_Position = True
2. In_Position geht eine bestimmte Zeitspanne (50ms) auf False, wenn Start gegeben wurde. Start kann stehenbleiben oder Start mit Flanke
3. In_Position ist solange auf True, wie im Servo Soll=Istposition (natürlich ein Fenster)

Variante 2 m.E. ist die Beste, man kann den Antrieb auch nochmals auf die Position starten, auf welcher er bereits steht, die Schrittkette läuft trotzdem bei obigem Schema (2.) normal durch.
Der Soll-Ist-Vergleich bietet den unübertroffenen Vorteil, dass man auf keinerlei Flanken usw. Rücksicht nehmen muss.
 
Zurück
Oben