# Sensor als Drehwächter



## Gerki (6 Februar 2008)

Hallo 
Ich muss an einer alten CPU 315 eine Laufüberwachung programieren. Dazu benutze ich zur zeit einen fertigen Motorbaustein.
Dieser wird in einem FB als multiinstanz aufgerufen. 
Als Sensor dient ein einfacher induktiver Sensor von IFM.
Jetzt ist es so das ab und zu die Laufüberwachung anspricht obwohl das Signal immer am Eingang anliegt. Impulsdauer ca 100ms.
Zykluszeit der CPU 40 MS aber trotzdem scheint die SPS die Eingänge nicht mizubekommen


----------



## Markus (6 Februar 2008)

hat es schonmal funktioniert?

was wurde seither verändert?

wie sieht der programmteil aus deer den sensor auswertet?

ggf. dort die überwachungszeiten anpassen oder den impuls verlänern indem du eine längere schaltfahne für den ini anbaust.


----------



## IBN-Service (8 Februar 2008)

Gerki schrieb:


> Hallo
> Ich muss an einer alten CPU 315 eine Laufüberwachung programieren. Dazu benutze ich zur zeit einen fertigen Motorbaustein.
> Dieser wird in einem FB als multiinstanz aufgerufen.
> Als Sensor dient ein einfacher induktiver Sensor von IFM.
> ...




Hallo Gerki,

*die Zykluszeit solltest du x2 berücksichtigen!*

Da das Prozessabbild (aus dem du wahrscheinlich deinen Eingang liest, z.B. mit U E x.y)
i.A. nur am Kontrollpunkt vor dem OB1 aktualisiert wird,
kann im ungünstigsten Fall 2x die Zykluszeit vergehen, bevor dein
Programm auf einen Zustandswechsel reagiert.

Hinzu kommen Verzögerungen, die aus Buslaufzeiten (wenn der Eingang über Bus mit SPS verbunden ist)
sowie der Eingangsverzögerung selber resultieren.

Aus dieser Sicht betrachtet, ist deine Zykluszeit zu hoch, um ein sicheres Erkennen des Eingangs unter allen Umständen zu gewährleisten.

Grobes Beispiel:

2 x 40ms + 10 ms (Buslaufzeit) + 10 ms (Eingangsverzögerung) = 100ms.

Ein Signal von 100ms Dauer wirst du dann nur noch sporadisch erkennen.

Abhilfe könnte hier ein Einlesen des Eingangs in einem Weckalarm - OB schaffen.

CU

Jürgen
IBN-Service


----------



## Jordy (9 Februar 2008)

IBN-Service schrieb:


> Hallo Gerki,
> 
> *die Zykluszeit solltest du x2 berücksichtigen!*
> 
> ...


 

  
Nöö, wieso? Bei einer Zykluszeit von 40ms wird das Prozessabbild auch alle 40ms aktualisiert. Ob ich den Eingang am Anfang von meinem Programm abfrage oder am Ende macht doch kein Unterschied!?


Zum Problem: 

@Gerki: Hast du keinen Timer im Programm? Also NUR den Eingang abfragen, ohne wenigstens ne halbe Sekunde Einschaltverzögerung beim Alarm ist bisschen unsicher.
Oder bekommst du vielleicht den Alarm beim hochfahren des Motors?

Anonsten wie Markus sagt, Schaltfahne verlängern.


----------



## Antonio (9 Februar 2008)

Oder den eingang über die Interruptsteuerng abfragen...
z.B OB 40, die Eingangsbaugruppe muss aber dafür geeignet sein


----------



## lorenz2512 (9 Februar 2008)

hallo,
@ jordy: stimmt schon mit den 2xzyklus, wenn man ein signal sicher erfassen will, zottel hat das hier schon mal schön erklärt.
das einfachste ist die markuslösung, ob40 geht auch, und dann gibt es noch impulsverlängerer.


----------



## Jordy (9 Februar 2008)

Ja? Huch... Hast du mal den link? In der Suche finde ich es nicht... Würd mich mal interessieren.


----------



## godi (9 Februar 2008)

Hallo!

Vielleicht währe es in deinem Fall einfacher einen Sensor einzubauen der bei Schwellwert schaltet.
Also der schaltet immer durch wenn die Drehzahl stimmt und bei Unterschreitung schaltet er ab. Damit hast du keine Zyklusprobleme. Und im Programm brauchst du nur den Eingang abfragen.


----------



## Jordy (9 Februar 2008)

Jup... oder ne Zählerbaugruppe für die SPS. Dann kannste auch schön die Drehzahl anzeigen...


----------



## lorenz2512 (9 Februar 2008)

hallo,
@ jordy: da ist eine erklärung von rolfb dabei:http://www.sps-forum.de/showthread.php?t=9686&highlight=zykluszeit+eing%E4nge

gibt aber wohl noch erklärungen hier im forum.


----------



## Jordy (9 Februar 2008)

Ja gut. Das das Signal danach auch einen Zyklus "0" sein muss ist klar. Bin mal davon ausgegangen das in Gerkis Fall 100ms signal "1" ansteht und 100ms signal "0".

Also sowohl das positive signal als auch das negative signal muss größer als die Zykluszeit plus Eingangsverzögerung.

Denke mal das ist hier gegeben, Gerki?


----------



## IBN-Service (9 Februar 2008)

Jordy schrieb:


> Nöö, wieso? Bei einer Zykluszeit von 40ms wird das Prozessabbild auch alle 40ms aktualisiert. Ob ich den Eingang am Anfang von meinem Programm abfrage oder am Ende macht doch kein Unterschied!?



Jordy,

doch, das macht einen Unterschied.

Was passiert denn, wenn du im letzen NW im OB1 den Eingang abfragst,
der Eingang aber zeitlich "im ersten NW im OB1" den Zustand gewechselt hat?
(Worst - case)

Bitte _erst überlegen_, _dann _antworten.

Zur Not hilft ein Blick ins Handbuch, 
da gibts Beispiele zur Berechnung...


----------



## godi (9 Februar 2008)

IBN-Service schrieb:


> Jordy,
> 
> doch, das macht einen Unterschied.
> 
> ...



Das sollte doch echt egal sein!
Das Prozessabbild der Eingänge hat am Anfang des OB1 den selben zustand wie am ende des OB 1 außer du greifst schreibend auf einen Eingang zu.

Auch wenn sich im ersten Netzwerk vom OB 1 der zustand des Signales ändert bleibt er trotzdem im Prozessabbild gleich! Also selber zustand am Anfang von OB 1 wie auch am schluss! Die Änderung wird erst beim nächsten Aufruf des OB1 wirksam.


----------



## IBN-Service (9 Februar 2008)

godi schrieb:


> Das sollte doch echt egal sein!
> Das Prozessabbild der Eingänge hat am Anfang des OB1 den selben zustand wie am ende des OB 1 außer du greifst schreibend auf einen Eingang zu.
> 
> Auch wenn sich im ersten Netzwerk vom OB 1 der zustand des Signales ändert bleibt er trotzdem im Prozessabbild gleich! Also selber zustand am Anfang von OB 1 wie auch am schluss! Die Änderung wird erst beim nächsten Aufruf des OB1 wirksam.



Oh godi,

und welche Verzögerung ergibt sich dadurch zwischen
Zustandsänderung und der zugehörigen Programmreaktion?


----------



## godi (9 Februar 2008)

IBN-Service schrieb:


> Oh godi,
> 
> und welche Verzögerung ergibt sich dadurch zwischen
> Zustandsänderung und der zugehörigen Programmreaktion?



Ja das mit der Verzögerung ist mir ja klar das ich 2 mal die Zykluszeit baruche!
Vielleicht habe ich da jetzt nur deine Antwort im zusammenhang falsch verstanden.
Das hat sich für mich so angehört als würdest du das während des OB1 mitbekommen wenn sich ein Eingang ändert.


----------



## IBN-Service (9 Februar 2008)

godi schrieb:


> ... Das hat sich für mich so angehört als würdest du das während des OB1 mitbekommen wenn sich ein Eingang ändert.




Hallo godi,

genau davon war hier *nicht *die Rede!


----------



## Jordy (10 Februar 2008)

IBN-Service schrieb:


> Jordy,
> 
> doch, das macht einen Unterschied.
> 
> ...


 
Ja, stimmt. Im extremfall doppelter Zyklus. Haste recht!
Geht aber auch bisschen Freundlicher, das Forum ist dafür da sowas zu diskutieren und argumentieren. Wenn jeder alles wüsste und das Handbuch so toll wäre bräuchte man das Forum nicht. 


Zum Thema.
Wobei es mit den 100ms reichen sollte, da die Trägheit vom DI keine 20ms braucht... Aber is schon knapp..


----------



## Ralle (10 Februar 2008)

Jordy schrieb:


> Ja, stimmt. Im extremfall doppelter Zyklus. Haste recht!
> Geht aber auch bisschen Freundlicher, das Forum ist dafür da sowas zu diskutieren und argumentieren. Wenn jeder alles wüsste und das Handbuch so toll wäre bräuchte man das Forum nicht.
> 
> 
> ...



100% Ack in diesem Falle  ! Soll ja keiner Angst haben, mal was Falsches zu antworten.


----------



## Gerki (11 Februar 2008)

Hallo danke schon mal für die ganzen Antworten
Alle Hardwareänderungen fallen raus, da der Kunde das nicht wünscht.
Ich kann euch ja gerne noch mal einen Auszug vom Programm geben Multiinstanz FB 122 wo die Eingänge verarbeitet werden. Das Komische ist das in dem Programm 8 Bänder laufen, wovon nur Zwei Probleme machen. Hatte es auch schon mit dem OB 35 versucht( nur diesen kann ich Aufrufen), aber das hat nichts gebracht

FB 121 Motorbaustein
FB 122 Multiinstanz


----------



## IBN-Service (17 Februar 2008)

Jordy schrieb:


> Wobei es mit den 100ms reichen sollte, da die Trägheit vom DI keine 20ms braucht... Aber is schon knapp..



Ja, die 20ms haben ja, wie geschrieben, als "grobes Beispiel" gedient.
Meist wird die Bus- und Eingangsverzögerung kleiner sein.

Aber du musst be_denken_, dass die Zykluszeit von ca. 40ms auch nicht immer konstant
ist sondern durchaus, je nach Maschinenzustand und Betriebsart, um 10 - 20 % 
schwanken kann.

Damit liegst du im Extremfall bei einer Reaktionszeit von schon _ca. 90ms oder mehr_, 
wobei deine Signallänge _ca._ 100ms. lang ist.

Mit dieser Konstellation kannst du nicht mehr betriebssicher jeden Eingangsimpuls erfassen.

Für Gerki wäre eine mögliche Lösung das bereits mehrfach angesprochene 
Verlängern der Schaltfahnen, falls technisch machbar.

.


----------



## Grubba (18 Februar 2008)

@ Gerki
Falls Du die Einschaltfahnen nicht verlängern kannst (oder darfst), kannst Du den Eingangsimpuls zur Not ja auch verlängern, indem Du einen Kondensator verwendest. Dieser würde je nach Größe Deinen Eingangsimpuls verlängern.


----------



## JesperMP (18 Februar 2008)

40 ms zykluszeit ist auch ein bisschen langsahm. Ist es vielleicht ein altes 315 ?

Eine vorschlage ist den CPU zykluszeit zu abfragen, und den gröstwert zu speichern. Dies kann vielleicht erklären warum das problem sporadisch auftritt.

Eine lösungsvorschlag ist rein mechanisch. Du kannst den abtastprofil bei die bändern optimieren so das den impuls etwas verlängert wird.
Wir haben abtastplatten mit entweder viele tastscheiben, oder ein halbmond - für ein langsahmes band respektive für ein schnelles band.


----------



## Grubba (18 Februar 2008)

@ Gerki

Hab das mit dem Kondensator hier kurz angetestet. Funktioniert einwandfrei, solange Du nicht wirklich zählen mußt, sondern nur die reine Drehüberwachung brauchst. Mit einem Wert von 2-3 mikroF solltest Du hinkommen.


----------



## Grubba (18 Februar 2008)

Sorry, sollte 20-30 mikroF heißen.


----------



## Gerki (19 Februar 2008)

Ich habe es nochmal mit dem OB35 versucht ihn auf 30ms gestellt. Dort lese ich dann die Eingänge neu ein.
L PEB 5
T EB 5
usw.
Im OB 35 war dann keine Lücke in der Abfrage zu erkennen dso das ich damit Arbeiten konnte.

Viele dank nochmal an Alle Helfer

MfG Gerki


----------

