Wie wird in der Industrie für Automatisierung eine schnelle Regelung realisiert? Eingesetzt werden ja gerne SPS, allerdings sind die ja nicht sehr flink. Für eine exakte und dynamische Regelung gehe ich davon aus, dass hardwarenah programmiert werden muss, also mindestens in einer Hochsprache wie C, eher aber in etwas wie Assembler. Wie wird sowas aber in der Realität umgesetzt? Es wird ja doch immer auf fertige Produkte gesetzt um schnell zu automatisieren, also auf welche Hardware greift man zurück und wie wird programmiert im Maschinenbau (Stanzen, Pressen, Schneidwerkzeuge, Werkzeugmaschinen, Walzwerke, etc)? Und: Wenn man beispielsweise die Dicke von Blechen im Walzwerk regelt, setzt man hier immer noch PID-Regler (auf einem Rechner) ein oder muss man da schon mit nichtlinearer Regelungstechnik hantieren?
es gibt SPS mit analogen Eingängen, du setzt ein Regler ein der einen Analogen Wert vorgibt und schickst diesen Wert an die SPS. Ob dort wirklich PID-Regler eingesetzt werden weiß ich nicht, ich kenne das so das Hauptsächlich mit P und bisschen I geregelt wird, da der D anteil doch recht kritisch sein kann in einem Regelkreis
Sehr interessante Frage, habe in Stahlwerken Praktika gemacht und aber dann in Logistik gearbeitet. In der Intralogistik sind SPSen eingesetzt worden (Fördertechnik usw.), die wurden über C/C++ angesteuert (eine Ebene darüber). Habe in den Stahlwerken auch viele SPSen gesehen, dazu später mehr, schreib grad mit Handy..
Hallo, für diese Zwecke sind die SPS schon noch schnell genug, gibt ja auch noch die erweiterten Technologiebaugruppen (z.B. bei Siemens). Diese sind dann für spezielle Anwendungen optimiert und konzipiert. Die bieten dann fertige Programmcodes für fliegende Scheren (schneiden von bewegten Objekten an definierten Punkten, mit anpassen der Schneide an die Bewegung der Objekte), Mischkreise (Pharmaindustrie, Lebensmittel,...). Die nächste Stufe sind dann Baugruppen mit integrierten PC-Systemen, die kommen dann bei Anwendungen wie Videogestützter Auswertung zum einsatz. Diese Baugruppen werden nur noch parametriert und arbeiten fast autark zum restlichen Programmzyklus. Zusätzlich kannst du die Prozessabbilder ja nicht nur am Anfang und Ende des Zykluses einlesen/ausgeben, sondern auch azyklisch aktualisieren. Dadurch bist du ja von den zykluszeiten unabhängig (bei 10 ms Zykluszeit wirst du ja schon argwöhnisch beäugt bei ner SPS, weil was nicht stimmen kann). Wenn es richtig schnell gehen muss, wechselt man die Leistungsklasse der SPS. (bei Siemens z.B. von S7-300 zu S7-400). Die meisten Programmbausteine (ob nu FUP oder CFC) sind mittlerweise auf SCL basierend. MfG
Hab grad gemerkt, dass ich ne "0" vergessen hab, sollte "100ms Zykluszeit" heißen... Sry
Ist SPS programmieren nicht eher was für Elektriker geworden und weniger etwas für Akademiker dh ETler? Akademiker werden da eher weniger eingesetzt oder?
Elektriker bekommen die 100ms Zykluszeit hin. Erfahrene Programmierer (manchmal Akademiker) auch <10ms.. wenn das System nit schon vorher durch "ökonomische Aspekte" kastriert wurde ;)
Die meisten Hersteller hatten schon vor 20 Jahren fertige, relativ schnelle Regler in ihren SPSen. Als geschlossene Module. Die konnte auch ein "normaler" Elektriker, mit ein bisschen Mathematikkenntnissen und etwas Gefühl fürs Feine, in Gang setzen. Heute sind die lediglich noch komfortabler und viel schneller geworden. Wer will kann auch seine Algorithmen am PC entwickeln (Mathlab) und anschließend in die SPS stopfen.
Helge schrieb:
>Elektriker bekommen die 100ms Zykluszeit hin.
Na klar -wenn die Zykluszeit vorher durch einen Schreibtisch-Entwickler
nicht beachtet wurde und die Steuerung an die reale Anlage angepasst
werden muss. Dann sind die "Superentwickler" weit, weit weg und der
Elektriker muß die Sache geradebiegen bzw. neu schreiben.
:-(
Heutzutage werden feritige kommponenten gekauft, sprich sps, und umrichter mit integriertem Regler um einen Servo anzusteuern, diese haben dann nette features wie autotunnig (wo der regelkreis ausgemessen wird, und die entsprechenden regelpararameter selbst ermittelt werden, etc...) Zykluszeiten von naja das küzeste was ich letzhin hatte waren 125us (für einen teil einer anwendung), standart ist etwa 1ms... P.S. wer programmiert freiwillig mit siemens-schrott, wenn er nicht muss??
Mit einer richtigen SPS kann man schon viel anstellen. Wenns noch mehr sein muss kommen z.B. Realzeitrechner (Industrie-PC) zum Einsatz.
Damian schrieb: >... > P.S. wer programmiert freiwillig mit siemens-schrott, wenn er nicht > muss?? Glöckner und Möller, Wago, Phönix Contact (ja die haben auch SPSen) sind aber die Lösung? Die passende Steuerung für die jeweilige Anwendung, jeder Hersteller hat andere Vorzüge oder ist in bestimmten Fällen besser zu proggen. Oft muss auch der Bestand erweitert werden, und wenn dann dazu die dezentrale Perepherie vom gleichen Hersteller kommt erspart es oft "Probleme". Eventuell mal schlechte Erfahrungen gemacht? MfG EGS
rcc schrieb: > Wenns noch mehr > sein muss kommen z.B. Realzeitrechner (Industrie-PC) zum Einsatz. Blödsinn. Wenn wir von Antrieben reden, dann steckt die Intelligenz wenn es richtig schnell sein muss im Antriebsregler (FU, Servoregler). In der Automatisierungstechnik wird da aber nicht wirklich in C oder ASM programmiert sondern es wird etwas fertiges aus dem Regal genommen, was es für alle denkbaren Zwecke heutzutage gibt. In den Entwicklungsabteilungen der Hersteller die dann dieses Equipment liefern wird schon mit C und ASM gearbeitet.
Claus M. schrieb: > Wenn wir von Antrieben reden, dann steckt die Intelligenz wenn es > richtig schnell sein muss im Antriebsregler (FU, Servoregler). In der > Automatisierungstechnik wird da aber nicht wirklich in C oder ASM > programmiert sondern es wird etwas fertiges aus dem Regal genommen, was > es für alle denkbaren Zwecke heutzutage gibt. In den > Entwicklungsabteilungen der Hersteller die dann dieses Equipment liefern > wird schon mit C und ASM gearbeitet. Genau so habe ich mir das eigentlich auch fast vorgestellt. Allerdings laß ich vor einiger Zeit bei einem Ingenieursbüro für Automatisierungstechnik auf der Website, dass dynamische Regelungen in ANSI-C realisiert werden. Das hat mich nicht losgelassen. EGS schrieb: > Die meisten Programmbausteine (ob nu FUP oder CFC) sind mittlerweise auf > SCL basierend. Ich habe damals während der Ausbildung nur ins FUP und in AWL programmiert, wobei ich mir bei AWL immer bescheuert vorkam, ich fand es einfach umständlich größerer Netzwerke dort abzutippen. So wie ich lese ist SCL AWL am ablösen. Was ist der Vorteil, abgesehen davon, dass es mehr wie eine richtige Programmiersprache aussieht (ist glaube ich Pascal-basierend oder?) und demnach übersichtlicher gecodet werden kann?
rcc schrieb: > Mit einer richtigen SPS kann man schon viel anstellen. Wenns noch > mehr sein muss kommen z.B. Realzeitrechner (Industrie-PC) zum Einsatz. Echt? Was sind Industrie PCs zB.? Hab grad mal einiges über Siemens Leitsysteme gelesen, wie sie in Walzwerken eingesetzt werden, ich suchs mal raus. Die sind dann in verschiedene Schichten unterteilt.
> Ich habe damals während der Ausbildung nur ins FUP und in AWL > programmiert, wobei ich mir bei AWL immer bescheuert vorkam, ich fand es > einfach umständlich größerer Netzwerke dort abzutippen. > > So wie ich lese ist SCL AWL am ablösen. > Was ist der Vorteil, abgesehen davon, dass es mehr wie eine richtige > Programmiersprache aussieht (ist glaube ich Pascal-basierend oder?) und > demnach übersichtlicher gecodet werden kann? SCL oder auch ST ist Pascal ähnlich. Im Gegensatz zu AWL kann man damit schneller und effektiver Aufgaben lösen und, sofern sauber programmiert, auch besser warten. Man denke an FiFo, Berechnungen, Schleifen, State Machine ... In AWL teilweise ein Graus. Meiner Meinung nach ist AWL tod und bietet gegenüber SCL/ST keinen Vorteil.
AWL bei der Siemens ist relativ nah an der Hardware. KOP/FUP wird soweit ich weiß in AWL übersetzt vom Programmiersystem. Wenn du kurze Laufzeiten brauchst (und kleine bzw. ältere Systeme sind z.T. nit arg schnell) kannst du da noch was rauskitzeln. Mich wundert es, daß man auf einigen IEC Systemen immer das ganze Programm übertragen muß statt wie früher bei Modicon/Klaschka/Siemens nur einzelne Netzwerke. Irgendwie ist seit IEC die Bedienbarkeit und Beobachtbarkeit recht langsam geworden.
Es gibt schon ziemlich flotte SPSsen. Google z.B. mal nach "Indramotion MLC" von Bosch Rexroth. Die packt Zykluszeiten von 0,25 ms synchron zum Echtzeitfeldbus. Neben der reinen Zykluszeit ist auch wichtig, dass die Ein- und Ausgabedaten in der Peripherie konsistent und gleichzeitig gültig bzw. gelatcht werden. Die meisten SPS-Systeme übersetzen das Anwenderprogramm inzwischen auch direkt in Maschinencode und werden dementsprechend schnell abgearbeitet.
Sebastian schrieb: > Die packt Zykluszeiten von 0,25 ms synchron zum > Echtzeitfeldbus. Nicht nur Bosch Rexroth ist so schnell ^^ Genauso Systeme mit Powerlink und Profinet IRT ermöglichen Zykluszeiten unter 500µs. Unter 500µs Buszykluszeit sollte man schon genau wissen was man macht. Das beste Beispiel ist die Werbung mit 31,25µs bei Profinet. Alles nur Marketing, gibt noch nicht mal Hardware dazu. Aber wie schon von einem Vorredner angesprochen, in der Regel werden alle Schnellen Dinge dezentral erledigt. z.B.: Servocontroller oder CoProzessoren in Feldbussstationen. Bei CoProzessoren hab ich bei der letzten SPS IPC Drives was interessantes bei B&R gefunden: http://www.br-automation.com/de-at/produkte/innovationen-2014/reaction-technology/reaction-technology/
Claus M. schrieb: >> Wenns noch mehr >> sein muss kommen z.B. Realzeitrechner (Industrie-PC) zum Einsatz. > > Blödsinn. > > Wenn wir von Antrieben reden, dann steckt die Intelligenz wenn es > richtig schnell sein muss im Antriebsregler (FU, Servoregler). In der > Automatisierungstechnik wird da aber nicht wirklich in C oder ASM > programmiert sondern es wird etwas fertiges aus dem Regal genommen, was > es für alle denkbaren Zwecke heutzutage gibt. In den > Entwicklungsabteilungen der Hersteller die dann dieses Equipment liefern > wird schon mit C und ASM gearbeitet. Und wie werden aus den vielen Antrieben, Sensoren und weiteren Aktoren dann automatisierte Fertigungsstraßen mit Prozessleitung etc. etc.? Da braucht es "etwas" mehr als ein ein paar FU.
klausi schrieb: > Was sind Industrie PCs zB.? Ganz vereinfacht ein normaler x86 Prozessor in einem Rechner der für den Einsatz in der Industrie und unter Realzeitbedingungen gebaut wurde, also entsprechende Schnittstellen, Zertifizierung, Support und Teileverfügbarkeit 5-10 Jahre, eigens dafür designte Mainboards, EMV Härtung, Redundanz... SIMATIC IPC sind solche Kandidaten.
Neben den Standard SPS von den bekannten Grossen gibt es noch Software SPS wie z.B. http://www.logicals.com/products/logi.CAD/engineering/index.php?lang=DE Hier kann die Anwendung auf hohem FBS Level erstellt werden. Für eine hohe Performance können komplexe Funktionsblöcke wie Regler direkt in C/C++ programmiert werden und müssen nicht aus Primitiven Blöcken zusammengesetzt werden. Lauffähig ist soetwas dann auf Industrie-PCs mit Standard x86 Hardware.
rcc schrieb: > Da > braucht es "etwas" mehr als ein ein paar FU. Ja, das können dann aber vergleichsweise schnarchlangsame Devices sein die man dann mit so etwas simplem wie AWL programmieren kann.
Also kann ich wie folgt zusammenfassen: * Regelungen sind grundsätzlich sehr gut über SPS realisierbar. * Regelungen für Antriebe und Servoventile werden bevorzugt an entsprechende FU und Ansteuereinheiten ausgelagert. * Neben der klassischen SPS (µC-Basis) gibt es ebenso Soft-SPS-Systeme (logiCAD) die auf x86-(IPC)Systemen laufen und gegebenfalls in C/C++ umgesetzt werden können. Was es das soweit? By the way: Läuft LogiCAD später in einer Windows-Umgebung oder gibt es da 'spezielle Betriebssysteme' für?
Automat schrieb: > By the way: Läuft LogiCAD später in einer Windows-Umgebung oder gibt es > da 'spezielle Betriebssysteme' für? für eine Steuerung ist es natürlich sinnvoll ein Echzeit-OS zu benutzen, Windows CE z.B.
Beckhoff TwinCAT 3.1 z.B. kann Zykluszeiten von bis zu 50µs erreichen (mit einer Freischaltung von Beckhoff bis zu 10µs). Das Ganze läuft in einer normalen Windows 7/8 Umgebung im Kernelmode, wodurch Echtzeit erreicht wird. Allerdings ist ein Industrie PC erforderlich (wer sowas nicht kennt - einfach mal auf die Herstellerwebsiten schauen).
Werner schrieb: > Beckhoff TwinCAT 3.1 z.B. kann Zykluszeiten von bis zu 50µs erreichen > (mit einer Freischaltung von Beckhoff bis zu 10µs). Mit Twincat 3.1 ist ja auch Multicore Unterstützung gekommen. Aber was macht man mit 50µs oder gar 10µs. Wenn man bedenkt das der minimal Ethernet Frame von 72 Byte 5,76 µs braucht und das Ganze muss dann beim Katzenbus übertragen werden. Dann kommen noch so Sachen wie Zugriffszeiten bei einem normalen PC hinzu. Wenn PCI-Express auch extrem schnell ist mit Aktuell 800MB/s so hat denn noch allein von der Feldbusschnittstelle bis in den RAM einige µs Delay. Von einem Kontextwechsel will ich erst gar nicht sprechen, denn da kommen auch noch einiges an Delay. Also wie viel von den 10µs oder 50µs kann man wirklich nutzen ? Noch eins ein Industrie PC ist fast ein ganz normaler PC der einzige Unterschied ist die Umgebungstemperatur in der er arbeitet (höher als bei einem Desktop) und bessere Verarbeitung. Manche Hersteller bauen noch Spezielle Hardware wie Feldbusmaster Schnittstellen, aber die kochen auch nur mit Wasser!
Automat schrieb: > Für eine exakte und dynamische Regelung gehe ich davon aus, dass > hardwarenah programmiert werden muss, also mindestens in einer > Hochsprache wie C, eher aber in etwas wie Assembler. Nimm einen busfähigen Regler, und den parametriers du! Alles was drum läuft und langsam sein darf, also min 5-6 mal den Programmdurchlauf, dafür kann man dann SW-Regler benutzen. SW-basierte Regler sind nur so gut, wie die HW auf der sie laufen!
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.