Innenleben einer SPS

http://www.djdoc.de/s/sps/s5/simatic-s5.html

Ja Cool,
nur eben soetwas für eine S7

Autonom schrieb:
> - wie stellt die CPU einen "Hardwarefehler" wohlmöglich an sich selbst
> fest?

Für sicherheitsrelevante Funktionen gibt es Normen dafür. Bei Microchip 
sind ein paar der Tests beschrieben:
http://ww1.microchip.com/downloads/en/AppNotes/01229A.pdf

Autonom schrieb:
> - wie wurde die enormen anforderungen an EMV/Temperatur,... realisiert
> (z.B. darf die CPU ja nicht aussteigen wenn in Ihrer Nähe riesige
> induktive Lasten geschaltet werden)

Ich weiß nicht was bei der SPS verwendet wurde. Ich würde 
Weißblechgehäuse um die kritischen Schaltungsteile bauen. Die 
Temperaturanforderungen sind ja nicht sooo hoch (im Vergleich zur 
Automobiltechnik -40 .. 85 oder 105 oder 125 Grad).


Gruß Anja

Autonom schrieb:
> Ist da eine "handelsüblich" CPU/µC ala ARM/C167/8051... oder ein
> Custom ASIC (so wie z.B. die ProfiBUS ASICs) auf dem die Programme
> laufen und wie schnell ist die?

Banales Elektronikerzeugs zwei Generationen zurück. Mehr braucht es auch 
nicht. Wenn du damit was komplexes machen willst kannst du! in der Regel 
die Siemens Hotline instruieren.


> - wie stellt die CPU einen "Hardwarefehler" wohlmöglich an sich selbst
> fest?
Na dadurch das die CPU läuft aber irgendein Bit beim Selbsttest nicht so 
toggelt wie erwartet. Wenn der Draht ab ist guckt die Möhre genau so in 
die Röhre wie der E-Mensch davor (wenn er so wenig Plan wie die SPS 
hat).


> - wie wurde die enormen anforderungen an EMV/Temperatur,... realisiert
> (z.B. darf die CPU ja nicht aussteigen wenn in Ihrer Nähe riesige
> induktive Lasten geschaltet werden)


Die fliegt dir genau so auseinander wie jedes andere Bauteil auch.
Da kochen alle mit Wasser und jedes dieser magischen Wunderwerke stirbt
wenn du Sie etwas zu sehr außerhalb der doch eher banal engen Specs
betreibst.

Die meisten Sörungen sieht so ne SPS auch gar nicht weil Sie schlicht
und ergeifend krückenlangsam ist.

Bisher habe ich jede SPS zum aussteigen, kaputgehen oder
programmverlieren gebracht, ab nun GL oder CE zertifziert, von SAG
Beckhoff oder sonstwem.

Im dicken Blechschrank in der warmen Halle mit satt 24 Volt und langen
Leitungen ist halt leicht SPSen. Im " Feld" sind die Dinger sehr
begrenzt nutzbar.

Hi
Is jetz  nich wirklich dein Ernst....
> Bisher habe ich jede SPS zum aussteigen, kaputgehen oder
> programmverlieren gebracht, ab nun GL oder CE zertifziert, von SAG
> Beckhoff oder sonstwem.
Man beachte das Wort "ich". Gestatte mir die Frage: du bist aber noch in 
Amt und Würde ?"
Bei uns gehen die Dinger höchstens von allein in die Wüste, aber wenn 
man nich grad draufrumwurschtelt und die Spec's beachtet, dann sind sie 
schon stabil. Aber im Grunde ist's schon richtig, ein PC funktioniert ja 
auch über längere Zeit. Wenn sein Leben kürzer ist, liegt's vielleicht 
am öfteren Ausschalten. Die Geschichte heiß - Kalt und Ausdehnung.....
Gruß oldmax

Genauso wie es unzählige Varianten gibt ein Gerät zu bauen, gibt es 
unzählige Varianten eine "SPS" zu bauen.
Eine "SPS" ist oft nichts anderes als ein "stinknornales Gerät", dass 
einige Bits liesst und ausgibt. ..meistens aber extrem langsam, da die 
(billigen) IEC-"Programmier"-Sprachen drin laufen , oder mit denen 
"kompiliert" wurde.

(In der S5 ein 80C535. Lachhaft.)

Danke Leute

Also ein Wunderwerk der Technik ist die SPS also eher nicht.
Das der Löwenanteil die Software einer SPS ausmacht ist mir jetzt auch 
klar.
Software kann ja soetwas von komplex sein!

Da stecken vermutlich etliche Mannjahre drinne bis man diese soweit hat 
bis auch ein Elektriker (das soll keine Beschimpfung sein!) damit 
umgehen kann.

bleiben noch 2 Frage die sich mir stellt: Wie wird der "Remanente 
Speicher" realisiert? Wenn ich bei jedem SPS-Zyklus auf ein Flasch 
schreibe, dann ist der Speicher doch relativ schnell kaput, oder nicht?

Und das Anwenderprogramm... wird das erst in das RAM geschrieben damit 
es "schneller" läuft, oder kommt es immer vom Flash?

Super!

Ich danke euch für eure wertvollen Hinweise!

bezüglich geschwindigkeit (da Geb ich Dannegger Recht!) :
Hatte neulich mal eine Vipa SPS in der Hand. Die hat werben mit einer 
zig fah höheren Arbeitsgeschwindigkeit als eine S7, aber bei voller 
kompatibilität zu ihnen. Die wird vermutlich dann wohl einen ASIC oder 
einen schnelleren Prozessor haben..

>D.h. ne SPS kann ruhig langsam sein (im ms-Bereich pro Durchlauf).
Es gibt aber auch Anforderungen, die höher sind.
...das kann man nicht allgemein sagen.
...ist eben ein riessiges Spektrum von mikrig bis sehrgross (wie 
allgemein bei Geräten auch).

Aber inbesondere kommt SPS ursprünglich daher, dass der 
Elektro-"Fachmann" nun seine Schützkontakt-Steuerungen in ein Gerät 
eingeben kann, und die Kontakte nicht verdrahten muss.  Daher auch die 
meist sehr billige "Programmiersprache" für den Geräte-"Endanwender" 
(dem C oder gar ASM ein Fremdwort ist).

Vipa SPS wird wohl eher einen herkömmlichen -eher kleineren- Prozessor 
haben als ein ASIC.
Bereits mit herkömmlichen modernen Prozessoren kann man weitaus mehr 
Leistung rauskriegen, als die Vipa-Geräte es haben.

Falk Brunner schrieb:
> Und das mit max. 100 Hz, meist deutlich weniger. Selbst ein kleiner AVR
> schafft das mal locker mit ein paar Dutzend IOs. Gabs auch mal ein
> Projekt dazu, müsste man mal suchen.

Du meinst das SPS-Ctrl?

http://www.mikrocontroller.com/de/SPS-ctrl.php

Ein AVR schafft es aber evtl nicht mehr, wenn verschiedene complexe 
Funktionsbausteine (evtl Regler usw (dann wäre sogar spez DSP 
erforderlich)) mit rein geholt wurden.
Manchmal sind es auch einige us, nicht 10ms, Zykl.Zeit.
...kommt halt drauf an, SPS kann alles sein, man kann es nicht
   verallgemeinern.
...aber denke auch, die meisten SPS-Geräte (ca < 1000eu) sind wohl
   doch recht  billige klapprige Dinger,
   die nur ein paar Kontakte simulieren.

Hi
Na ja, das geballte Wissen um eine SPS und deren Aufgaben ist ja doch 
schon einen Kommentar wert. Also, ich arbeite an mehreren Goßanlagen, 
gesteuert durch SPS Vom großen S. Langsam... na ja, sicherlich im 
ms-Bereich, je nach Programmgröße mal 2, mal 20mS. Alte Steuerungen sind 
evtl. auch noch langsamer. Aber, eine SPS ist so schnell, wie es der 
Einsatz erfordert. Wenn ich Bauteile im mm-Bereich positionieren will, 
kann ich dies nicht mit einer Zykluszeit von zig ms und einer 
Anlagengeschwindigkeit von mehreren hundert Metern in der Minute machen. 
Eine Sicherheits-SPS kann nicht erst auslösen, wenn der Kollege längst 
durch den Lichtvorhang gewandert und seine Pfoten schon in die Presse 
gesteckt hat. Es ist halt so, wie auch bei euch zu hause, manch einer 
ist noch mit einem 286 zufrieden, weil er nur Texte schreibt und einem 
anderen ist ein DualCore noch zu langsam, weil er 3 Filme auf einmal 
kopieren möchte.
Zur Speicherung: Das Programm ist eine Feste Vorgabe und kann in einem 
EEProm oder Flash liegen. Die variablen Teile eines Programmes, die Ein- 
und Ausgaben, Datenbereiche und einiges andere Zeugs liegt 
selbstverständlich im RAM, de durch eine Batterie gepuffert wird 
(Lebenszeit in der Regel 3 Jahre. Fällt wirklich einmal der Strom aus, 
so wird die Vorbesetzung von Datenbereichen aus dem Flash in den Ram 
durgeführt. Alle anderen Werte haben nach einem Zyklus sovieso erst 
gültige Werte. Aber dafür gibt es Anlaufverfahren. Und für diejenigen, 
die meinen, SPS programmieren sei Kinderkram, kommt nur und traut euch, 
ich freue mich schon auf solche Kollegen, die mal mit Links eine 
Automatik-Funktion schreiben oder einen Fehler in null komma nix aus der 
Steuerung lesen.... ich geh auch gern mal einen Schritt zur Seite und 
schaue "Fachleuten" ber die Schulter....
nun ja.... jeder hat in seinem Bereich sicherlich sein Tun, aber 
Programmiersprachen als "billig" zu bezeichnen.... na ja..  macht mal
Gruß oldmax

>Also, ich arbeite an mehreren Goßanlagen.......
Ein "Großanlage" sagt nicht die Bohne was über die nötige Rechenleistung 
aus. Es gibt "Großanlagen", da würde man die Rechenleistung für 0,50eu 
kriegen!
>aber Programmiersprachen als "billig" zu bezeichnen....
Der typische SPS-Anwender hat von einer richtigen Programmiersprache und 
bes. von ASM noch nie was gehört. (ausserdem sind ihm "ns" ein 
Fremdwort, weil er wüsste gar nicht was denn überhaupt in einer ns 
geschaltet werden soll, wo doch Relais im mehrstelligen ms-Bereich 
schalten.)
Und genau deswegen gibt es halt fertige "Funktionsbausteine" zum 
zusammen klicken.
Es gibt allerdings auch SPS-Programmier-Systeme, die auch zB in C 
progr.bar sind, aber das sind absolute Ausnahmen.

da ziehen die hersteller aber selbst gerne eine trennlinie zwischen SPS 
und Prozessleittechnik.

Mein Bestreben war es ursprünglich, heraus zu finden, wo und wie die 
Ausfallssicherheit bei industrieller Elektronik realisiert wird.

Ich arbeite im universitären Bereich und wir entwerfen diverse 
Elektroniken für Steuer.- und Regelsysteme und haben da oft halt das 
Problem, das Fehler in der Hardware nicht zur laufzeit detektiert werden 
können. Gut, wenn ein Bus gestört ist - das kriegt man schon mit. Aber 
wenn eine Hardware einen Fehler im normalen Betrieb erhält, wie soll man 
so etwas erkennen und gegenreagieren.

Und da kamm ich auf die Idee der SPS (ich will die Hardware nicht 
verwenden!), da diese eben fast alle Kriterien erfüllen.

Eine normale SPS ist gegen Hardw-Ausfälle (bsp Bit im Speicher gekippt) 
genauso wenig gefeit wie eine normale uC-Schaltung, da in einer normalen 
SPS auch nichts anderes drin sitzt.
Die angeschlossene SPS-Module gehen evtl in einen (vorher festgelegten) 
SicherheitsZustand über, wenn die SPS-CPU für eine Zeit lang nichts mehr 
"gemeldet" hat.

Ja, es gibt auch redundante SPS'en, genauso wie es redundant gebaute 
andere Geräte (evtl VME-Systeme) gibt.
Aber "SPS" sagt nichts aus über 'redundant' oder 'nicht redundant' .

>Warum sollte man in einer SPS überhaupt generell in C oder Assembler
>verwenden?
Sagt keiner. Das simple Zeugs kann auch anders "programmiert" werden.

>Und was passiert wenn die Gewünschte Funktion nicht als
>Funktionsbaustein verfügbar ist?
Einen Funktionsbaustein schreiben (mit der gleicher "Syntax" wie oben)

Es gibt eine Maschinenrichtlinie und in der letzten Änderung ist das 
Thema Sicherheits SPS stärker reglementiert worden. Das ist für 
Maschinenbauer jetzt deutlich aufwändiger, du must eine Risikoanalyse 
vorweisen und in den Sicherheitsrelevanten Bereichen z.B. spezielle 
Feldbusmodule einsetzen. Wir benutzen da Beckhoff Klemmen, die treiben 
da viel Aufwand selbst für einfache E/A Klemmen.
Die SPS die wir Nutzen ist eine Soft SPS auf X86 Hardware und nutzt 
sogar sehr viel C++ Bausteine weil damit auch komplette Messtechnik 
miterledigt wird (um den Vorteil der grafischen Programmierung zu 
Nutzen).

MCUA schrieb:
> Der typische SPS-Anwender hat von einer richtigen Programmiersprache und
> bes. von ASM noch nie was gehört. (ausserdem sind ihm "ns" ein
> Fremdwort, weil er wüsste gar nicht was denn überhaupt in einer ns
> geschaltet werden soll, wo doch Relais im mehrstelligen ms-Bereich
> schalten.)
> Und genau deswegen gibt es halt fertige "Funktionsbausteine" zum
> zusammen klicken.
> Es gibt allerdings auch SPS-Programmier-Systeme, die auch zB in C
> progr.bar sind, aber das sind absolute Ausnahmen.

Mit welchen SPS hast du denn Erfahrungen?

Richtige Programmiersprache ist ASM? Hast du dir AWL/IL überhaupt mal 
angesehen? Wo ist denn darin der Unterschied zu Assembler? Extra 
Bit-Befehle hat z.B. der 8051 auch, ansonsten sehe ich nicht was an 
Assembler so viel besser/anders ist.

Als Hochsprache gibt es ST. Ich bin zwar auch ein Fan von C, aber nicht 
ohne Grund wird in sicherheitskritischen Bereichen beispielsweise ADA 
und nicht C verwendet. Und ST hat wie ADA eine starke Anlehnung an 
Pascal.

Eine SPS macht auch noch mehr als das reine Abarbeiten des 
Programmcodes, wie Feldbuskommunikation, Programmänderungen in 
Run-Modus, Programmbeobachten zur Fehlersuche, diverse 
Diagnosemöglichkeiten etc. Es ist eben ein eigenes Betriebssystem auf 
der SPS das diese Dinge verwaltet.

Nicht ohne Grund haben sich SPS im Industrieumfeld durchgesetzt. Vor 
10-20 Jahren wollte auch noch jeder Maschinenbauer seine eigene 
"Bastel-SPS" mit einem 8051 verkaufen. Heute will den Schrott keiner 
mehr haben. Standardisierte und zuverlässige Bauteile sind gefragt.

Im übrigen: Warum überhaupt nur Nanosekunden und nicht Pikosekunden? 
Scheint für dich wohl ein Fremdwort zu sein...

Hallo Autonom,

wenn es dir um Fehlererkennung und Behandlung geht, kannst du dich im 
Automotive-Bereich umschauen. Jedes Steuergerät im Auto muss im Betrieb 
damit rechnen dass irgend etwas passiert, was nicht zum normalen Ablauf 
gehört (Kurzschlüsse, Abreißen von Verbrauchern, Verrechnen). Je größer 
die Gefahr bei Fehlern desto größer der Schaltungstechnische Aufwand 
(zb. zwei Dual-Cores bei HEVs).

Aber das wichtigste ist die Vorbereitung. Schau dir deine Grundschaltung 
an. Mach eine Liste mit möglichen Fehlern. Und dann kannst du dir auch 
Gedanken machen wie du die erkennen oder sogar vermeiden kannst. So muss 
zB bei einem Steuergerät jeder Kontakt zu seinerm Nachbarkontakt 
Kurzschlussfest sein, es könnte ja einer den Stecker reinwürgen und Pins 
verbiegen.

Als Schlagwörter kann man eigensichere FETs, Current sens, Rücklesen von 
Spannungen und/oder Strömen und auch externe Watchdogs nennen.


Gruß,
TManiac

>Wo ist denn darin der Unterschied zu Assembler?
Machst du Witze ????
----------------------
Ich habe doch erwähnt, dass es Geräte gibt, die man in C progr kann, 
aber das sind Ausnahmen.

>Eine SPS macht auch noch mehr als das reine Abarbeiten des
>Programmcodes, wie Feldbuskommunikation, Programmänderungen in
>Run-Modus, Programmbeobachten zur Fehlersuche, diverse
>Diagnosemöglichkeiten etc. Es ist eben ein eigenes Betriebssystem auf
>der SPS das diese Dinge verwaltet.
Und das schreibt alles der SPS-Anwender von Grund auf selbst ????

>Nicht ohne Grund haben sich SPS im Industrieumfeld durchgesetzt.
Nicht ohne Grund haben sich oft normale Steuer-Geräte im Industrieumfeld 
durchgesetzt. (denn eine SPS ist oft nur ein normales Steuer-Gerät)

>Vor 10-20 Jahren wollte auch noch jeder Maschinenbauer seine eigene
>"Bastel-SPS" mit einem 8051 verkaufen.
Ein Maschinenbauer baut keine SPS, er benutzt diese nur.
Und Geräte, auf denen SPS drauf steht, gibts (fast) schon so lange, wie 
es Computer gibt.
8051 ist ne olle kleine CPU, die nichts kann.

>Standardisierte und zuverlässige Bauteile sind gefragt.
Du meinst wohl standardisierte Geräte, nicht Bauteile.
(Bauteile sind ua ICs)

Hallo ihr Streithammel,

wieso müssen eigentlich immer diejenigen mit der wenigsten Ahnung die 
Klappe am weitesten aufreissen ?

Die ASM, C, usw - Programmierer würden sich schwer wundern, wie 
schwierig es ist eine Maschine, welche von Menschen bedient wird, so zu 
programmieren, dass trotzdem alles funktioniert.
Und bitte daran denken: Es hängt im Normalfall immer recht viel Mechanik 
mit dran, die auch nicht immer das macht was sie soll.

Übrigens, zeige mir doch mal einer einen µC, welcher ganz locker mal 
2048 Byte Eingänge + 2048 Byte Ausgänge + fast eine beliebige Anzahl von 
anteilig Analogen Ein- und Ausgängen (1024 Bytes E+A) managed.
Diese Daten stammen von einer Siemens 325-2PN/DP, das ist eigentlich 
eine kleine Standard-SPS. Es gibt da auch wesentlich bessere.

Wenn es dann wirklich schnell gehen soll, dann muss eben noch per 
PROFI-Bus oder sonst etwas ein Gerätchen her, welches einen µC 
beinhaltet.

So kann jeder das machen was er kann ... wo liegt das Problem und vor 
allem wo liegt das Streitpotential ?

Zur Frage der Sicherheit:
Eine normale SPS ist auch nicht sicherer als ein anderes Stück 
Elektronik.
Wenn es sicher werden soll, dann kommen redundante Systeme zum Zuge. Die 
nennen sich dann Sicherheits-SPS oder sonst irgend wie.

@Falk:
Normalerweise kommen ja doch recht kompetente Antworten von Dir (ich 
würde sagen ca. 98%).
Aber zu Thema SPS solltest Du Dich doch lieber zurückhalten ...
Sorry, aber das musste ich jetzt leider los werden ..

Ach ja noch etwas:
Beruflich programmiere ich SPSen.
Privat programmiere ich AVRs.

Schönen Feiertag noch ..
... Ulli-B

>Assembler und C, die einzigen, wirklichen Programmiersprachen!
Das sagt soch keiner!
Sagte nur, das bei SPS-Geräten norm. nur SPS-"Progr.sprachen" benutzt 
werden, die weder mit einer richtigen Hochsprache noch mit ASM etwas zu 
tun haben.

So eine Zigaretten-Bau-Maschine in der Tabakindustrie ist ja rasend 
schnell. Keine ahnung wie schnell da die Steuerung arbeitet, war 
Beckhoff verbaut. Damals in der Ausbildung hatten wir KlöMö PS3 zum 
lernen gehabt. Da konnte man eine kleine Verzögerung bei Signalsetzen 
und dem Ausgang erkennen.

Wahrscheinleich ist heute sogar eine Siemens LOGO schneller als die PS3.

>Wenn ich einfach nur zwei Eingänge miteinander verknüpfen will ....
dann kann man aber nichts komplizierteres machen, weil die "Sprache" es 
nicht zulässt.
Und selbst das simple Zeug ist evtl total langsam, weil es evtl über 
Interpreter läuft.

Hi
Leute, laßt es gut sein. Wenn ich die "Programmierer" sehe, die in 
Delphi ein paar DBEdit- oder DBGrid-, vielleicht noch ein 
DBListBox-Objekt auf ein Formular ziehen können und dann von sich 
behaupten, sie wären Datenbankprogrammierer, dann will ich dem ein- oder 
anderen hier abnehmen, seine hochgelobte "Hochsprache" sei um so vieles 
besser als ein simples AWL- Programm, was ja grad mal ein paar Schütze 
schaltet. Allein diese Aussage qualifiziert zu einem absoluten Fachmann. 
Ich bin hell begeistert. Es ist halt in einem Forum so, das hier jeder 
von sich behaupten kann, er sei der Größte, und niemand wird's 
widerlegen, bis ... ja, bis die Aussagen die Qualität zutage bringen.
Zurück zum Thema:
Also, auch eine moderne SPS merkt, wenn ein Bit kippt. Lustige Aussage, 
denn ein Bit kann nicht kippen, sondern eine Speicherzelle kann defekt 
sein. Also, eine CPU merkt sehr wohl durch interne 
Sicherheitsschaltungen, das da was faul ist und geht im schlimmsten Fall 
einfach in "Stop". Stichwort Parity Check. Das bedeutet für die Kollegen 
Schützeschalter, alles schaltet aus, Maschine steht. Na ja, ist halt 
eine intelligente Anlöage...
Nun gibt es jedoch auch Prozesse, da wäre ein solches Verhalten fatal. 
Denken wir einmal an chemische Prozesse. Da kann ein Ausfall eines 
Rührwerkes, einer Absaugvorrichtung oder eines bestimmten Ventiles zur 
Katastrophe führen. Da ist ein Versagen einer ABS-Anlage pippifax gegen. 
Also müssen je nach Gefahrengrade entsprechende Systeme eingesetzt 
werden und ob ihr's glaubt oder nicht, sowas programmiert eine 
Elektrofachkraft.....
Ne, natürlich nicht, sonst wär mir nich sehr wohl dabei.....
Gruß oldmax

>Also, eine CPU merkt sehr wohl durch interne
>Sicherheitsschaltungen, das da was faul ist und geht im schlimmsten Fall
>einfach in "Stop". Stichwort Parity Check.
- Erstens kann Parity Check schonmalgarnicht alle Fehler finden,
  Parity Check alleine ist geradezu witzig
- Zweitens ist die Frage wie oft ein Speicherchec (wenn zB mit CRC
  abgesichert) gemacht wird. (man kann den aus Zeitgründen nicht ständig
  machen und selbst dann ist auch nicht gesagt, dass man einen Bitkipper
  bemerkt
- Drittens ist es blanker Humbug zu behaupten ein Gerät (oder SPS
  genanntes  Gerät) könne jeden Fehler finden, denn es gibt, auch
  ausserhalb von Speicher. Es gibt tausende mögliche Fehlerstellen in
  einem Gerät, und es ist prizipell unmöglich jeden möglichen Fehler zu
  bemerken. Anders gesagt ein 100% sicheres Gerät kann es nie geben (nur
  Ahnungslose behaupten das)

>Also müssen je nach Gefahrengrade entsprechende Systeme eingesetzt
>werden und ob ihr's glaubt oder nicht, sowas programmiert eine
>Elektrofachkraft.....
Haha.
Die Elektrofachkraft klickt die bereits (von anderen) fertig 
entwickelten Kästchen zusammen, was nichts mit programmieren oder 
entwickeln zu tun hat. (ist nur reine Tatsache, sonst nichts)
(In einem Auto bedient der Anwender auch den Motor, ohne die 
Motor-Steuerung programmiert zu haben)