Ablaufkette - Schritte werden übersprungen?

[twincatter]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Gemeinde,
wieder wende ich mich an Euch mit einer Frage.
Es geht um eine Ablaufkette, folgendes soll in einer Schleife passieren.

1. ZielpositionZunten anfahren (start mit globaler Variable gZAchse.PTPMove)
2. warten bis globale Variable gZAchse.InPos = TRUE (Transition)
3. ZielpositionZMitte anfahren (start mit globaler Variable gZAchse.PTPMove)
4. warten bis globale Variable gZAchse.InPos = TRUE (Transition)

siehe Anhang.

Leider funktioniert das bei mir nicht. Ich denke es liegt daran weil beide direkt aufeinander folgende Schritte die gleiche Transition (gZAchse.InPos) verwenden. Es sieht so aus als ob teilweise Schritte übersprungen werden.

Wenn ich (wie im Anhang ersichtlich) nach den eigentlichen Schritten Dummyschritte einfüge funktioniert es dagegen.

Doch das ist sicher keine gute Lösung!

In der Eingangsaktion setze ich übrigens gZAchse.InPos und gZAchse.PTPMove jeweils auf FALSE.

Ich hoffe mein Problem ist verständlich.

Vielen Dank, Michael

 

[Lupo]

Leider funktioniert das bei mir nicht. Ich denke es liegt daran weil beide direkt aufeinander folgende Schritte die gleiche Transition (gZAchse.InPos) verwenden. Es sieht so aus als ob teilweise Schritte übersprungen werden.

Das würde ich auch vermuten.
Du könntest z.B. nach dem Setzen der "neuen" Zielposition zusätzlich abfragen, dass die Achse nun nicht mehr in Position sein darf. Möglicherweise gibt es aber auch noch ein Bit mit der Info "Achse fährt". Auf jeden Fall solltest du so oder so ähnlich sicherstellen, dass die Achse erstmal fährt und somit eben nicht mehr auf der Sollposition ist.

 

[drfunfrock]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das generelle Problem mit solchen globalen Variablen ist, dass sie - wenn sie nicht aktiv zurückgesetzt werden, entweder eine 2. Bedingung oder dass sie einen weiteren Schritt in der Kette erfordern. Wenn du hier zu Schritt 3 gehst, kann die Achse noch in der Ausgangsposition sein, also noch melden, dass sie in Pos ist. Du brauchst eine zusätzliche Bedingung, die den Zielbereich mit einschliesst. Das war denn auch die Ursache, dass, wenn du einen Schritt dazwischengeschoben hast, die Achse sich aus dem Zielbereich herausbewegt hatte.

 

[twincatter]

Hallo Lupo,
erst einmal Danke für die Info.

Ich setze im Funktionsblock der für die Positionierung zuständig ist den Ausgang InPos immer dann auf FALSE wenn ein neuer Fahrauftrag (positive Flanke von PTPMOVE) an den Funktionsblock übergeben wird.
Das sollte doch schlüssig sein?

Zusätzlich, weil es eben nicht funktioniert, setze ich auch InPos auch in der Eingangsaktion zurück - ohne Erfolg.

Ich hoffe auf neue Anregungen, Lösungen.

Grüsse, Michael

 

[Lupo]

Ich glaube nicht, dass das Rücksetzen der FB-Meldung wirklich funktioniert - das widerspricht sich mit dem, was du schreibst, dass passiert.
In jedem Fall ist aber auch der Vorschlag von drfunfrock recht sinnig, wo du ja einfach die aktuelle Position +/- Toleranz überprüfst. Ist diese dann ungleich der Zielposition so kann dann ja mit deiner InPos-Meldung etwas nicht stimmen.
Ich persönlich favourisiere hier aber eigentlich eher den Handshake, wo ich dann ich der Schrittkette das Verlassen der aktuellen (also NICHT InPos) und dann das Erreichen der gewünschten Position (also InPos) abfrage (als 2 aufeinanderfolgende Schritte.

 

[Verpolt]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

Die "InPos" Meldung hängt doch sicherlich von einem vordefinierten Fenster ab. (z.B +/- 1mm um SollPos)

Die Abfrage würde ich mit "Fahrbefehl" + "FlankePosErreicht" realisieren.

 

[drfunfrock]

Verpolt hat recht:

Teste solche Variablen nur auf das Erreichen der richtigen Flanke, weil dieses Ereignis nicht statisch ist. Dafür gibts es auch einen FB ohne, dass man einen weiteren explizieten Schritt benötigt.

 

[twincatter]

Hallo,

vielen Dank für die vielen Antworten.
Ich bin derzeit noch am experimentieren.
Der Move-Funktionsblock ist im Moment noch so realisiert:
Die positive Flanke von PTPMove setzt InPos zurück und setzt einen Zähler TON auf 2Sekunden. Wenn der Zähler abgelaufen ist, wird InPos auf TRUE gesetzt.
Es findet also (zum Glück) noch keine echten Bewegungen statt.

Grüße, Michael

 

[Verpolt]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

vielen Dank für die vielen Antworten.
Ich bin derzeit noch am experimentieren.
Der Move-Funktionsblock ist im Moment noch so realisiert:

Die positive Flanke von PTPMove setzt InPos zurück und setzt einen Zähler TON auf 2Sekunden. Wenn der Zähler abgelaufen ist, wird InPos auf TRUE gesetzt.
Es findet also (zum Glück) noch keine echten Bewegungen statt.

Grüße, Michael

Warum setzt du eine Eingangsinfo zurück? zum Testen?

Da würde ich schon ein Bit opfern, mit dem man "PosErreicht" simuliert.

 

[twincatter]

Hallo, ich setzte die Eingangsinfo zurück, weil sonst die Schritte komplett übersprungen werden. Ich nehme an, nein ich bin mir sicher dass ich mir das Verfahren bei Schrittketten nochmals genauer anschauen muß.

Bin für weitere Infos dankbar, Michael

 

[Marco77]

Wie wird denn die ZielPos definiert? Ist das ne Variable aus der Steuerung oder fährt die Achse im "Positioniersatz - Betrieb"....
Wenn du mehr Infos über die Hardware nennst kann dir sicherlich besser geholfen werden.

Mit den mir jetzt bekannten Fakten würde ich auch die Idee von "Verpolt" vorschlagen.

Gruß Marco

 

[twincatter]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Programmierer und Experten,

leider habe ich den Ablauf (AS) immer noch nicht im Griff.

Ich habe einen Baustein FB_MovePTP erstellt und global instanziiert
Der Baustein simuliert eine Bewegung, d.h. nach einer Startflanke wird ein Timer gestartet
Ist der Timer abgelaufen, so wird das Signal InPos = TRUE ausgegeben
Ich hätte erwartet dass Positionen 1-3 hintereinander 'angefahren' werden.
Jedoch SPRINGT das Programm unregelmäßig durch den Ablauf.
Die Ursache liegt wohl im Timing der Schrittabarbeitung.

Ich hoffe Ihr könnt mir den/die Fehler aufzeigen.

Allen ein schönes Wochenende, Michael

 

[Verpolt]

Hallo Programmierer und Experten,

leider habe ich den Ablauf (AS) immer noch nicht im Griff.

Ich habe einen Baustein FB_MovePTP erstellt und global instanziiert
Der Baustein simuliert eine Bewegung, d.h. nach einer Startflanke wird ein Timer gestartet
Ist der Timer abgelaufen, so wird das Signal InPos = TRUE ausgegeben
Ich hätte erwartet dass Positionen 1-3 hintereinander 'angefahren' werden.
Jedoch SPRINGT das Programm unregelmäßig durch den Ablauf.
Die Ursache liegt wohl im Timing der Schrittabarbeitung.

Ich hoffe Ihr könnt mir den/die Fehler aufzeigen.

Allen ein schönes Wochenende, Michael

Vielleicht hilft es, die Var InPos nur als Flanke an deinen Transitionen abzufragen. Sonst wird ja sofort der Fahrbefehl wieder gestoppt.

 

[Markus Rupp]

also ich hatte solche probleme auch schon (als ich meinen modbus-treiber beigebracht habe queued-befehle abzuarbeiten) und habe es am ende einfach damit gelößt, das ich parallel zur befehls-/reaktionskette einen zähler (statische definition oder dynamisierte definition ist egal) geführt habe, der sichergestellt hat das die nötigen schritte durchlaufen werden allerdings war es kein as sondern case-anweisungen, ich denke aber das du sowas auch im as umsetzen kannst, deine transistionen währen dann eben nicht von InPos abhängig sondern vom wahrheitswert aus InPos und dem Zähler-Vergleich. Ich hoffe du konntest mir folgen und was damit anfassen.

 

[Lupo]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich bleibe dabei : du hast in deiner Schrittkette definitiv ein paar Schritte zu wenig drin. Dadurch erhälst du dann eine durchlaufende Kette. Ich persönlich halte das zusätzlich Einbauen von Flankenauswertungen für ein drum-herum-programmieren um die Schrittkette. Es würde aber das vorhandene Problem ganz sicher lösen helfen.

Dennoch - bei mir sähe das so aus :
S1 : Fahre auf Pos.1
T1 : warte bis Pos. errreicht = 1
S2 : lösche Pos. erreicht
T2 : Pos. erreicht = 0
S3 : Fahre auf Pos.2
T3 : warte bis Pos. errreicht = 1
S4 : lösche Pos. erreicht
T4 : Pos. erreicht = 0
S5 : Fahre auf Pos.3
T5 : warte bis Pos. errreicht = 1
S6 : lösche Pos. erreicht
T6 : Pos. erreicht = 0
usw.

das dargestellte impliziert dann allerdings auch die schon genannte Flankenauswertung.

 

[drfunfrock]

Ich bleibe dabei : du hast in deiner Schrittkette definitiv ein paar Schritte zu wenig drin. Dadurch erhälst du dann eine durchlaufende Kette. Ich persönlich halte das zusätzlich Einbauen von Flankenauswertungen für ein drum-herum-programmieren um die Schrittkette. Es würde aber das vorhandene Problem ganz sicher lösen helfen.

Dennoch - bei mir sähe das so aus :
S1 : Fahre auf Pos.1
T1 : warte bis Pos. errreicht = 1
S2 : lösche Pos. erreicht
T2 : Pos. erreicht = 0
S3 : Fahre auf Pos.2
T3 : warte bis Pos. errreicht = 1
S4 : lösche Pos. erreicht
T4 : Pos. erreicht = 0
S5 : Fahre auf Pos.3
T5 : warte bis Pos. errreicht = 1
S6 : lösche Pos. erreicht
T6 : Pos. erreicht = 0
usw.

das dargestellte impliziert dann allerdings auch die schon genannte Flankenauswertung.

Das ist definitiv zu viel Aufwand. Die Arbeit mit den Merkern ist ausserdem zu fehleranfällig. Eine Variable Typ Enumerated reicht und man vergisst keinen Merken zurüczusetzen. Wenn man allerdings so simple Dinge vergisst, wie dass das Signal POS-erreicht, statisch ist, kann einem niemanden helfen.

 

[cybertracepda]

hallo Leute !
Das Problem ist ,dass die Zählerflanke nicht richtig zählt, da der FB_Move.Start nur beim Duchlauf durch den Schritt Init einmal 0 wird und bei den anderen Schritte nicht. Hier sollte man programmtechnisch anders agieren. ich habe hier das Beispiel funktionierend bearbeitet und angehgängt. Ein leerer Zwischenschritt ist hier immer notwendig, aber normalerweise fährt man zum einer Position, macht dort etwas und dann wird die nächste angefahren
mfg
Cybertracepda