Sensor als Drehwächter

Gerki

Level-1
Beiträge
19
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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


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
 
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.
IBN-Service


:confused: :confused:
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.
 
Oder den eingang über die Interruptsteuerng abfragen...
z.B OB 40, die Eingangsbaugruppe muss aber dafür geeignet sein
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
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.
 
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?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
:confused: :confused:
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...
 
Zuletzt bearbeitet:
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...

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.
 
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?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
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...

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..
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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..

100% Ack in diesem Falle :ROFLMAO: ! Soll ja keiner Angst haben, mal was Falsches zu antworten.
 
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
 

Anhänge

  • FB121.pdf
    74,3 KB · Aufrufe: 41
  • FB122.pdf
    169,5 KB · Aufrufe: 27
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 bedenken, 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.

.
 
Zuletzt bearbeitet:
Zurück
Oben