Hallo Leute, ich hoffe das hier ist nicht Offtopic, aber mich würde mal wahnsinnig interessieren, was da so in einem CPU-Modul von einem bestimmten Hersteller mit grünem Logo so alles drinne Steckt. (Z.B. S7 317-2dp) Fragen, die mich brennend interessieren wäre z.B. - 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? - wie stellt die CPU einen "Hardwarefehler" wohlmöglich an sich selbst fest? - 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) - wie ist die ausfallsicherheit (Redundanz) bei der Hardware ausgelegt - wie ist der remanente Speicher in der CPU realisiert - wieviel RAM hat die Hardware denn wirklich (also nicht der, der dem SPS Programmierer zur verfügung steht sondern der ganze) Ich suche mich im Netzt regelrecht die Finger wund, aber finden tue ich zu diesen Themen nichts. Auch meine Suche nach einer defekten SPS war erfolglos. (konnte nur eine mit einem Brandschaden auftreiben - aber die war im warsten sinne des Wortes ausgebrannt - sprich das PCB war praktisch nicht mehr vorhaden, sonder nurnoch eine undefineirbare bröselige Angelegenheit (hab ich noch nie bei FR4 so gesehen!!!) :-() Falls jemand Infos für mich hätte - immer her damit ;-) Schönen Abend noch!
Erinner mich nächste Woche nochmal dran, auf der Arbeit hab ich die letzten Tage eine alte S-400-CPU rumfliegen sehen, ich werd dann da mal nen Blick reinwerfen. Ich hab vor ein paar Wochen auch mal eine Reglerkarte aus einem Simodrive flüchtig betrachtet, die hatte schon PC-ähnliche Züge. Mittendrin ein Prozessor, beschriftet mit Siemens und einer Typenbezeichnung, woanders finden sich Steckplätze für RAM und unbekannte, nicht vorhandene Erweiterungen.
Hallo, hier gibt es ein paar Bilder von der S7 Hardware: http://databridge.narod.ru/Hardware_S7_300/S7_300.htm und http://databridge.narod.ru/Hardware_S7_400/S7_400.htm Von der 300er Serie (315 2-DP) gibt es seit ca. einem Jahr Modelle mit besserer Performance. Ich hatte aber noch keine zum Zerlegen in den Fingern, um nachzusehen was für ein Prozessor dort aktuell verbaut wird. In manchen Modellen sitzt auch ein spezieller ASIC der direkt MC7-Code (also quasi AWL) verarbeitet.
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
Angehängte Dateien:
-
Beckhoff_BC9120_oben.jpg
970 KB -
Beckhoff_BC9120_unten.jpg
730 KB
Und im Anhang die Platinen einer Beckhoff Low-Cost SPS BC9120. Die Steuerung hat einen 2-Port Switch an Board (wird auf die Stiftleiste im Scan aufgesteckt). Ich habe die Bauteile daruf einfach mal grob gegoogelt: # Siemens Infineon SAB-C165-L25F 16-Bit CPU @25 MHz, 2 KBytes On-Chip Internal RAM # Simtek STK 2068-SF4 RAM # Beckhoff BK000A1 # Micrel KSZ8993M Integrated 3-Port 10/100 Managed Switch with PHYs # SMSC LAN91C113-NU 10/100 Non-PCI Ethernet Single Chip MAC + PHY # Samsung 746 K6X8016C3B-UF55 512Kx16 bit Low Power Full CMOS Static RAM # AMD AM29F160DT-75EF 16 Megabit (2 M x 8-Bit/1 M x 16-Bit) CMOS 5.0 Volt-only, Boot Sector Flash Memory
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?
Jetzt hab ich mir doch gerade versehentlich selber meinen Beitrag gelöscht, ... Also hier nocheinmal: --> Wie wird der "Remanente Speicher" realisiert? Ich weiß zwar nicht, wie es Siemens macht, könnte mir aber vorstellen, dass die Daten im Betrieb im RAM liegen (somit wäre das Flash vor den vielen Schreibzyklen geschützt). Im falle eines Stromausfalls werden die Daten ins Flasch kopiert (Die Spannungsversorgung der am Kopiervorgang beteiligten Koponenten wird dabei beispielsweise durch ein paar Kondensatoren aufrechterhalten) Eine andere möglichkeit wäre es beispielsweise einen Teil des RAM mittels Goldcap und Batterie/Akku zu puffern, damit er die Daten auch bei einem Stromausfall nicht verliert. Mal grob überschlagen sollten sich die Daten so über Jahre halten, ...
Autonom schrieb: > Und das Anwenderprogramm... wird das erst in das RAM geschrieben damit > es "schneller" läuft, oder kommt es immer vom Flash? Schnell und SPS sind ein Widerspruch in sich. Ne SPS nimmt man hauptsächlich, um Kontakte und Sensoren abzufragen und Relais zu schalten und Spannnungen auszugeben. Und ein Schütz sollte man nicht alle 500ms schalten, das wird es nicht lange überleben. D.h. ne SPS kann ruhig langsam sein (im ms-Bereich pro Durchlauf). Der Hauptaufwand einer SPS liegt nicht in der CPU (kann ein einfacher 8051 sein), sondern in der ordentlichen Entkopplung und Schutz der Aus- und Eingänge. Und dann bezahlt man natürlich auch für den Interpreter/Compiler, der Deinen grafischen Ablaufplan in Code umsetzt. SPS haben oftmales ne Stützbatterie, um das Program im SRAM zu halten. Optional gibt es auch Flash-Module zum Einstecken. Peter
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..
Was ist denn eigentlich Dein Bestreben ? Schwächen und Fehler bei SPS'en finden ? Für Maschinen und Vorrichtungen, die rund um die Uhr ohne Störungen laufen, sind diese allerbestens geeignet und ja wohl tausendfach bewährt. Die alljährlichen Ausflüge in die Soft-SPS PC basiert scheitert immer wieder an der Betriebssicherheit für 24h Einsatz. Also nöl net rum über Dinge die wie Danegger beschrieben eine ganze Sparte in der Automatisierung gut bedient. Kaputt kriegt und zum Stolpern bekommt man alles. Gruß Uwe
>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.
@ Autonom (Gast) >kompatibilität zu ihnen. Die wird vermutlich dann wohl einen ASIC oder >einen schnelleren Prozessor haben.. Wozu ASIC? Jeder halbwegs gescheite Mikrocontroller ist Dutzendfach schnell genug für so bissel SPS-Kram. Was macht die denn? Alle Eingänge lesen Logische Verknüpfungen berechnen Alle Ausgänge schreiben. 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. Und wozu soviel RAM? RAM raucht man nur für die Variablen, das sind nicht sooo viele. Das Programm mit den logischen Verknüpfungen kann man locker live aus einem Flash lesen, das ist mehr als schnell genug. MfG Falk
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.
Falk Brunner schrieb: > Was macht die denn? > > Alle Eingänge lesen > Logische Verknüpfungen berechnen > Alle Ausgänge schreiben. * Kommunikation über Feldbusse * Kommunikation mit Ethernet * Visualisierung * Datenverwaltung ("Rezepte") * Regelunden * Analogwertverarbeitung * Aufzeichnung von Logfiles * ...
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' .
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. Warum sollte man in einer SPS überhaupt generell in C oder Assembler verwenden? Und was passiert wenn die Gewünschte Funktion nicht als Funktionsbaustein verfügbar ist? Beten?
>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)
Assembler und C, die einzigen, wirklichen Programmiersprachen! Warum zum Teufel sollte man auf einer SPS keine andere Hochsprache verwenden?
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.
MCUA schrieb: >>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. Warum sollten sich auch? Eigentlich programmiert man ja nicht die SPS sondern schreibt ein Programm für eine Art Interpreter. Der macht die Arbeit und man braucht sich keinerlei Gedanken darüber machen, das irgendwo ein Speicher überläuft oder ein Pointer wild um sich schießt. Wenn ich einfach nur zwei Eingänge miteinander verknüpfen will KANN ich so keinen Fehler einbauen, bei Assembler oder C hat man dazu reichlich Gelegenheit. Diese Art der "Programmiersprache" wurde eben speziell für die Bedürfnisse einer SPS erdacht, so erhält man ein funktionierendes Programm in kürzerer Zeit.
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.
@ Ulli-B (Gast) >Ü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. ;-) Niemand hat behauptet, dass man mit einem uC für Eins fuffzich ganze Industriestrassen steuern kann. >So kann jeder das machen was er kann ... wo liegt das Problem und vor >allem wo liegt das Streitpotential ? - Meiner ist länger! ;-) - SPS-Programmierer sind keine richtigen Programmierer. - SPSen sind nix weiter als gepimpte Relaiscomputer. - Mir ist langweilig. Reicht die Auswahl? :-0 >Normalerweise kommen ja doch recht kompetente Antworten von Dir (ich >würde sagen ca. 98%). Vielen Dank. >Aber zu Thema SPS solltest Du Dich doch lieber zurückhalten ... >Sorry, aber das musste ich jetzt leider los werden .. Schon OK. Aber ich bin nicht der böse Theoretiker, als den du mich hier hinstellst. Ich hab auch schon mal ne SPS programmiert, so vor 15 Jahren oder so, im Abitur. Scheibchen sortieren nach dem Turm von Babel Prinzip ;-) >Ach ja noch etwas: >Beruflich programmiere ich SPSen. Also doch kein richtiger Programmierer ;-) >Privat programmiere ich AVRs. Ich auch, wenn gleich in letzter Zeit selten. MFg Falk, auch kein Programmierer, nur Hardwerker
MCUA schrieb: >>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. Man kann schon, nur nicht aus versehen. Funktionsbausteine kann man selbst Programmieren, bei Phoenix gibts dafür auch eine extra Programmiersprache, erinnert stellenweise an C. Dein Geschwindigkeitsmangel geht mir auch auf die Nerven, wenn dir DIESE SPS zu langsam ist brauchst du eben eine Schnellere, der Ersatz für eine Schützsteuerung muss garnicht so schnell sein. In CNC-Maschinen jedweder Art finden sich in der Regel kleinere oder größere Rechner die mit DSP`s aufgepimpt wurden und eine sehr enge Beziehung zu seinen Antriebsmodulen führt, die denken auch daran, die durchbiegung einer waagerecht verlaufenden Welle mit in ihre Bewegung einzurechnen. In Echtzeit, und alle Achsen koordiniert versteht sich. Gehen wir noch einen Schritt weiter, zu Industrierobotern. Kennst du dich damit ein wenig aus?
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)
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.