Hallo Kann eine SPS einen 2 msec. kurzen Impuls an einem Digitaleingang fangen/registrieren? Habe gelesen, daß die Geschwindigkeit, mit der eine SPS einen Eingang abfragt von der Programmlänge abhängt, die abgearbeitet wird. Bei einem langen Programm soll die SPS langsamer als mit einem kurzen sein, da die Eingänge seltener abgefragt werden. Stimmt das?
Wen es ein Interrupt-fähiger Eingang ist, könnte es gehen, kommt auf die SPS an.
Das steht in der Beschreibung der (hier geheimen) SPS, es gibt viele unterschiedliche.
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.
:
Bearbeitet durch User
Bei den meisten Steuerungen in meiner Firma (Siemens/Rexroth u.a.) läuft die Zykluszeit so um die 20 Millisekunden. Interrupteingänge haben/benutzen wir nicht.
Danke für die Antworten. 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?
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.
:
Bearbeitet durch User
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.
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. Die tastet mit ihrer (je nach Codegehalt variablen) Zykluszeit ab und die Anwender-Software interagiert nur mit dem eingefrorenen Zustand der letzten Abtastung. 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...
Falk B. schrieb: > 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. So ist es. Darauf ist schon so mancher hereingefallen. 100 mal der gleiche Puls und nur drei mal reagiert die SPS anders. Ein SPS Zufallsgenerator.
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
:
Bearbeitet durch User
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
:
Bearbeitet durch User
Uwe B. schrieb: > 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. 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...
c-hater schrieb: > Ah ja? Dann zeig' mir doch bitte die entsprechende "Schleife", z.B. in > AWL. Offizielle Aussage von Siemens ist, AWL zu meiden und SCL zu verwenden. Mit Schleifen und tralala. 1ms bei einer 1500er ist kein Problem. Kommt drauf an, mit wievielen AG Abbildern gearbeitet wird.
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
MaWin schrieb: > Offizielle Aussage von Siemens ist, AWL zu meiden und SCL zu verwenden. > Mit Schleifen und tralala. OK, dann bitte die Schleife in SCL zur weiteren Diskussion...
Uwe B. schrieb: > Ich bin schon groß und darf in ST (Strukturierter Text) programmieren. Ok, dann bitte die Schleife in ST zur weiteren Diskussion...
Patrick L. schrieb: > Deshalb ist die Standard SPS ja Spagetti also > Zyklusorientiert. Das Wort "Spaghetti" stimmt nicht. Bei der echten klassischen Spaghetti-Programmierung kann man mittels Sprungmarken/Zeilennummern ÜBERALL hinspringen -- also im Speziellen auch rückwärts (in Richtung Programmanfang). Auf diese Art kann man (gewollt oder ungewollt) Schleifen formulieren, die eine Laufzeitgarantie schwierig bis unmöglich machen. Bei einer SPS springt man aber nur in Richtung Ende, d.h. jeder Codeabschnitt wird innerhalb eines Zyklus HÖCHSTENS ein Mal durchlaufen. Deswegen lässt sich JEDERZEIT eine obere Schranke für die Laufzeit GARANTIEREN .
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...
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
Uwe B. schrieb: > Welche Steuerungstechnik empfielst du > dem Maschinenautomatisierer n der Industrie? Arduino? https://www.controllino.com/
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
:
Bearbeitet durch User
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.
Angehängte Dateien:
Innenansichten einer Ampelsteuerung. Schicke 19"-Eurokartentechnik. Stehe ich drauf :-) Uwe
c-hater schrieb: > Uwe B. schrieb: > >> 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. > > 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... Kenn mich mit SPSen nicht aus, wuerde aber vermuten dass es dort so Art Z-Glieder (Verzoegerugsgieder) gibt. Dann den Eingang auf z.B. 4 seriell verschalteter Z-Glieder und alle Verbindungen logisch verunden (Und-Gatter). Der Ausgang ist nur dann '1', wenn der Eingang seit min. 5 Zyklen '1' ist.
Bei der Siemens S7-200 Reihe (die ich vor 20 Jahren mal einsetzte und programmierte) konnte man in der Software (MicroWin) digitale Filter zwischen 0,2 ms bis 12,8 ms einstellen. Wird, denke ich, heute nicht viel anders sein. (bin schon 'ne Weile aus diesem Tätigkeitsbreich raus)
Und, kurze Impulse konnte man damit auch erfassen. Ein Impuls am Eingang wird dabei so lange gespeichert, bis die Aktualisierung des nächsten Zyklus stattfindet. Ist für jeden einzelnen Eingang aktivierbar.
Alle sind dumm, außer Mama. Typisches Mikrocontroller.net-Nutzerverhalten. Die Antwort auf die ursprüngliche Frage ist ganz einfach: Hängt von der Hardware ab. Manche SPSen können das, andere nicht.
Angehängte Dateien:
Wie schön daß sich hier tatsächlich nur SPS-Experten zu Wort melden. Cyblord -. schrieb: > ...dann musst du das wohl ausprogrammieren. D.h. du > misst die Zeitdauer des impulses mit einem Timer und vergleichst mit > einem vorgegebenen Wert. Ok, das kann man noch so gelten lassen, auch wenn die Wortwahl nicht wirklich zum Thema SPS passt. Ich meine, oben mal das außerordentlich komplexe "ausprogrammierte Programm" dazu (rot umkringelt) in FUP Siemens-logo. ;-) 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. > Bei einer Zykluszeit con 10ms müsste das (Eingangs-) Signal also 50 mS > anstehen. Ein 2mS Signal wird verworfen. 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... Die Zykluszeit hat NICHTS, aber auch überhaupt nichts mit der Geschwindigkeit einzelner Eingänge zu tun. Mehr dazu vielleicht vom Wahlschweizer... Ich hier nicht. Maxe schrieb: > Kenn mich mit SPSen nicht aus, wuerde aber vermuten dass... Gut! Sehr gut! Dieses Satzfragment fehlt hier einigen Antworten...
Also die CPU greift ja bei "richtigen" SPSn nicht direkt auf irgendwelche Eingänge zu. Die E/A sind Modular aufgebaut und werden über Bussysteme an die CPU angebunden. Es ist also interessant wie das Eingangsmodul das Signal verarbeitet. In den Datenblättern stehen auch die entsprechenden Zeiten. Teilweise sind die auch einstellbar. Ist die Baugruppe schnell genug das "ab und zu" ein falsches Signal erfasst wird sollte man es z.B. über eine Eingangsverzögerung über mehre Zyklen entprellen. Oder vielleicht einen passenden Sensor auswählen :)
Uwe B. schrieb: > Grummler schrieb: >> Hmm. >> Die werden wohl wissen, warum sie das einzige Alleinstellungs- >> merkmal der SPS-Technik vorsätzlich ruinieren... > > Welches genau wäre das? M.E. ist das die einfache und offensichtliche Laufzeitgarantie. Mag aber wohl sein, dass ich von den "Schleifen" in ST eine falsche Vorstellung habe; ich habe nur AWL und FUP gemacht.
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. Wahlschweizer schrieb: > Und, kurze Impulse konnte man damit auch erfassen. Ein Impuls am Eingang > wird dabei so lange gespeichert, bis die Aktualisierung des nächsten > Zyklus stattfindet. Ist für jeden einzelnen Eingang aktivierbar. Solche Baugruppen sind mir zumindest bei Siemens nicht geläufig.
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.