TwinCat2 - Lückensteuerung

HappyHippo95

Level-1
Beiträge
10
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo in die Runde,

wir haben eine Anlage, welche mit einer Lückensteuerung arbeitet. Soll heißen: Platten werden auf eine definierte, vom Maschinenführer eingegebene, Lücke aufgeschoben.
Wir möchten diese Lücke nun möglichst klein bekommen. Also ca. 2mm wären super. Derzeit schwankt die Lücke bei eingegebenen 5mm zwischen 3 und 10mm.
Als Lückenlichtschranken verwenden wir Leuze LSRL 713/2.8 bestehend aus Sender und Empfänger. Davon 4 Paar (jeweils ein Eingang).

Nun zu den Prioritäten der Tasks im System-Manager:

Auf Prio 4 liegt die NC-Task SAF, Zykluszeit 3ms
Prio 8 die NC-Task SVB, Zykluszeit 10ms
dann lange nichts
auf Prio 25 Task 0 (bei uns "Servo") Zykluszeit 3ms
und auf Prio 26 Task 1 (das restliche Programm). Zykluszeit 15ms
Die Eingänge der Lücken-LS sind in Task 0 verknüpft.

Frage 1: Macht der große Zwischenraum zwischen Prio 8 und Prio 25 irgendetwas aus? Könnte ich Task 0 & 1 einfach "runterschieben" auf Prio 9 & 10?
Frage 2: Wie könnte man die Lücken nun möglichst klein bekommen, ohne großartige Schwankungen zu haben? :confused:
Frage 3: Kann man irgendwo die tatsächlich, von der Steuerung benötigte Zykluszeit pro Task sehen?
Frage 4: Lohnt die Optimierung der Prioritäten?
Frage 5: Was ist "Boost Priority" und wie funktioniert es?

Die Mechanik der Anlage dürfte keine allzugroße Rolle spielen, da die Transporte kontinuierlich durchlaufen. Also kein ständiges Anfahren und Abbremsen. Dadurch sollte schonmal der Schlupf vernachlässigbar sein. Die Anlagengeschwindigkeit liegt bei 13-20m/min, je nach produziertem Produkt.

Ich hoffe, es gibt jemanden der meine ganzen Fragen beantworten kann.


LG
 
Die Prios sind uninteressant - solange es keine Exceed Counter gibt was bedeutet das eine Task in seinem Zyklus nicht zu Ende gerechnet wurde.
Ansonsten bedeuten die Prios nur ein "Verdrängungsprinzip"...
Dein Anlage wird aber keinen Deut besser wenn es keine Exceed Counter gibt und du daran etwas spielst/änders.


Relevant sind meines Erachtens primär die exakte Erkennung der Lichtschranken bzw. die exakte zeitliche Steuerung der Ausgänge.
3ms dürften nach Adam Riese und 20m/sec = 0.33 mm sein.... fuer die Erkennung sein.
Das Ganze dann eventuell noch für die Ausänge (keine Ahnung wie Ihr das macht)...

Wenn Ihr die Performance-Reserver habt macht eine 1msec Task und rechnet hier die Eingänge/Zeiten/Ausgänge.
Ansonsten würde ich persönlich das Ganze mit TimeStamp-Eingängen (eventuell auch Ausgängen) realisieren die mir genau angeben (µs Level) wann das Signal kam bzw. der Aktor geschaltet werden soll. Also z.B. EL1259 oder EL2258 soviel ich mich erinnere.
Wenn man sich das Rechnen mit der Bahngeschwindigkeit sparen will nutzt man dann die XFC-Bibliothek (Kostenpflichtig).

Guga
 
Die Prios sind uninteressant - solange es keine Exceed Counter gibt was bedeutet das eine Task in seinem Zyklus nicht zu Ende gerechnet wurde.
Ansonsten bedeuten die Prios nur ein "Verdrängungsprinzip"...
Und deshalb kommt es schon darauf an, die Prioritäten ordentlich zu vergeben. Eine Task mit langer Zykluszeit darf keine höhere Priorität haben als eine Task mit kürzerer Zykluszeit.

@HappyHippo95:
Setz mal die Priorität der Task0 auf 6. Und hake "I/O am Taskanfang" an, damit der Output-Zyklus unabhängig von der benötigten Tasklaufzeit wird.
Die Lichtschranken hängen hoffentlich an E-Bus-Eingangsklemmen. Bei K-Bus-Klemmen würde Dir der K-Bus-Zyklus auch noch in die Suppe spucken.
 
Zuletzt bearbeitet:
Erstmal danke für die Antworten,

die Eingänge sind über eine FC2001 (Lichtbus) mit BK2000 an KL1114-Klemmen angeschlossen.
Kann man die Eingänge auch in der NC-Task SAF verknüpfen? Dann wären sie ja theoretisch auch höherprior.

@Guga: Was sind denn Performance-Reserver?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich kenne den Lightbus nur vom Hörensagen, aber der soll ja recht flott sein. Nützt Dir aber nicht viel, weil der interne K-Bus, über den der BK2000 mit seinen KL-Klemmen kommuniziert, schon eine Zykluszeit von typischerweise 3-4 ms hat. Da wird nur Umsteigen auf EtherCat helfen.
Aber erstmal würde ich auf der Softwareseite optimieren. Das Programm der Task 0 mit in die SAF-Task zu legen, wäre die eleganteste Lösung. Ob das geht, weiß ich nicht, da ich die Beckhoff-NC nicht einsetze. Alternativ sollte die Task 0 von ihrer Priorität her zwischen SAF- und SVB-Task liegen. Sonst schiebt die SVB-Task die Task 0 immer dann um die SVB-Laufzeit nach hinten, wenn SVB und Task 0 gleichzeitig anfangen wollen. SAF und Task0 müssen natürlich noch genug Zeit für SVB und Task 1 übrig lassen, also erstmal die Tasklaufzeiten überprüfen. Ein Blick auf die Online-Anzeige der Tasks im Systemmanager sollte dazu fürs Erste reichen.
 
Das Messfenster für die Sensoren + Aktoren besteht aus prinzipiell aus der Task-Zykluszeit + der Zykluszeit des unterlagerten K-Busses. Da kann schon einiges zusammenkommen.

Die Task-Zykluszeit kann man reduzieren wenn genug Rechenleistung vorhanden ist (da ja schneller/öfters gerechnet wird). Das wäre mein erster Ansatz.

Den unterlagerten K-Bus kannst du nicht beeinflussen bzw. nur wenn du an die HW rangehst (ersetzen oder aber einen zusaetzlichen Master setzen....).

Klar kannst du etwas mehr Determinismus hineinbringen mit der Checkbox "IO am Taskanfang". D.h. beim Interrupt der Task wird erst die EA behandelt und dann erst der Code gerechnet (der theoretisch je nach Situation länger oder kürzer sein kann). Ob du damit aber viel gewinnst bzw. ob der Hacken nicht schon gesetzt ist bezweifle ich.

Geht mal logisch die Signalkette durch und schaue wer / wo wie lange braucht und ob die Teilnehmer zeitlich unabhängig sind oder nicht. Damit hast du dann einen zeitlichen Jitter und somit auch einen Wegdifferenz. Dann sieht man recht klar was möglich ist bzw. notwendig ist.

Guga
 
Zurück
Oben