Step 7 Schritt aus Schrittkette wird nicht registriert ...

[spirit]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi Ihr,

habe eine Frage. Es geht darum, dass ein Motor eine Achse ansteuert und gleichzeitig ein Greifer gedreht werden soll.

Also wenn die Achse z.B. 3cm gefahren ist, dann soll der Greifer schwenken - die Achse aber weiter in ihre Endlage fahren.
Das Problem ist nun, dass offensichtlich der Schritt (Greifer schwenken) zu kurz ist, damit das der Greifer registrieren kann.

Es handelt sich um einen Festo-Antrieb und ich habe einfach (in SCL eine Case-Anweisung) programmiert:

2: 
IF (Achse_ActualPosition = 300) THEN
  Schritt := 3;
END_IF;

In Schritt 3 soll dann der Greifer schwenken ...

Wenn ich die Achse bei 3cm kurz anhalten lasse und dann den Befehl für den Greifer gebe, dann klappt es - aber ich verliere natürlich zuviel Zeit ...

Wie könnte ich das lösen, damit der Greifer den Startimpuls auch sicher mitbekommt?

Vielen Dank!

 

[hub]

Niemals auf "=" abfragen.
Was macht deine Routine, wenn die Achse auf 300,001 fährt, anstatt auf 300?

 

[spirit]

Zuviel Werbung?
-> Hier kostenlos registrieren

Naja das Problem ist ja, dass der Greifer nicht mitbekommt, dass die Achse den Punkt 300 überfahren hat, weil sofort in den nachfolgenden Schritt gesprungen wird.

Die Achse fährt im Zuge ihres Weges eh über die 300er Marke hinweg.

 

[hub]

da musst du mir schon mal den Code vom Schritt 3 zeigen

 

[Ralle]

Du kannst bei Überfahren der Postion einen Merker (oder Datenbit) setzen, der dann den Greifer dreht. Diesen kannst du dann z.Bsp. wieder zurücksetzen, wenn der Greifer in die andere Richtung angesteuert wird.

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die Istposition der Achse wird in einem bestimmten Zeitraster übertragen.
Deshalb ist es fast unwahrscheinlich, dass du genau die 300 mitbekommst.
Darum hat hub vollkommen recht mit niemals auf "=" abfragen.

Bau mal deine Abfrage um:

IF ((Achse_ActualPosition >= 300) AND (Achse_ActualPosition <= Zielpos) THEN

Bei manchen Antrieben kannst du auch Ausgänge oder M-Funktionen beim Überfrahren einer Position setzen.

Gruß
Dieter

 

[spirit]

Die Istposition der Achse wird in einem bestimmten Zeitraster übertragen.
Deshalb ist es fast unwahrscheinlich, dass du genau die 300 mitbekommst.
Darum hat hub vollkommen recht mit niemals auf "=" abfragen.

Bau mal deine Abfrage um:

IF ((Achse_ActualPosition >= 300) AND (Achse_ActualPosition <= Zielpos) THEN

Bei manchen Antrieben kannst du auch Ausgänge oder M-Funktionen beim Überfrahren einer Position setzen.

Gruß
Dieter

Danke Dieter,

würde denn dann (wie von Ralle vorgeschlagen) auch ein Merker an der Position 300 nicht gesetzt werden?

Aber dann bleibt es ja auch etwas ein Zufallsprodukt, wann genau der Greifer zu schwenken beginnt, richtig?

 

[RONIN]

Schon. Da ja mit größer gleich 300 abgefragt wird.

JEIN. Der Greifer schwenkt sobald die CPU erhalten hat dass 300 oder mehr gefahren wurde. Die Ungenauigkeit ist (wie immer) die Aktualisierungsrate der Position und der CPU-Zyklus.

Ist aber besser als "möglicherweise gar nicht".

 

[spirit]

Zuviel Werbung?
-> Hier kostenlos registrieren

Schon. Da ja mit größer gleich 300 abgefragt wird.

JEIN. Der Greifer schwenkt sobald die CPU erhalten hat dass 300 oder mehr gefahren wurde. Die Ungenauigkeit ist (wie immer) die Aktualisierungsrate der Position und der CPU-Zyklus.

Ist aber besser als "möglicherweise gar nicht".

Ja das stimmt natürlich RONIN!

Und den Merker bei genau (also Abfrage auf "=") dem Wert 300 setzen, würde dann eher auch nicht klappen, oder?

 

[RONIN]

Und den Merker bei genau (also Abfrage auf "=") dem Wert 300 setzen, würde dann eher auch nicht klappen, oder?

Bin mir nicht sicher ob wir das selbe meinen, vielleicht habe ich den Satz auch missverstanden...

Positionsverlauf über 3 Zyklen: 299, 300, 301 -> Sowohl >= als auch = lößen den Greifer aus (oder setzt den Merker, je nachdem wie du es nennst).
Positionsverlauf über 3 Zyklen: 299, 301, 302 -> Nur >= löst den Greifer aus.

Beim größer gleich kann man sich auch das "merken" des Ereignisses sparen. Das = gilt schließlich nur für eine Position, das größer gleich für alle über 300.

oder was meintest du mit der Frage?

 

[bike]

Sollte nicht ein zusätzlicher Schritt dir helfen?

Wenn in Schritt 2 fertig ist, dann in Schritt 2a die nächste Bewegung starten, würde ich machen.


bike

 

[spirit]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ok RONIN,

habe mich vielleicht dumm ausgedrückt.

Der "Wunsch" war eben, dass der Greifer exakt bei dem Wert von 300 zu schwenken beginnt und nicht innerhalb eines Bereiches von z.B. 300 -400.


Nun hat ja Ralle unter anderem den Vorschlag gemacht, ich könnte bei genau 300 einen Merker setzen, der dann das Schwenken des Greifers auslöst.

Hierzu war nun meine Frage: Wird denn dieser Merker dann überhaupt gesetzt, wenn die Abfrage auf "=" lautet?

 

[Blockmove]

Ok RONIN,

habe mich vielleicht dumm ausgedrückt.

Der "Wunsch" war eben, dass der Greifer exakt ab dem Wert von 300 zu schwenken beginnt und nicht innerhalb eines Bereiches von z.B. 300 -400.

Dein Wunsch ist nicht machbar.
Sowohl die SPS als auch die Achssteuerung arbeiten mit div. Zeitrastern.
Bei der NC gibt es meist einen IPO-Takt.
Bei der SPS hast du Zykluszeit.
Bei der Kommunikation gibt es Aktualisierungszeiten.

Wenn sich also die Achse bewegt wirst du also nie in der Lage sein eine Bewegung genau bei 300.00 zu starten.

 

[spirit]

Dein Wunsch ist nicht machbar.
Sowohl die SPS als auch die Achssteuerung arbeiten mit div. Zeitrastern.
Bei der NC gibt es meist einen IPO-Takt.
Bei der SPS hast du Zykluszeit.
Bei der Kommunikation gibt es Aktualisierungstakte.

Wenn sich also die Achse bewegt wirst du also nie in der Lage sein eine Bewegung genau bei 300.00 zu starten.

Ok, vielen Dank!

Dann bleibt also im Grunde nichts anderes übrig, als wirklich immer über einen best. Bereich abzufragen, richtig?

 

[Ralle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn du auf >= 300 abfragst, wird der Merker beim ersten Überschreiten gesetzt, das hängt von der Geschwindigkeit deiner Hardware ab.
Man könnte auch gleich beim Anfahren das Drehen starten, aber über eine Freigabe noch solange verhindern, bis der Wert >= 300 ist.

 

[Blockmove]

Ok, vielen Dank!

Dann bleibt also im Grunde nichts anderes übrig, als wirklich immer über einen best. Bereich abzufragen, richtig?

Im Prinzip ja.

 

[RONIN]

Der "Wunsch" war eben, dass der Greifer exakt bei dem Wert von 300 zu schwenken beginnt und nicht innerhalb eines Bereiches von z.B. 300 -400.

"Exakt" existiert leider nur in unserer Vorstellung...

ich könnte bei genau 300 einen Merker setzen, der dann das Schwenken des Greifers auslöst.

Macht keinen Unterschied. Das >= würde den Merker auch bei 300 setzen.

Klar kann das "Größer gleich "auch erst bei 400 schalten, die Frage ist: Wann passiert das?

• Die Abfrage wird beim Positionswert = 400 das erste mal durchlaufen. Dass kannst du mit dem Programm ja verhindern. Kommt bei deiner Schrittabfolge wahrscheinlich gar nicht vor, du wirst schließlich irgendwo bei 0 starten. Man könnte den Wert auch noch weiter eingrenzen: >=300 UND <= 320
• Der PosWert spring von 299 auf 400. Dann hast du aber ein anderes Problem.

Wenn diese Bedingen eingehalten werden, dann ist >= ident mit = (zumindest im Punkt 300).
Man muss das Programm so gestalten dass das "Größer" im "Größer gleich" ein Vorteil und kein Nachteil ist.

Wie meine Vor-Schreiber schon schrieben ist eben die Frage ob die SPS die 300 denn jedes mal zu sehen bekommt.
Die Erfahrung sagt, meistens nicht. Deshalb nimmt man zur Sicherheit (sofern es die Logik nicht beeinflusst) lieber ein >=.

Insofern sollte man (wo möglich) immer mit >= oder <= anstatt von = arbeiten.
Das ist in der freien Wildbahn einer der häufigsten Gründe warum Programme mal gehen, dann aber wieder nicht....

 

[hub]

Zuviel Werbung?
-> Hier kostenlos registrieren

Der "Wunsch" war eben, dass der Greifer exakt bei dem Wert von 300 zu schwenken beginnt und nicht innerhalb eines Bereiches von z.B. 300 -400.

Wenn es so genau geht, kannst du ja einen kleinen Vorlauf berücksichtigen, der die Zeitverzögerungen (Bus, Antrieb, ...) geschwindigkeitsabhängig ausgleicht.
z. B. den Befehl fürn Greifer bereits bei Position 299,75 absetzen.

 

[weißnix_]

Wie hoch sind denn die Bewegungsgeschwindigkeiten/Geberauflösungen.
Ich glaube, Du machst Dich verrückt.
Mit dem angesprochenen Vergleich auf >= wird eben beim Überfahren der Sollpos. der Greifer ausgelöst. Abhängig von Geschwindigkeit/Auflösung kommt der Startbefehl also irgendwo sehr nah an der 300. Ich würde mal schätzen, wenn der Vergleich auf = 300 manchmal geklappt hat, dann hast Du eine Auslösehysterese von max 5 Incrementen. Ist das Nah genug an der 300? wenn nicht hilft nur die Berechnung eines geschwindigkeitsabhängigen Vorauslösewertes.

Du kannst ja programmmäßig "einfangen" welcher Positionswert den Greifer triggert.

 

[spirit]

Jetzt hätte ich noch eine Frage zu dieser Thematik:

Ich starte die Achse bei dem Wert 0 und lasse den Greifer ab >= 300 drehen. Wenn ich jetzt überprüfen möchte, ob der Greifer an der Stelle 400 auch wirklich gedreht hat, bevor die Achse in ihren Endlagenwert 500 fährt, dann
muss ich ja die Achse bei 400 kurz anhalten lassen; ist das richtig?

D.h. der erste Fahrbefehl lautet: 0 bis 400

Der zweite Fahrbefehl lautet: 400 - 500