Frage an SPS Spezialisten

Und wenn die SPS "Latchet-Input" unterstützt bspw Procontic,
dann kann sie auch auf noch kürzere Pulse reagieren.

Aber grundsätzlich ist richtig das SPS eigentlich,
.. *Spagettiprogramm*-Steuerungen sind und daher sehr träge auf 
Eingangssituationen reagieren.

Das rührt von der Art und Struktur der SPS ab, da das eigentlich im 
groben Sinne, nix anderes als mit µP modernisierte Relais-Steuerungen 
sind.

dimpfelmoser schrieb:
> Kann die Eingangs- Ansprechzeit per Programm definiert verzögert werden,
> z.B. auf 10 msec. damit die 2 msec. Störimpulse wirkungslos bleiben?

Das hängt von der Steuerung und ihrer Peripherie ab. Es gibt 
Eingangsmodule die haben eine einstellbare Filterzeit.
Wenn es das nicht gibt, dann musst du das wohl ausprogrammieren. D.h. du 
misst die Zeitdauer des impulses mit einem Timer und vergleichst mit 
einem vorgegebenen Wert.
Einfach hoffen dass ein Spike nicht erkannt wird, ist pfusch. Du kannst 
natürlich auch einen Filter in Hardware vorsehen.

dimpfelmoser schrieb:
> Eigentlich geht es um Störimpulse von (lt. Scope) 2 msec. Länge,
> die NICHT erkannt werden sollen.
>
> Kann die Eingangs- Ansprechzeit per Programm definiert verzögert werden,
> z.B. auf 10 msec. damit die 2 msec. Störimpulse wirkungslos bleiben?

In einer Schleife z.B. 5x abfragen. Wenn alle fünf Abfragen True liefern 
steht das Signal 5 x Zykluszeit an und wird für gültig erklärt.
Bei einer Zykluszeit con 10ms müsste das (Eingangs-) Signal also 50 mS 
anstehen. Ein 2mS Signal wird verworfen.

Natürlich wird so der Eingang entsprechend verzögert ausgewertet.

Uwe

Patrick L. schrieb:
> Aber grundsätzlich ist richtig das SPS eigentlich,
> .. *Spagettiprogramm*-Steuerungen sind und daher sehr träge auf
> Eingangssituationen reagieren.

Quark. Wenn man nicht vollkommen verpeilt ist und weiß was man tut, hat 
auch eine SPS eine garantierte Zykluszeit, in der alle Logik bzw. 
sequentiellen Automaten vollkommen unspaghettiartig ablaufen.

dimpfelmoser schrieb:
> Kann die Eingangs- Ansprechzeit per Programm definiert verzögert werden,
> z.B. auf 10 msec. damit die 2 msec. Störimpulse wirkungslos bleiben?

Murks. Denn nur weil der Puls kürzer als die Zykluszeit ist, heißt das 
NICHT, daß die SPS die SICHER NICHT sieht! Wenn der Störpuls gerade zum 
Abtastzeitpunkt der Eingänge anliegt, sieht die SPS den Puls. Wenn man 
das SOLIDE verhindern will, braucht es entweder einen externen Filter in 
Hardware oder intern in Software, siehe Entprellung.

c-hater schrieb:
>> In einer Schleife z.B. 5x abfragen. Wenn alle fünf Abfragen True liefern
>
> Du hast keinerlei Ahnung von der Funktionsweise einer SPS.

Bei dir scheint es nicht soooo vuiel besser zu sein.

> Die tastet mit ihrer (je nach Codegehalt variablen) Zykluszeit ab

Einspruch! Eine SPS kann sehr wohl mit KONSTANTER Zykluszeit arbeiten! 
Nicht jeder Murks mit einer überfahrenen, überlasteten SPS ist der 
Normalfall.

> und
> die Anwender-Software interagiert nur mit dem eingefrorenen Zustand der
> letzten Abtastung.

Ja und? Das macht auch jeder Mikrocontroller, nur daß die Abtastfrequenz 
meist gleich der CPU-Frequenz ist. Und auch in einer SPS kann man über 5 
Zyklen ein Eingangssignal abtasten und speichern und dann eine 
Mehrheitsentscheidung durchführen.

> D.h.: für alles an Signalen, was kürzer ist als 1/2 der Zykluszeit, kann
> oder wird bei deinem Ansatz völlig unbrauchbarer Mist rauskommen...

Nö. Das ist ja der Witz einer Entprellung, daß eben die kurzen Pulse 
SICHER vermieden werden.

Falk B. schrieb:
> Quark. Wenn man nicht vollkommen verpeilt ist und weiß was man tut, hat
> auch eine SPS eine garantierte Zykluszeit, in der alle Logik bzw.
> sequentiellen Automaten vollkommen unspaghettiartig ablaufen.

Eine Standard SPS arnbeitet das Programm immer Zyklisch vom Anfang zum 
ende durdch es gibt eigentlich keine GOSUB und RETURN in dem sinne.

Es gibt zwar Steuerungen die Funktionen und Unterprogramme unterstützen, 
aber das sind dann keine eigentliche SPS mehr.

Auszug aus WPA:
Eine große Gruppe der SPS-Geräte arbeitet zyklusorientiert, also streng 
nach dem EVA-Prinzip. Das vom Hersteller fest eingespeicherte 
Betriebssystem kontrolliert diesen Zyklus. Nach Feststellung der 
Betriebsbereitschaft aller angeschlossenen Baugruppen wird das 
Prozessabbild aller Eingänge aktualisiert. Das bedeutet häufig den 
Status aller Eingangskarten abzufragen. Danach gibt das Betriebssystem 
die Kontrolle an das Anwenderprogramm ab. Dieses hat als Ergebnis das 
Prozessabbild der Ausgänge. Nun geht die Kontrolle an das Betriebssystem 
zurück. Das Prozessabbild der Ausgänge wird an die Peripherie 
übertragen. Das bedeutet häufig die Ansteuerung der Ausgangskarten. Und 
dann beginnt der Zyklus von vorne. Typische Zykluszeiten liegen zwischen 
einer und zehn Millisekunden. Bei leistungsstärkeren Modellen oder 
kleinen Programmen kann diese auch im Bereich von 100 µs liegen. Es gibt 
Ausführungen mit festem und solche mit asynchronem Zyklus. Das 
Anwenderprogramm kann Verzweigungen und bedingte Aufrufe beinhalten, was 
unterschiedliche Laufzeiten zur Folge hat.

c-hater schrieb:

>Die tastet mit ihrer (je nach Codegehalt variablen) Zykluszeit ab und
> die Anwender-Software interagiert nur mit dem eingefrorenen Zustand der
> letzten Abtastung.
>
Man kann auch extra Tasks dafür einsetzen, die sind dann genau. Musste 
man früher mal bei der seriellen bei Wago machen, da der Puffer zu klein 
war.


PS: Allerdings hatte ich bei Wago auch mal Zykluszeiten von 30s. Obwohl 
das Programm vorher monatelang lief.

Und genau das will man eigentlich im Prozess vermeiden,
unterschiedliche Laufzeiten
Deshalb ist die Standard SPS ja Spagetti also Zyklusorientiert.
Es wäre Katostrophal wenn als Beispiel eine Abfüllanlage aus dem Zyklus 
gerät, dann wär wohl das Bier(oder was auch immer) plötzlich neben der 
Flasche :-D

Patrick L. schrieb:
> Und genau das will man eigentlich im Prozess vermeiden,
> *unterschiedliche Laufzeiten*
> Deshalb ist die Standard SPS ja Spagetti also Zyklusorientiert.

Der Zyklus ist immer gleich. Allerdings, je mehr Code so länger.
Eine Schleife z.B. wird in jedem Zyklus nur einmal durchlaufen.
Will man kürzere Reaktion muß man mit mehreren Tasks arbeiten.
Kann aber nicht jede SPS.
Das hat nichts mit Spagetti zu tun sondern ist eine wichtige Eigenschaft 
der SPS - Technik.

Uwe

c-hater schrieb:
> Uwe B. schrieb:
>
>> In einer Schleife z.B. 5x abfragen. Wenn alle fünf Abfragen True liefern
>
> Du hast keinerlei Ahnung von der Funktionsweise einer SPS.

Du bist aber schnell zu dem Ergebnis gekommen...

> D.h.: für alles an Signalen, was kürzer ist als 1/2 der Zykluszeit, kann
> oder wird bei deinem Ansatz völlig unbrauchbarer Mist rauskommen...

Nein, ein eventuell erfasstes Signal welches z.B. kürzer ist als 1/2 der 
Zykluszeit wird verworfen, = FALSE. Wenn es denn zufällig eingelesen 
wurde weil es zum richtigen Zeitpunkt anlag.

Uwe

c-hater schrieb:
> Ah ja? Dann zeig' mir doch bitte die entsprechende "Schleife", z.B. in
> AWL. In FUP oder KOP sieht es mit "Schleifen" ja sowieso von Hause aus
> eher schlecht aus...

Ich bin schon groß und darf in ST (Strukturierter Text) programmieren.

(Ich werde dazu (CodeSys) gezwungen...)

Uwe

Grummler schrieb:
> MaWin schrieb:
>
>> Offizielle Aussage von Siemens ist, AWL zu meiden und SCL
>> zu verwenden.
>> Mit Schleifen und tralala.
>
> Hmm.
> Die werden wohl wissen, warum sie das einzige Alleinstellungs-
> merkmal der SPS-Technik vorsätzlich ruinieren...

Welches genau wäre das? Und, wenn genau dieses Alleinstellungsmerkmal 
nicht unbedingt erforderlich ist: Welche Steuerungstechnik empfielst du 
dem Maschinenautomatisierer n der Industrie? Arduino?

Uwe

Sehr lustig hier. Vielleicht sollte man besser nur noch nachts bei 
blinkender Ampel über die Kreuzung tasten...

Abdul K. schrieb:
> Sehr lustig hier. Vielleicht sollte man besser nur noch nachts bei
> blinkender Ampel über die Kreuzung tasten...

Du glaubst tatsächlich daß Ampelsteuerungen aus SPS-Bausteinen 
zudammengedübelt werden?

Uwe

Denke ich, vermutlich mit eine Art framwework-Compiler, der die 
Kausalität (Aua oder nicht aua) überprüft, ja.

Uwe B. schrieb:
> Du glaubst tatsächlich daß Ampelsteuerungen aus SPS-Bausteinen
> zudammengedübelt werden?

Glaube ich nicht.
Eine Ampel in der Nähe schaltet sofort wieder auf grün, wenn man schnell 
genug die Taste drückt. War sie aber schon lange rot, muß man ewig 
warten. Da ist wohl nur ein Elko und eine Transistorschaltung drin. Die 
Wartezeit ist daher so lang, wie der Elko Zeit hatte, sich umzuladen.

Eine andere Ampel ist wohl über ein kompliziertes Datenprotokoll mit 
einer Zentrale verbunden. Nach dem Drücken dauert es mehrere Sekunden, 
bis die Taste leuchtet. Daher ist sie auch öfters mal zersplittert und 
muß ersetzt werden.

Innenansichten einer Ampelsteuerung. Schicke 19"-Eurokartentechnik. 
Stehe ich drauf :-)

Uwe

Krause schrieb:
> Bei der Siemens ET200SP-Eingangsbaugruppe, die ich mit gerade angesehen
> habe, kann man eine Eingangsverzögerung einstellen. Damit sollte es
> möglich sein, die 2ms-Impulse zu unterdrücken.

Man will aber keine Verzögerung, sondern eine Filterung zu kurzer Pulse. 
Natürlich führt diese zu einer Verzögerung, aber das ist die Folge der 
Filterung, nicht der Zweck!

Ich kann Pulse auch verzögern, ohne sie zu filtern!

kein experte schrieb:
> Uwe B. schrieb:
>
>> In einer Schleife z.B. 5x abfragen. Wenn alle fünf Abfragen True liefern
>> steht das Signal 5 x Zykluszeit an und wird für gültig erklärt.
>> [...]

> Das ist natürlich alles totale Grütze von Leuten die einer SPS nie näher
> als 10km kamen, C#+++ gerade in der Schule hatten und in der Freizeit am
> liebsten Ampelsteuerungen umfahren und erzählen, und erzählen, und
> erzählen, und erzählen, und erzählen...

Au, da hat aber jemand ganz große Probleme mit seinem Ego.

> Die Zykluszeit hat NICHTS, aber auch überhaupt nichts mit der
> Geschwindigkeit einzelner Eingänge zu tun.

Nein, natürlich nicht.

Dein Vorschlag mit dem TON-Baustein (Verzögerung, Signal muß die ganze 
Zeit anstehen) tut genau das gleiche wie mein Vorschlag mit der 
mehrfachen Abfrage in einer Schleife. Ich habe den Ansatz hier so 
gewählt um die Funktion (der Entprellung) zu verdeutlichen.
Offensichtlich reicht deine Expertise tatsächlich nicht aus das zu 
verstehen, wie dein gelungener Nick ja schon andeutet.

> Mehr dazu vielleicht vom Wahlschweizer... Ich hier nicht.

Besser ist das man.

Uwe