Step 7 Digitales Eingangssignal so schnell wie möglich erfassen

[Xplosion]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

stehe vor folgenden Problem:

Eine Wickelanlage, die Fehler im Wickelgut erkennt, läuft mit einer Geschwindigkeit von max. 600m/min (10m/s).
Bei einem Fehler im Wickelgut muss die Anlage stoppen. Da die Anlage aber nicht so schnell zum Stillstand kommt, fährt diese nach dem Stop rückwärts. Es wird bis zu einen bestimmten Bereich rückwärts gefahren, in der das Wickelgut eingesehen werden kann.

Dieser Bereich ist allerdings nur ca. 60cm lang. Somit muss die Anlage auf 60cm genau zurückfahren.


Das Wickelgut bewegt sich umgerechnet mit 10cm/ms. Wenn ich die Auslösezeit des Fehlerdedektors mal weglasse und nur die Zykluszeit einrechne ( ca. 4ms ), komme ich im schlechtesten Falle auf 80cm Differenz ( 2x Zykluszeit) , bis die Abschaltung wirklich erkannt wird.

Welche Möglichkeiten habe ich, um die Abschaltung schneller zu erfassen?

Es handelt sich um eine Insevis-CPU ( S7-315 ). Über einen Digitaleingang kommt das Signal vom Fehlerdedektor. Wenn die CPU das Signal erkannt hat, setzt die CPU einen Zähler in einen Frequenzumrichter (über Canopen) auf 0. Danach stoppt die Anlage und fährt anschliessend rückwärts bis der Zähler wieder bei 0 angekommen ist.

Die CANopen-Übertragung wird 1x pro ms aktualisiert. Die Signalzeit des Fehlerdedektors kann man wahrscheinlich vernachlässigen.


Wäre für Tips dankbar

 

[weißnix_]

Wenn Du nicht auf Position fahren kannst und auch keinen Schleichmodus für Rückwärts hast, könnte ich mir einen Alarmtimer vorstellen, der nach einer berechneten Zeit einen Stop auslöst. Damit kommst Du zumindest aus dem Zykluszeitraster raus. Die Alarmzeit kannst Du ja als Durchnittswert ermitteln.

Aus der beschriebenen Funktion der Anlage könnte ich mir daraus durchaus eine Verbesserung der Situation vorstellen.

 

[M-Ott]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich kenn mich mit den Insevis-CPUs nicht aus, aber bei einer Siemens-CPU würde ich das Ganze mit einer Alarmfähigen Eingangsbaugruppe und einem Prozessalarm-OB lösen. Ich weiß natürlich nicht, inwiefern diese Möglichkeit bei Insevis besteht.

 

[Xplosion]

die Rückwärtsfahrt findet langsam statt.

Mein Problem ist nur die Zeit zwischen "Fehler erkannt" und "FU Zähler auf 0 setzen". Alles danach ist kein Problem mehr.

Wenn nach dem Signal "Fehler erkannt" der FU-Zähler erst 10ms später auf 0 gesetzt wird, fahre ich schon 1m falsch zurück.


Ich spiele eher mit folgenden Gedanken:

- mehrere Abfragen pro Zyklus (im S7-Programm immer wieder abfragen)
- Frequenzzählerkarte in SPS einbauen

Wobei die Mehrfach-Abfrage in der SPS vielleicht doch die einfachste wäre. Muss ich dazu das PEW ständig einlesen oder reicht es wenn ich immer wieder z.b. E0.3 abfrage?

 

[volker]

e0.3 reicht nicht da dieses bit im pae liegt, aslo nur 1 mal pro zyklus aktualisiert wird. du müsstest schon pew einlesen.
ich würde das, wie m-ott auch schon erwähnt hat, über eine alarmfähige e-baugruppe machen.

 

[rheumakay]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich würde einen Inkrementalgeber einbauen und damit dann genau auf die Fehlerstelle "positionieren".
Ich denke aufgrund der hohen Geschwindigkeit, wird es über Zeit zu ungenau.
So machen wir es zumindest bei uns (Rohre werden Wirbelstrom geprüft ->Gut/Schlecht Sortierung/Markierung)

 

[weißnix_]

Bleibt ja nur der Alarm für das Rücksetzen. Mehrere Abfragen im Zyklus verlängern diesen ja auch noch...

 

[weißnix_]

Ich würde einen Inkrementalgeber einbauen

Den "Zähler im FU" verstehe ich schon als einen Positionsgeber.

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

... die Zykluszeit einrechne ( ca. 4ms ) ...

Welche Möglichkeiten habe ich, um die Abschaltung schneller zu erfassen?

Hier fällt mir in der beschriebenen Konstellation nur der OB35 mit einer sehr schnellen Abtastrate (1 ms) ein. Da müßtest du dann programmieren :

L PEB 12
T EB 12
(z.B.)

... nun kannst du auf das unerhoffte Ereignis schneller reagieren ...
Allerdings - wie machst du das (wenn deine Zykluszeit 4 ms ist) :

Die CANopen-Übertragung wird 1x pro ms aktualisiert.

In jedem Fall würde sich durch die Alarm-Bearbeitung zwar wahrscheinlich deine Zykluszeit erhöhen (von 4 auf 5 ms) - aber wäre das hier dann soooo schlimm ?

Gruß
Larry

 

[rostiger Nagel]

Welche Möglichkeiten habe ich, um die Abschaltung schneller zu erfassen?

Es handelt sich um eine Insevis-CPU ( S7-315 ). Über einen Digitaleingang kommt das Signal vom Fehlerdedektor. Wenn die CPU das Signal erkannt hat, setzt die CPU einen Zähler in einen Frequenzumrichter (über Canopen) auf 0. Danach stoppt die Anlage und fährt anschliessend rückwärts bis der Zähler wieder bei 0 angekommen ist.

Die CANopen-Übertragung wird 1x pro ms aktualisiert. Die Signalzeit des Fehlerdedektors kann man wahrscheinlich vernachlässigen.

Könntest du den nicht am Umrichter etwas machen, das du das Signal vom Sensor für die Störung,
direkt zum Umrichter legst, so das du weder Zykluszeit noch Buslaufzeit berücksichtigen musst.

 

[Tuffi]

Wie wäre es einen Weckalarm OB auf "Ausführen = 1" zu stellen und diesem OB und der EA-Karte mit dem Eingang dasselbe Teilprozeßabblild zuordnen und den relevanten Code in diesem OB laufen zu lassen.
Oder nur den Weckalarm OB auf "Ausführen = 1" und am Anfang des OBs halt:

L PEB 12
T EB 12

$relevanter Code

Gruß,
Tuffi

 

[Xplosion]

Zuviel Werbung?
-> Hier kostenlos registrieren

Könntest du den nicht am Umrichter etwas machen, das du das Signal vom Sensor für die Störung,
direkt zum Umrichter legst, so das du weder Zykluszeit noch Buslaufzeit berücksichtigen musst.

Genau das wird die Lösung sein. Werde das ausprobieren.



Habe heute mit Insevis telefoniert. Eine alarmfähige Baugruppe gibt es zwar, wird aber softwareseitig noch nicht unterstützt.

folgende Sachen scheiden aus:

- OB35 ( geht nur mindestens 10ms )
- alarmfähige Baugruppe derzeit nicht unterstützt
- mehrmalige Abfrage auch unsicher

Ich werde das Signal des Fehlerdedektors auf den FU bringen. Dieser setzt mir dann den Positionszähler auf 0.

Scheint mir die beste Lösung zu sein.

Danke für eure Hilfe

 

[Blockmove]

Auch wenn du die Zykluszeit in Griff bekommst, bleibt dir immer noch das Problem mit der Kommunikationszeit der SPS und des Umrichters.
Ich sehe es wie der rostige Nagel.
Pack die Funktionalität in den Umrichter.
Die meisten vernünftigen Antriebe bieten schnelle Eingänge (Touch Probe) für solche Aufgaben.
Je nach Hersteller gibt es div. Lösungen.
Du aktivierst z.B. die Funktion und bekommst über die Schnittstelle ein Signal, dass ein Ereigniss erkannt wurde und die dazugehörige Position.

Gruß
Dieter

 

[bike]

Du aktivierst z.B. die Funktion und bekommst über die Schnittstelle ein Signal, dass ein Ereigniss erkannt wurde und die dazugehörige Position.

Gibt es wirklich Umrichter, die bei einem Event sich die Position merken, herunterfahren und die Daten von dem Eintreten des Event bereitstellt?
Also ich kenne es so, dass ein Event den Umrichter herunterfährt.
Man kann dann die Daten auslesen, doch nur die aktuelle Position und nicht den Wert, an dem das Signal kam.
Liege ich falsch?

Für mich ist der Fehler bei der Projektierung gemacht worden und jeder Versuch sich aus der Spirale zu befreien ist und wird ein Krücke bleben.

Mit Alarmeingängen sind solche Anwendung zuverlässig realisiert werden.


bike

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

Gibt es wirklich Umrichter, die bei einem Event sich die Position merken, herunterfahren und die Daten von dem Eintreten des Event bereitstellt?
Also ich kenne es so, dass ein Event den Umrichter herunterfährt.
Man kann dann die Daten auslesen, doch nur die aktuelle Position und nicht den Wert, an dem das Signal kam.
Liege ich falsch?

Für mich ist der Fehler bei der Projektierung gemacht worden und jeder Versuch sich aus der Spirale zu befreien ist und wird ein Krücke bleben.

Mit Alarmeingängen sind solche Anwendung zuverlässig realisiert werden.


bike

Herunterfahren ist bei den meisten Umrichtern die Standardaktion.
Bei SEW kannst du mit IPos auch die Position wegspeichern.

Ein Alarmeingang hilft hier meines Erachtens wenig. Ohne die Eventposition ist der Alarm nur die halbe Miete.
Wenn man sowas mit ner SPS machen will, dann würde ich versuchen den Geberwert irgendwie auch noch direkt auf die SPS zu bekommen.
Evtl mit ner Splitbox auf ne passende Baugruppe.

Gruß
Dieter

 

[RogerSchw85]

Bei Sew wäre es tatsächlich möglich bei eintreten eines Events mit der Rampe zu stoppen und automatisch au die position zurückfahren in der das event eingetreten ist

 

[rostiger Nagel]

Herunterfahren ist bei den meisten Umrichtern die Standardaktion.
Bei SEW kannst du mit IPos auch die Position wegspeichern.

Ein Alarmeingang hilft hier meines Erachtens wenig. Ohne die Eventposition ist der Alarm nur die halbe Miete.
Wenn man sowas mit ner SPS machen will, dann würde ich versuchen den Geberwert irgendwie auch noch direkt auf die SPS zu bekommen.
Evtl mit ner Splitbox auf ne passende Baugruppe.

Gruß
Dieter

Mit SEW und IPOS ein Kinderspiel, da kann man in C jede Schweinerei machen.

 

[Ing_Lupo]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo

wenn Du die Zaehlerkarte einsetzt und einen Encoder angeschlossen hast kannst Du die Nullspur. benutzen.

Auf ein Eingangssignal von der Fehlstellendetektion wird der Zählwert auf Null gesetzt.
Dann kannst du den Antrieb langsam auf Null zurueckfahren.

Gruss