TIA Profisafe Geber SSI von TR, Zykluszeit/Abtastzeit verbessern

Aleksej

Level-2
Beiträge
5
Reaktionspunkte
1
Zuviel Werbung?
-> Hier kostenlos registrieren
Mahlzeit, wir haben Testweise einen Profisafe SSI Drehgeber von TR gekauft (CDV582M-00061 65536 Revolution und 8192 Steps) bei der wir ein Problem mit der Auswertungszeit haben

Der Aufbau ist einfach: An der Welle eines Schrittmotors ist der Drehgeber gekoppelt, der Schrittmotor wird von Arduino ein/ausgeschaltet, den ein/ausschaltimpuls kriegt die Arduino über ein Schütz welches von der Safetykarte der SPS angesteuert wird
Der Schrittmotor hat eine einstellbare Geschwindigkeit aktuell ca. 1sec/umdrehung (praxis nah)
Die Werte kriege ich alle ziemlich präzise von dem Geber (UINT 0-65536) wobei das 8 umdrehungen entsprechen, diesen Wert teile ich noch durch 8 damit der Zähler bei jeder Umdrehung von neu anfängt, ich skalier die Werte auch passend zu Winkel 0-65536 = 0-359.9°

Nun zum Problem: Der Motor Soll bei 310° abschalten (ich schalte Schütz spannungsfrei) leider stoppt er aber erst bei 335 (was erstmal ok ist durch Toleranz und arduino)
Starte ich aber den Motor erneut ( start Winkel 335°) bleibt er bei ~355° stehen, erneuter start bleibt er bei ~10° stehen, erst hiernach bleibt er wieder bei ~335° stehen
Wenn ich dem Geber bei jeder Umdrehung 0° Wert zuweise (justage) dann bleibt die Toleranz konstant bei 25°, der bleibt dann immer bei 333-335° stehen, dies ist leider keine Lösung

Ich vermute dass es an der Zykluszeit liegt

Nun würde ich gerne wissen ob es da möglichkeit besteht das alles zu optimieren?
Wir hatten Parallel einen Drehgeber von Pilz dran mit PSU4000 PLC als auswertung, dort war die Toleranz 12° aber konstant, da gabs keine verschiebung von z.b 324° ->336°->348° etc

anbei habe ich auch das Programm archiviert V17
 

Anhänge

ich hab nur grob reingeschaut.
der stop kommt wenn der istwert > #"Position abkoppeln". das erklärt das verhalten.
im fb505 wird durch den start der stop rückgesetzt. im nächsten ob123-aufruf aber zurückgesetzt wenn die istpos noch > sollpos..
da musst du was an der logik umprogrammieren. zb das der stop erst nach dem nulldurchgang des gebers wieder aktiv wird.
was aber andere probleme bereiten kann abhängig von der sollstopposition.

ich würde zusätzlich zum safetyteil den geber auch im nichtsicheren programm einlesen und damit zusätzlich den stop auslösen.
evtl reihenschaltung von sicherm und nichtsicheren ausgang (relais)
oder im arduino 2 eingänge für den start verunden (1 sicherer und 1 unsicherer ausgang von der sps)
damit umgehst du die 100ms in der der ob123 aufgerufen wird.
oder du rufst den ob123 öfter auf.
.
entspricht der arduino überhaupt dem PLr?

simples beispiel. ob das mit den anforderungen einhergeht musst du prüfen
1739795321713.png
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
ich bin ein dusel, ich bin so dran gewöhnt das wir nur basics im safety machen dass ich garnicht geguckt hab was für ein Zykluszeit der OB123 hatte.. bei 100ms wundert es mich nicht, bei 30ms erzielen wir das nötige ergebnis
Wie weit kann ich die Zykluszeit runterschrauben das es keine "störung" gibt, bei 5ms meckert er von wegen laufspeicher voll und irgendwas mit OB 80, wo kann ich das was nachlesen?
 
schau mal nach der normalen zykluszeit des programms. du musst dem nichtsicheren teil auch zeit zur verfügung stellen.
ich sag mal so salopp ob123 aufruf = doppelte zykluszeit.

ob80
Zeitfehler-OBs unterbrechen die zyklische Programmbearbeitung, wenn die maximale Zykluszeit überschritten ist. Die maximale Zyklusszeit definieren Sie in den Eigenschaften der CPU.
 
vielen dank! haben etwas angepasst, bei 1214 sind wir bei 10-15ms geblieben mit 2-4° toleranz bei 80u/min
und parallel noch mit et200 probiert das selbe ergebnis, selbst bei 3ms zykluszeit, den rest schiebe ich einfach mal auf Arduino, in der Praxis kommt natürlich kein Arduino zum Einsatz
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Mit nem simplen Stop bei Sollposition wird das aber arg abhängig von der Massenträgheit.

Besser wäre vermutlich ein Rampdown über xx Incremente, der entsprechend xx Incremente vor dem Ziel startet.
 
Zurück
Oben