Hallo Zusammen, Die Frage soll nicht polemisch etc. klingen, mit Sicherheit haben bekannte Hersteller wie z. B. Siemens & Konsorten ihre Daseinsberechtigung. Mich würde aber trotzdem interessieren, ob hier jemand speziell auf z. B. Open-Source Komponenten in der Automatisierungstechnik / Produktion setzt. Wie glaubt ihr, wird sich das in naher Zukunft ändern: Glaubt ihr, dass den Open-Source Komponenten die Zukunft in der Automatisierungstechnik gehört? Speziell würde mich interessieren: - Verwendet ihr in der Automatisierungstechnik z. B. schon Linux? Wie ist es da mit der Kompatibilität zu Sensoren / Aktoren bisheriger "großer" Hersteller (z. B. HMI, RFID-Lesegerät, ...)? - Was haltet ihr von Vertreibern von Open-Source Komponenten wie z. B. https://www.industrialshields.com/industrial-automation-solutions-home-20210212-lp oder https://revolution.kunbus.de/. Hat hier jemand schon mal solche Dinger getestet und kann dazu eine Meinung abgeben? - Glaubt ihr die Maschinensteuerungen werden zukünftig weiterhin mit Sprachen wie FUP AWL etc. programmiert oder geht's vielleicht mal (mMn hoffentlich) in Richtung Hochsprache wie C / C++ ,... Auch wenn das natürlich sehr allgemeine Fragen sind, würde mich da echt eure Meinung interessieren. Im besten Fall natürlich von denen, die wirklich in dieser Open-Source Ecke ihre Automatisierungsstraßen aufbauen und den Schritt bisher "nicht" bereut haben... Bin echt gespannt auf die Antworten ;) Grüße
:
Verschoben durch Moderator
Die einzig sinnvolle Antwort hier muss lauten: Das hat nichts mit https://www.mikrocontroller.net/forum/1 zutun, politische Diskussionen passen hier nicht hin. wendelsberg
Alexander M. schrieb: > Glaubt ihr die Maschinensteuerungen werden zukünftig weiterhin mit > Sprachen wie FUP AWL etc. programmiert oder geht's vielleicht mal > (mMn hoffentlich) in Richtung Hochsprache wie C / C++ ,... C-ähnliche Hochsprachen sind heute schon üblich. Das hat aber mit OSS oder nicht rein garnix zu tun. Bei Sachen wie FUP oder KOP geht es vielmehr darum, die Steuerung auch für Leute programmierbar zu machen, denen C oder erst C++ schlicht zu kompliziert ist. Das sind viele. AWL hingegen ist der Assembler der Siemens-VM. auch relativ kompliziert im Vergleich zu FUP oder KOP, aber im Vergleich zu C oder gar C++ immer noch sehr trivial. Keine 1.000 oder gar 10.000 Seiten Specs, sondern nur schlappe 30 (mit wirklich verständlichen Beispielen, rein formal ausgedrückt, wie die gräßlichen C- oder C++-Specs sind es sogar nur sehr bescheidene VIER Seiten). > Bin echt gespannt auf die Antworten ;) Troll!
Hi Nun, ob Open Source bei Maschinensteuerungen möglich sind, keine Ahnung, aber auf jeden Fall ist da ein erweiterter Sicherheitsaspekt zu beachten, und da bin ich mir nicht sicher, ob das mit Open Source Angeboten wirklich günstiger werden würde. Aber meiner Meinung nach werden auch keine Programme in "Hochsprachen" zum Einsatz kommen. Schließlich muß eine Wartbarkeit von den Technikern möglich sein, und glaub mir, die haben schon mit AWL große Probleme. FUP und noch besser SCL, also grafsche Programmierung, das geht und ist auch für die "einfachen" Techniker händelbar. Es ist aber denkbar, das Teilsysteme mit einer eigenen festen Funktionalität und einem begrenzt wartbaren Programm (Fehlermeldungen, Betriebs- und Meßwertanzeige) zum Einsatz kommen, deren Programmierung in C oder anderen Sprachen vorgenommen wird. Gruß oldmax
:
Bearbeitet durch User
In meinem Fachbereich (Java Backend) ist Open-Source allgegenwärtig - egal in welcher Firma. Man nutzt viel Open-Source und veröffentlicht so gut wie gar nichts. Solange man die Software im Hause behält und die Maschinen als Dienstleistung für den Kunden betreibt, erfüllt das die üblichen Lizenzen (GPL, LGPL, etc). Aber nicht alles darf man so nutzen. Da stehen ganz klar kommerzielle Interessen im Fokus.
Martin V. schrieb: > Hi > > Nun, ob Open Source bei Maschinensteuerungen möglich sind, keine Ahnung, > aber auf jeden Fall ist da ein erweiterter Sicherheitsaspekt zu > beachten, und da bin ich mir nicht sicher, ob das mit Open Source > Angeboten wirklich günstiger werden würde. > Aber meiner Meinung nach werden auch keine Programme in "Hochsprachen" > zum Einsatz kommen. Schließlich muß eine Wartbarkeit von den Technikern > möglich sein, und glaub mir, die haben schon mit AWL große Probleme. FUP > und noch besser SCL, also grafsche Programmierung, das geht und ist auch > für die "einfachen" Techniker händelbar. > Es ist aber denkbar, das Teilsysteme mit einer eigenen festen > Funktionalität und einem begrenzt wartbaren Programm (Fehlermeldungen, > Betriebs- und Meßwertanzeige) zum Einsatz kommen, deren Programmierung > in C oder anderen Sprachen vorgenommen wird. > > Gruß oldmax Danke. Warum könnte es denn deiner Meinung nach da ein erhöhtes Sicherheitsrisiko geben? --> mehr Leute als Community = weniger Fehler Gibt es aber vielleicht auch genau die Probleme, weil eben mit AWL etc. programmiert wird. So bekommen die Programmierer ja überhaupt nie die Change, mal hinter die Kulissen schauen zu können...(Naja, aber das ist dann doch ein anderes Thema) Grüße
Alexander M. schrieb: > Speziell würde mich interessieren: > - Verwendet ihr in der Automatisierungstechnik z. B. schon Linux? Was meinst du, womit SpaceX fliegt?
Stefan ⛄ F. schrieb: > In meinem Fachbereich (Java Backend) ist Open-Source allgegenwärtig - > egal in welcher Firma. Man nutzt viel Open-Source und veröffentlicht so > gut wie gar nichts. > > Solange man die Software im Hause behält und die Maschinen als > Dienstleistung für den Kunden betreibt, erfüllt das die üblichen > Lizenzen (GPL, LGPL, etc). Aber nicht alles darf man so nutzen. > > Da stehen ganz klar kommerzielle Interessen im Fokus. Okay. Aber das ist ja dann doch ein bisschen weiter weg zur klassischen Automatisierungstechnik, indem Sensoren ausgewertet und Aktoren geschaltet werden sollen...
Alexander M. schrieb: > Danke. Warum könnte es denn deiner Meinung nach da ein erhöhtes > Sicherheitsrisiko geben? --> mehr Leute als Community = weniger Fehler Das ist eine Milchmädchenrechnung, die noch nie in der Geschichte von OSS wirklich funktioniert hat. > Gibt es aber vielleicht auch genau die Probleme, weil eben mit AWL etc. > programmiert wird. So bekommen die Programmierer ja überhaupt nie die > Change, mal hinter die Kulissen schauen zu können... Weiter als mit AWL kann man überhaupt nicht hinter die Kulissen schauen. Genau wie man auf jedem beliebigen anderen Target nicht weiter hinter die Kulissen schauen kann als mit dem Assembler des jeweiligen Target. Dein Problem ist: du hast kein Verständnis, wie Assembler funktioniert. Du bist ein C-Only-Typ. Also strukturell ganz erheblich behindert...
Wolfgang schrieb: > Alexander M. schrieb: >> Speziell würde mich interessieren: >> - Verwendet ihr in der Automatisierungstechnik z. B. schon Linux? > > Was meinst du, womit SpaceX fliegt? Ich meinte, ob hier jemand bereits in der Industrie-Automatisierung, solche Sachen verwendet im Vergleich zu z. B. einer Siemens SPS, usw... um damit evtl.: 1. Kosten zu sparen 2. Vorteile zu sehen in der Wartbarkeit 3. Weil er gute Erfahrungen gemacht hat mit bereits bestehenden Komponenten 4. er Hochsprachen als effizienter ansieht als klassische SPS Programmiersprachen 5. er Open Source eher in Zukunft in solchen Bereichen sieht Dass viele kommerzielle Produkte auf Open-Source Komponenten bestehen, ist mir schon bewusst.. Grüße
hier etwas zum schmunzeln dazu, also Lizenzen genau durchlesen https://thenewstack.io/the-open-source-lesson-of-the-linksys-wrt54g-router/
Wolfgang schrieb: > Alexander M. schrieb: >> Speziell würde mich interessieren: >> - Verwendet ihr in der Automatisierungstechnik z. B. schon Linux? > > Was meinst du, womit SpaceX fliegt? Natürlich Linux mit PREEMPT_RT patch. Ohne Linux wäre die Erde komplett dunkel. Und das Weltall bald auch... ;) "For some level of scope on Starlink, each launch of 60 satellites contains more than 4,000 Linux computers. The constellation has more than 30,000 Linux nodes (and more than 6,000 microcontrollers) in space right now. And because we share a lot of our Linux platform infrastructure with Falcon and Dragon, they get the benefit of our more than 180 vehicle-years of on-orbit test time. – Matt" https://www.reddit.com/r/spacex/comments/gxb7j1/we_are_the_spacex_software_team_ask_us_anything/
Alexander M. schrieb: > Okay. Aber das ist ja dann doch ein bisschen weiter weg zur klassischen > Automatisierungstechnik, indem Sensoren ausgewertet und Aktoren > geschaltet werden sollen... Ja das stimmt. Ich wollte damit nur klarstellen, dass die Qualität Open-Source kein Show-Stopper sein muss.
Ich hab mir einiges an open source oder von newcomer-Herstellern angesehen. Das war eher nicht begeisternd. Steuerungen müssen industrietauglich sein, Protokolle wie Profinet (Master und Slave) und weitere beherrschen, um überhaupt einsetzbar zu sein. Von der reinen Rechenleistung wär was mit RPi schon Ok, drunter eher nicht. Dann müssen Steuerungen Diagnosemöglichkeiten haben und on the fly umprogrammierbar sein. Ich werd mir nicht leisten, daß irgendeine Stufe einer verketteten Produktionsanlage 3 Minuten das neue Programm reinlädt. Der zweite Komplex ist Gewährleistung. Wenn mir irgendwas stirbt, was mit Schneider oder Siemens nicht stirbt (oder die Lebensdauer der Komponenten eher so 2 Jahre - 1 Tag ist), wird das sehr schnell sehr teuer. Der dritte Komplex ist Verfügbarkeit von Ersatzteilen. Mir hilft die beste open source Platine nix, wenn ich die erst fertigen und bestücken muß. Bis dahin können schon paar hunderttausend Verlust durch Produktionsausfall zusammenkommen. Dann der Bereich Sicherheitskomponenten. Da können die versiertesten Leute was zambaun und das funktioniert auch sicher super, aber da ist kein Stempel drauf. -- Das soll kein bashing sein. Schaun mer mal in 5 Jahren, vielleicht siehts dann schon ganz anders aus.
Wolfgang schrieb: > Alexander M. schrieb: >> Speziell würde mich interessieren: >> - Verwendet ihr in der Automatisierungstechnik z. B. schon Linux? > > Was meinst du, womit SpaceX fliegt? Mit RT11
Stefan ⛄ F. schrieb: > Alexander M. schrieb: >> Okay. Aber das ist ja dann doch ein bisschen weiter weg zur klassischen >> Automatisierungstechnik, indem Sensoren ausgewertet und Aktoren >> geschaltet werden sollen... > > Ja das stimmt. Ich wollte damit nur klarstellen, dass die Qualität > Open-Source kein Show-Stopper sein muss. Ja da hast du schon Recht.
Alexander M. schrieb: > Dass viele kommerzielle Produkte auf Open-Source Komponenten bestehen, > ist mir schon bewusst.. > > Grüße Sogar in großem Stil, das steigert den Profit! Evtl. noch minimal angepasst...
Helge schrieb: > Ich hab mir einiges an open source oder von newcomer-Herstellern > angesehen. Das war eher nicht begeisternd. Steuerungen müssen > industrietauglich sein, Protokolle wie Profinet (Master und Slave) und > weitere beherrschen, um überhaupt einsetzbar zu sein. Von der reinen > Rechenleistung wär was mit RPi schon Ok, drunter eher nicht. Dann müssen > Steuerungen Diagnosemöglichkeiten haben und on the fly umprogrammierbar > sein. Ich werd mir nicht leisten, daß irgendeine Stufe einer verketteten > Produktionsanlage 3 Minuten das neue Programm reinlädt. > Der zweite Komplex ist Gewährleistung. Wenn mir irgendwas stirbt, was > mit Schneider oder Siemens nicht stirbt (oder die Lebensdauer der > Komponenten eher so 2 Jahre - 1 Tag ist), wird das sehr schnell sehr > teuer. > Der dritte Komplex ist Verfügbarkeit von Ersatzteilen. Mir hilft die > beste open source Platine nix, wenn ich die erst fertigen und bestücken > muß. Bis dahin können schon paar hunderttausend Verlust durch > Produktionsausfall zusammenkommen. > Dann der Bereich Sicherheitskomponenten. Da können die versiertesten > Leute was zambaun und das funktioniert auch sicher super, aber da ist > kein Stempel drauf. > -- > Das soll kein bashing sein. Schaun mer mal in 5 Jahren, vielleicht > siehts dann schon ganz anders aus. Danke für deine Meinung. Da stimme ich dir schon zu. Das Problem ist da aber da doch, dass aktuell keine Veränderung stattfindet, weil einfach bisher immer schon auf den jeweiligen Plattformen gearbeitet wurde. Unabhängig ob vielleicht andere Wege besser wären... Das finde ich persönlich irgendwie extrem schade / ärgerlich...
Alexander M. schrieb: > Ich meinte, ob hier jemand bereits in der > Industrie-Automatisierung, solche Sachen verwendet > im Vergleich zu z. B. einer Siemens SPS, usw... > um damit evtl.: > 1. Kosten zu sparen > 2. Vorteile zu sehen in der Wartbarkeit > 3. Weil er gute Erfahrungen gemacht hat mit bereits > bestehenden Komponenten > 4. er Hochsprachen als effizienter ansieht als > klassische SPS Programmiersprachen > 5. er Open Source eher in Zukunft in solchen Bereichen > sieht Bei allem Respekt, aber ich weiss nicht, auf welchem Traumschiff Du so zu Hause bist. Gehen wir mal ein paar Punkte durch: > 1. Kosten zu sparen Komisch. Wieso fragt eigentlich nie jemand "Möglichst oft möglichst großen Schaden zu verursachen?" Möchtest Du tatsächlich der versammelten Mannschaft aus der Werkstatt, die gerade eine Rundtischmaschine mit acht Stationen zur Konfektionierung von Steck- verbindern gebaut hat, erklären: "Tja, Leute, tut mir leid... die 100'000-Euro-Kiste ist jetzt leider Schrott, weil ich statt einer Siemens-SPS für 5'000 Euro einen Arduino für 5 Euro als Steuerung verwenden wollte"? > 2. Vorteile zu sehen in der Wartbarkeit Welche sollten das sein? "Oh... schade... den neuen Endlagenschalter kann ich jetzt gerade nicht in Betrieb nehmen... die Arduino-IDE ist abgek*ckt und hat die Quelltexte mitgerissen!" > 4. er Hochsprachen als effizienter ansieht als > klassische SPS Programmiersprachen Wer das so sieht, hat m.E. von Steuerungsprogrammierung keine Ahnung. "Normale" Programmiersprachen dienen der Implementierung von ALGORITHMEN, also von Vorschriften, die mit endlich vielen Schritten zum Ergebnis führen. Die Turing-Maschine als Modell arbeitet sequenziell und kennt nur INNERE Zustände. Deswegen funktionieren klassische Programmiersprachen schon für GUIs nicht gut, weil ein GUI auf Signale von AUSSEN reagieren muss. Gottseidank hat der Mensch aber nur EIN Gehirn und kann sich zu jeder Zeit nur auf eine Sache konzentrieren. Bei Maschinensteuerungen wird das zum Problem, weil die Abläufe an verschiedenen Stationen derselben Maschine relativ unabhängig voneinander sind (und auch unabhängige Fehlerzustände haben). Die Steuerung muss also von vornherein quasi-parallel arbeiten und für alle Aktionen immer alle blockierenden Bedingungen im Blick haben. "Hochsprachen" haben hier keinen Vorteil. Man kann die hundertmalige Wiederholung derselben Aktion der Maschine nicht mit einer for-Schleife ausdrücken.
Helge schrieb: > Von der reinen Rechenleistung wär was mit RPi schon > Ok, drunter eher nicht. War das nicht der Raspberry Pi, den man nicht mit Blitzlicht fotografieren durfte, weil der dann aufgrund der Fehlfunktion eines Spannungsreglers abgestürzt ist? Was hat das in einer Industrieumgebung zu suchen?
Alexander M. schrieb: > Glaubt ihr, dass den Open-Source Komponenten die Zukunft in der > Automatisierungstechnik gehört? "Die Zukunft" wohl nicht, aber es ist ein Pluspunkt wenn die Software einer Komponente open ist, also im Source verfügbar ist. Dann kann man die Qualität kontrollieren und auch mal Anpassungen machen die oft auf vorhandener Hardware spotteinfach sind hingegen durch Ergänzung mit zusätzlicher Hardware auf der dann das irgendwie unpassende doch noch nachträglich irgendwie hingedengelt werden muss a pain in the ass, ähnlich bei Software dem Drumrumprogrammieren um Fehler in anderen Modulen. Frei verfügbare Software löst auch das Problem, welches auftritt, wenn der Anbieter vom Markt verschwindet. Aus verfügbarer Hardware mit offener Software wächst auch mehr, als wenn alles closed source ist. Beispiel GRBL, was es da inzwischen an Anwendungen von Fräsen über Lasergravierer über Plasmacutter oder Plottern "auf der Oberfläche von Eiern" gibt, mit Erweiterungen wie Werkzeugwechsel und Heightmaps, ist erstaunlich. Bankautomatenaufsteller hätten wohl auch nicht das Problem gehabt, in das sie mit Windows XP gelaufen sind, wenn sie Linux verwendet hätten. Und ein Bekannter hat seinen Staubsaugroboter übernommen, der dankenswerterweise ein Linux nutzt, nun nicht mehr nach Hause telefoniert, dafür endlich seine Ladestation findet bevor der Akku leer ist. Also: vollständig dokumentierte, 'offene' Hardware und Software bringt wieder den Zustand zuruck, als Geräte und Werkzeuge noch ohne Software und dafür aufschraubbar und inspizierbar waren: solche wartbare Technik lebt ggf. bis heute weil sie auch ohne existierenden Hetsteller(support) repariert werden kann. https://youtu.be/gMvVGF7AkTk
Es gibt mittlerweile mehrere Visualisierungen in JavaScript/TypeScript. Ich habe noch kein JS/TS Programm gesehen das nicht 'Standard' Module verwendet, also ist hier jede Menge OpenSource drin. SoftSPS laufen auch auf Basis Linux, das ist damit dann auch in vielen Steuerungen drin.
MaWin schrieb: > "Die Zukunft" wohl nicht, aber es ist ein Pluspunkt wenn die Software > einer Komponente open ist, also im Source verfügbar ist. Fast alles im Steuerungsbereich ist so gesehen "Open Source", zumindest aus Sicht des Endkunden. Niemand kauft eine Anlage für Tausende oder gar Hunderttausende Euro ohne die Originalprojekte der Steuerung(en) vom Lieferanten als unverzichtbare Doku einzufordern. Und zu bekommen. Das ist absoluter Usus. Der, der dafür bezahlt, kriegt also "Open Source". Nassauer hingegen bleiben draussen. Das Konzept finde ich garnicht so schlecht...
c-hater schrieb: > Fast alles im Steuerungsbereich ist so gesehen "Open > Source", zumindest aus Sicht des Endkunden. Sicher nicht. Du bekommst weder Schaltplan noch Layout noch Firmware der S700, die in Deiner Maschine steckt. Wie die Feldbusse im Detail arbeiten, bleibt Dir auch verborgen. (Das ist die Ebene, um die es hier geht.) Du bekommst einen Klemmenplan, welcher Sensor/Aktor Deiner Maschine an welche Klemme von welchem Buskoppler angeschlossen ist, Du bekommst (vielleicht) eine Beschreibung der Konfiguration Deiner SPS, und Du bekommst Zugriff auf das SPS-Programm. Um Deine Maschine am Laufen zu halten, genügt das ja auch. > Der, der dafür bezahlt, kriegt also "Open Source". Nix "Open Source". Dein Lieferant wird Dir schön auf's Dach steigen, wenn er mitbekommt, dass Du sein Steuerungsprogramm munter an Dritte weiter- vertickst...
Egon D. schrieb: > War das nicht der Raspberry Pi, den man nicht mit > Blitzlicht fotografieren durfte, weil der dann aufgrund > der Fehlfunktion eines Spannungsreglers abgestürzt ist? Der Spannungsregler hatte keine Fehlfunktion. Der war extra so gebaut. Es wurden nur die Falschen für die Produktion des Raspi geliefert.
Alexander M. schrieb: > Helge schrieb: >> Ich hab mir einiges an open source oder von newcomer-Herstellern >> angesehen. Das war eher nicht begeisternd. Steuerungen müssen >> industrietauglich sein, Protokolle wie Profinet (Master und Slave) und >> weitere beherrschen, um überhaupt einsetzbar zu sein. Von der reinen >> Rechenleistung wär was mit RPi schon Ok, drunter eher nicht. Dann müssen >> Steuerungen Diagnosemöglichkeiten haben und on the fly umprogrammierbar >> sein. Ich werd mir nicht leisten, daß irgendeine Stufe einer verketteten >> Produktionsanlage 3 Minuten das neue Programm reinlädt. >> Der zweite Komplex ist Gewährleistung. Wenn mir irgendwas stirbt, was >> mit Schneider oder Siemens nicht stirbt (oder die Lebensdauer der >> Komponenten eher so 2 Jahre - 1 Tag ist), wird das sehr schnell sehr >> teuer. >> Der dritte Komplex ist Verfügbarkeit von Ersatzteilen. Mir hilft die >> beste open source Platine nix, wenn ich die erst fertigen und bestücken >> muß. Bis dahin können schon paar hunderttausend Verlust durch >> Produktionsausfall zusammenkommen. >> Dann der Bereich Sicherheitskomponenten. Da können die versiertesten >> Leute was zambaun und das funktioniert auch sicher super, aber da ist >> kein Stempel drauf. >> -- >> Das soll kein bashing sein. Schaun mer mal in 5 Jahren, vielleicht >> siehts dann schon ganz anders aus. Ja, genau, so sieht die Realität aus. Alle Sonder-Sachen sind schlussendlich viel zu teuer. Weil man braucht für die Inbetriebnahme meist zig mal mehr Zeit, hat an allen Ecken und Enden irgend welche Einschränkungen und wehe es geht was kaputt. Und wer die Sicherheitstechnik (z.B. Nothalt und Schutztürkreis) mit Selbst-Bastel-Lösungen ohne Stempel erstellt, der steht im Prinzip jetzt Schon im Knast. Moderne Siemens-Steuerungen können die Sicherheitstechnik gleich mit übernehmen, dazu braucht man keine extra Steuerung einbauen, und das spart wiederum Geld. > Danke für deine Meinung. > > Da stimme ich dir schon zu. Das Problem ist da aber da doch, dass > aktuell keine Veränderung stattfindet, weil einfach bisher immer schon > auf den jeweiligen Plattformen gearbeitet wurde. Unabhängig ob > vielleicht andere Wege besser wären... > Das finde ich persönlich irgendwie extrem schade / ärgerlich... Ich finde das überhaupt nicht ärgerlich. Siemens war schon vor 30 Jahren gut und hat einfach funktioniert, so ist es auch heute. Und wenn ein anderer Techniker/Monteur das übernehmen muss weil der eine in Rente geht, dann hat es der Nachfolger einfacher, da alles standardisierte Technik ist. Daher: Ich ärgere mich wenn ich solch spezielle Technik auch nur schon anschauen muss ... für den eigentlichen Kunden der da was repariert haben möchte ist das dann zig mal teurer. Falls der überhaupt einen findet der das dann noch richten kann, muss der sich erst mal da einarbeiten. Daher: Alle Kunden die nur einen funken Verstand haben werden solche Lieferanten von "komischer" Technik achtkant rausschmeißen. Wer das unbedingt dennoch nutzen möchte: Nutzt das für eure private Aquariumsteuerung - wo es eigentlich egal ist wenn die Technik versagt.
Hi Alexander M. schrieb: > Martin V. schrieb: >> Hi >> >> Nun, ob Open Source bei Maschinensteuerungen möglich sind, keine Ahnung, >> aber auf jeden Fall ist da ein erweiterter Sicherheitsaspekt zu >> beachten, und da bin ich mir nicht sicher, ob das mit Open Source >> Angeboten wirklich günstiger werden würde. >> Aber meiner Meinung nach werden auch keine Programme in "Hochsprachen" >> zum Einsatz kommen. Schließlich muß eine Wartbarkeit von den Technikern >> möglich sein, und glaub mir, die haben schon mit AWL große Probleme. FUP >> und noch besser SCL, also grafsche Programmierung, das geht und ist auch >> für die "einfachen" Techniker händelbar. >> Es ist aber denkbar, das Teilsysteme mit einer eigenen festen >> Funktionalität und einem begrenzt wartbaren Programm (Fehlermeldungen, >> Betriebs- und Meßwertanzeige) zum Einsatz kommen, deren Programmierung >> in C oder anderen Sprachen vorgenommen wird. >> >> Gruß oldmax > > Danke. Warum könnte es denn deiner Meinung nach da ein erhöhtes > Sicherheitsrisiko geben? --> mehr Leute als Community = weniger Fehler > Gibt es aber vielleicht auch genau die Probleme, weil eben mit AWL etc. > programmiert wird. So bekommen die Programmierer ja überhaupt nie die > Change, mal hinter die Kulissen schauen zu können...(Naja, aber das ist > dann doch ein anderes Thema) > > Grüße Eigentlich steh ich nicht auf soviel zitierten Text, aber wenn ich nur den eigentlichen Kern zitiere, laufe ich Gefahr, das ich komplett mißverstanden werde. In der Industrie kosten Maschinen halt Geld, so auch in der Produktionskette. Das sind Maschinenstunden, die entsprechend ihrer Produktivität berechnet werden. Nun fällt so ein Stück aus und es beginnt die Uhr zu Ticken. Nur mal so ein Gedanke, Open Source, Programm vielleicht in C Hersteller finden, Kommunity einberufen, Spezialist trotzdem hinzubeordern was auch immer. Ein C Programm analysieren und über schlechte oder mißverständliche Dokumentation fluchen. Wann glaubst du, läuft die Karre wieder? Wenn C genau wie AWl, FUP, KOP oder SCL die Funktion der Schaltung sichtbar machen würde, wär vielleicht C im Einsatz, aber C ist vermutlich in der Programmierung dieser Sprachen benutzt worden. Steuerung von entsprechender Fachfirma. Da gibt es nicht nur Siemens. Aber die ist wohl die bekannteste auf dem Sektor Industriemaschinensteuerung. Das Betriebssystem, wennn ich es mal so nennen darf, ist genormt und in der Regel kann ein gut ausgebildeter Industrieelektroniker mit umgehen. (Nebenbei, ich bin ein Quereinsteiger gewesen und kam aus der Elektroinstallation.) Oftmals hat er die Anwendersoftware, also die Steuerung selbst geschrieben oder zumindest schon ein paarmal angepaßt. Der setzt sich nun an sein Datensichtgerät, schaut, was nicht geht und in der Regel findet er den Fehler innerhalb von ein paar Minuten. Selten ist es ein Programmfehler. Auch hier kann man davon ausgehen, das es ein Bauteil ist, das den Geist aufgegeben hat. Also, Bauteil wechseln und gut. Eventuell noch ein paar Parameter einstellen und das ist es dann. Ich habe über 30 Jahre einen solchen Job gemacht und ihr könnt mir glauben, da ist ganz schön Druck von Seiten der Produktion. Manchmal hab ich mir dann einen Produktionsmeister ins Schalthaus geholt, an die Sprechanlage gestellt und ab und zu mal gesagt, er soll seinem Bediener sagen, das er eine Taste drücken soll. Der kam sich dann enorm wichtig vor, der Bediener langweilte sich nicht mehr und ich konnte in Ruhe die Störung suchen. Aber kommen wir nun mal zum erhöhten Sicherheitsrisiko. Wenn es um Steuerungssysteme geht, ist da schon eine gewisse Stabilität erforderlich. Ein Ausfall einer Steuerung aufgrund einer dahin gebastelten Platine ist u.U. tödlich. Zusatzkomponenten wie Sensoren, Meßgeber, Aktoren und was euch da sonst noch so einfallen mag, kommen eh schon aus verschiedenen Firmen, darüber bedarf es keiner Debatte, aber es sind auch keine Garagenschmieden, sondern seriöse Produzenten, die sich ihrer Verantwortung bewußt sind. @ Alexander M Wenn du Probleme mit AWL, KOP und FUP und dem Rest von Anwenderprogrammiersprachen hast, du brauchst sie doch nicht, oder? Und wenn doch, wirst du feststellen, Programmieren in FUP, KOP oder AWL ist auch nicht anders wie in einer Programmiersprache wie C, lediglich der Syntax ist anders. Na ja, und auch meist das Ziel. Gut, wenn du auf dem PC eine Reihenfolge vertauscht, ist das Ergebnis falsch und alle kratzen sich am Kopf. Machst du das bei einer Maschine, kracht es da schon mal ziemlich laut und jeder weiß, das du einen Fehler gemacht hast. Gruß oldmax
Sorry, wollte ja eigentlich auf diesen Part eingehen Alexander M. schrieb: > Gibt es aber vielleicht auch genau die Probleme, weil eben mit AWL etc. > programmiert wird. So bekommen die Programmierer ja überhaupt nie die > Change, mal hinter die Kulissen schauen zu können. So ganz hab ich deinen Satz nicht verstanden. Welche Probleme gibt es? Ich programmiere eine Anwendersoftware in AWL, KOP oder FUP oder sonstwas. Auch PASCAL, C, BASIC und was es sonst noch so gibt, sind Anwenderprogramme, die dazu da sind, ebenfalls Anwenderprogramme zu schreiben für Leute, die einfach nur mal einen Text schreiben, ein Bild bearbeiten oder ihre Steuererklärung machen möchten. Die interessiert auch nicht, wie das gemacht wird. Schön, kann sein, das es Open Source ist, aber braucht das der Anwender? Gut, wenn er programmieren kann, vielleicht, aber die Regel sagt, ich will spielen, schreiben oder malen. Mach mir, das das geht. Will er aber wie du hinter die Kulissen schauen, muß er die zugrunde liegende Sprache lernen, sonst nutzt auch Open Source nix. So, nun ist genug von mir gefaselt. Gruß oldmax
Danke für die interessanten Antworten. Der Kern meiner Aussage ist ja nicht: Ich möchte meine eigene Platine entwickeln (oder im besten Fall den Arduino so wie er ist nehmen) und die in der Industrie sinnvoll einsetzen, und beschwere mich, weil das aktuell noch nicht gemacht wird... Ich kann ja zu 100% verstehen, dass jegliche HW-Komponenten staub-/EMV-/usw. geschützt & geprüft sein müssen, nur was ich eben nicht ganz verstehe, dass die Industrie so auf die SW-Komponenten wie AWL/FUP usw. beharrt und nie mal daran gedacht hat, weg von z. B. Siemens zu kommen und "günstigere" Komponenten zu verwenden, bei der dann wirklich auf das letzte Bit geschaut werden kann und nicht nur gehofft wird, dass schon alles laufen wird. Ob ich einen Not-Halt Schalter mit AWL programmiere oder mit C, spielt erstmal keine Rolle. Ist es falsch programmiert, ist es nun mal falsch, und dann ist man so wie so "fällig", egal ob das mit dem C oder mit AWL programmiert wird. Dass aber z. B. sich Open-Source SW da nicht durchgesetzt hat bei verschiedenen Funktionsbausteinen Funktionen Steuerungen (wie eine Siemens SPS), verstehe ich halt nicht... Die Vorteile würden doch auf der Hand liegen: - jeder weiß, was im Hintergrund ab geht - die Community würde Fehler finden (wenn es welche gibt) --> aktuell weiß doch keiner, ob die Siemens SPS im Jahr 1.1.2022 ein Überlauf hat und mir somit das Programm abschmiert... Die einzige richtige Vorteil ist mMn - die Instandhalter kennen sich mit AWL etc. aus (der auch mMn der Entscheidende ist, warum sich da nichts ändert) Alle anderen Vorteile könnten mMn zu Nichte gemacht werden: - Langzeitverfügbarkeit --> wenn Firma x seine SW Open-Source verkauft und passende HW liefert, die langzeitverfügbar ist... - "aktuell läuft alles stabil, es lief auch die letzten 30 Jahre stabil und warum sollte man das ändern" --> für mich ist das reine Hoffnung (na klar kann man hier dann auch argumentieren: "dann müsste aber auch die Chipherstellung der uC usw. Open-Source sein" --> zumindest hätte man so aber dann aber die "Unsicherheitskomponente" SW Steuerung ausgemerzt...) Grüße
ich verstehe es immer noch nicht: du willst eine SPS Steuerung für irgendeine Maschine durch ein Open Source C Gefrickel ersetzen und öffentlich machen, in der Hoffnung das irgendein Freak dir die Fehler daraus entfernt? Nicht dein Ernst, oder?
Alexander M. schrieb: > Ob ich einen Not-Halt Schalter mit AWL programmiere oder mit C, spielt > erstmal keine Rolle. doch, Stichwort SIL, safety integrity level. Um dem zu entgehen setzt man sogar liefer eine fertige Sicherheits SPS ein für kritische Funktionen.
Der Markt hat sich vor etwa 4 Jahren begonnen zu öffnen. Die Automatisierungsbranche steht Steuerungstechnisch am Anfang eine Revolution. Man muss nur mal schauen, was Phoenix mit PLCnext für Erfolge feiert, wie Bosch mit CtrlX in den Markt drückt, und selbst der Windows-Laden Beckhoff schwenkt (langsam) auf FreeBSD um. Container, Python, HTML-Visualisierung, etc., alles Dinge die es vor 5 Jahren kaum in der Branche gegeben hat, heute auf den Weg zum Normalzustand mit großer strategischer Unterstützung der Lieferanten. Die Vorstellung, dass der Betriebselektriker vom Kunden an einer aktuellen, neuen Maschine ein paar Netzwerke in der SPS ändert, hat nichts mit der Realität zu tun und ist ein verklärter Blick durch die Früher-war-alles-besser-Brille. Heutige Anlagen und Maschinen sind technisch viel zu komplex, vertragliche und rechtliche Rahmenbedingungen sprechen auch dagegen, dass da ein Kunde dran rumfummelt. Steuerungssoftware wird heute von Informatikern entwickelt. Schaut euch mal an, was für eine Generation da gerade ranwächst bzw. heute schon in den Entwicklungspositionen, z.B. bei Beckhoff, Bosch, und ja, auch bei Siemens ist. Klar gibt es noch Horden von "SPS-Programmierern", Elektriker und sonstige Nicht-Informatiker die sich das irgendwie und irgendwo mal beigebracht haben und mit fragwürdigen Methoden irgendetwas zusammen basteln. Aber schaut mal den Altersdurchschnitt an, das sind alles Leute, die in den nächsten 10 bis 15 Jahre in Rente sind. Es wird auch noch sehr lange einen Mark für das Geraffel àla Siemens geben, nur ist das ein schrumpfender Markt für den sich immer weniger interessieren, Studienabgänger wie Hersteller.
Johannes S. schrieb: > ich verstehe es immer noch nicht: du willst eine SPS Steuerung für > irgendeine Maschine durch ein Open Source C Gefrickel ersetzen und > öffentlich machen, in der Hoffnung das irgendein Freak dir die Fehler > daraus entfernt? Nicht dein Ernst, oder? Nein. 1. Ich möchte keine tausende Euros für eine Programmierumgebung zahlen, nur weil es einfach immer schon so gemacht wurde (Stichwort TIA Portal) 2. Ich verstehe nicht, warum sich Firmen abhängig machen von anderen Firmen (z. B. Siemens), nur weil das "bewährte Technik" ist bzw. besser gesagt: Ich verstehe nicht, wie Siemens & andere große Firmen so ein Monopol in der Industrie aufbauen konnten 3. Ich versehe nicht, warum nie Punkt 2 von anderen Firmen mal angegangen wurde, à la "Hier bekommt ihr unsere sichere Open-Source Software, (damit ihr versteht, was ab geht) und hier habt ihr gleichzeitig unsere industrietaugliche HW, die ihr dann mit unserer SW programmieren könnt. Ich will erstmal nichts öffentlich machen, ich will in erster Linie mit öffentlicher SW arbeiten ;)... Grüße
Johannes S. schrieb: > Alexander M. schrieb: >> Ob ich einen Not-Halt Schalter mit AWL programmiere oder mit C, spielt >> erstmal keine Rolle. > > doch, Stichwort SIL, safety integrity level. Um dem zu entgehen setzt > man sogar liefer eine fertige Sicherheits SPS ein für kritische > Funktionen. Ist diese Schnittstelle denn einsehbar? Weil wenn nicht, dann beruht die Schnittstelle ja lediglich auf Hoffnung... Grüße
Alexander M. schrieb: > Dass aber z. B. sich Open-Source SW da nicht durchgesetzt hat bei > verschiedenen Funktionsbausteinen Funktionen Steuerungen (wie eine > Siemens SPS), verstehe ich halt nicht... Zu erwähnen wäre das dort im Umfeld bereits Open-Source SW in der Entwicklung verwendet wird. Bei hohen Ansprüchen an die Zuverlässigkeit besteht die Notwendigkeit über einen anderen Systemansatz gegenzutesten. Wenn grobe Fehler in der SW wären, kann schlecht eine ganze Community eingesperrt werden. Vor allem muss die OSS-Community auch von irgendetwas Leben und ein Einkommen haben. Aktuell lernen die Profis die ersten Schritte mit OpenSource, wie das alles funktioniert. Dabei tragen diese oft der Community etwas bei. Parallel oder danach arbeiten diese häufig an den proprietären Projekten, wo diese ihr Einkommen beziehen um ohne Sozialhilfe Leben zu können. Open Source hat daher für die IT, bzw. µC-Programmierung die Funktion des Selbststudiums einer öffentlichen Bibliothek von Lernbüchern übernommen. Somit bildet OSS für alle Firmen dieser Branchen einen wichtigen Faktor mit dem Niveau des IT-Fortschrittes weiter mithalten zu können.
Dieter D. schrieb: > Alexander M. schrieb: >> Dass aber z. B. sich Open-Source SW da nicht durchgesetzt hat bei >> verschiedenen Funktionsbausteinen Funktionen Steuerungen (wie eine >> Siemens SPS), verstehe ich halt nicht... > > Zu erwähnen wäre das dort im Umfeld bereits Open-Source SW in der > Entwicklung verwendet wird. Bei hohen Ansprüchen an die Zuverlässigkeit > besteht die Notwendigkeit über einen anderen Systemansatz gegenzutesten. Kannst du da konkreter werden? Welche gibt es denn z. B.? > Wenn grobe Fehler in der SW wären, kann schlecht eine ganze Community > eingesperrt werden. Vor allem muss die OSS-Community auch von > irgendetwas Leben und ein Einkommen haben. Es geht mir ja nicht darum, dass jeder "mitpfuschen" kann an der Software, sondern eher darum, dass jeder die SW einsehen kann und dann evtl. natürlich Anträge zur Verbesserung einreichen kann... Vielleicht hab ich mich da auch nicht gut genug ausgedrückt in den letzten Posts... Grüße
Alexander M. schrieb: > Ist diese Schnittstelle denn einsehbar? Weil wenn nicht, dann beruht die > Schnittstelle ja lediglich auf Hoffnung... Quark, das hat nix mit 'Sicherheit durch Verbergen' zu tun. SIL ist ein Sack voll Normen, und du darfst deine Steuerung beim TÜV abnehmen lassen. Das in Einzelstücken ist natürlich wesentlich günstiger als Standardprodukte... Siemens ist auch nicht der einzige Große, es gibt jede Menge SPS Anbieter. Und Industrie ist konservativ, da will man Ersatzteile/lösungen min. 10 Jahre lang verfügbar haben. In der Praxis wirst du auch für >20 Jahre alte Anlagen noch Ersatzteile bekommen. OSS ist dynamisch, da wird jeden Monat eine neue Sau durchs Dorf getrieben. Auch wenn alles offen ist, finde mal in 10 Jahren jemanden der sich noch mit dem auskennt was heute hipp ist.
Johannes S. schrieb: > Und Industrie ist konservativ, da will man Ersatzteile/lösungen min. 10 > Jahre lang verfügbar haben. In der Praxis wirst du auch für >20 Jahre > alte Anlagen noch Ersatzteile bekommen. OSS ist dynamisch, da wird jeden > Monat eine neue Sau durchs Dorf getrieben. Auch wenn alles offen ist, > finde mal in 10 Jahren jemanden der sich noch mit dem auskennt was heute > hipp ist. Das ist aber doch auch möglich mit Open Source? 1. Spricht ja nichts dagegen, dass trotzdem Komponenten 10 Jahre verfügbar sind. 2. Es kann ja auch alt bewährte Technik Open Source sein, dann kennen sich vielleicht in 10 Jahre noch viel mehr aus ;) Aber an sich verstehe ich die Argumente natürlich schon... Ich wünschte es mir persönlich vielleicht einfach nur anders (auch wenn das dann eher weniger wirtschaftlich bzw. nicht wartbar etc. für die Firmen wär) ;)...
Alexander M. schrieb: > 1. Ich möchte keine tausende Euros für eine > Programmierumgebung zahlen, Naja, das scheint sich ja in den letzten Jahrzehnten zum Massenphänomen entwickelt zu haben: Niemand will mehr für eine vernünftige Leistung zahlen, weil "Geiz ja geil" ist. Nur die Folge, dass dann auch für die eigene Leistung nicht mehr vernünftig gezahlt wird, will dann doch niemand in Kauf nehmen... > nur weil es einfach immer schon so gemacht wurde > (Stichwort TIA Portal) ??? 1) Linux wurde 1991 veröffentlicht. 2) Von "TIA" spricht Siemens seit 1996. 3) Das TIA-Portal wurde 2017 veröffentlicht. Wenn TIA oder das TIA-Portal für Dich alte Zöpfe sind, die schon lange abgeschnitten gehören, dann sollte das doch noch viel mehr für Linux oder die ganze GNU-Software gelten, nicht wahr? Schließlich ist das Zeug noch viel älter... Von der Programmiersprache "C" reden wir lieber gar nicht erst. > 2. Ich verstehe nicht, warum sich Firmen abhängig machen > von anderen Firmen (z. B. Siemens), nur weil das "bewährte > Technik" ist bzw. besser gesagt: Ich verstehe nicht, wie > Siemens & andere große Firmen so ein Monopol in der > Industrie aufbauen konnten Gegenfrage: Verstehst Du ÜBERHAUPT, wie Arbeitsteilung funktioniert? Warum macht sich das Wasserwerk vom Elektrizitätswerk abhängig? Warum macht sich der Bauer von der Tankstelle abhängig und bestellt sein Feld nicht wie früher mit dem Ochsen? > 3. Ich versehe nicht, warum nie Punkt 2 von anderen > Firmen mal angegangen wurde, à la "Hier bekommt ihr > unsere sichere Open-Source Software, (damit ihr > versteht, was ab geht) und hier habt ihr gleichzeitig > unsere industrietaugliche HW, die ihr dann mit unserer > SW programmieren könnt. Der Teil ist einfach: Weil a) FOSS im öffentlichen Bewusstsein eine relativ junge Sache ist (wenig älter als 20 Jahre) und b) die Erkenntnis, dass man auf der Basis von FOSS auch Geld verdienen kann, noch viel jünger ist. Spannend ist eigentlich die umgekehrte Richtung der Frage: Warum ist Steuerungsprogrammierung ein von der "richtigen" Informatik dermaßen verachtetes Gebiet, dass zwar im Wochentakt neue Programmiersprachen für PCs und ähnliche Geräte erscheinen, aber die Zahl der Versuche, die Steuerungsprogrammierung zu verbessern, SEHR überschaubar ist? > Ich will erstmal nichts öffentlich machen, ich will > in erster Linie mit öffentlicher SW arbeiten ;)... Naja, dann entwickle doch einen freien AWL-Interpreter für Arduino.
Alexander M. schrieb: > 1. Ich möchte keine tausende Euros für eine Programmierumgebung zahlen, > nur weil es einfach immer schon so gemacht wurde (Stichwort TIA Portal) Na dann viel Spaß beim zehntausende Euro zahlen um die Sicherheitstechnik durch den TÜV zu bekommen. Und nicht vergessen: Jede HW-Komponente, jeder Stecker, jeder Taster, jedes Bit im ganzen Quellcode-Bereich was in irgend einer Form in Verbindung steht mit der Sicherheitstechnik muss zertifiziert werden. Einfach mal ein C-Programm was die "Sicherheitstechnik" in einem Task mit macht ist da nicht. Das Bedeutet dass nach JEDER Änderung das komplette Programm vom TÜV NEU abgenommen werden muss. Bei den gängigen Firmen wie z.B. Pilz, die Sicherheitstechnik anbieten sind das spezielle HW-Module, die doppelt überwacht werden. Auch der Programmcode kann nicht alles programmiert werden, da lässt sich das Projekt dann nicht übersetzen. Selbst bei Änderung der Sicherheitstechnik ist immer erst eine Passwort-Abfrage drin die das frei schaltet und der Download geht prinzipiell immer über Anlagestopp. Vergiss es einfach das in einem "C-Programm" mal schnell mit zu machen, du wirst es nicht schaffen durch den TÜV zu kommen - schon gar nicht ohne einen fetten Sack voll Geld. Beispiel Kosten: Von Pilz gibt es Feld E/A Module mit 4 Ein-/Ausgängen in Savety-Ausführung und ProfiSave Netzwerkanschluss. Kosten je Modul: ca. 800€ Je nach Maschine kostet alleine die Savety Hardware locker mal 5-Stellig. Schlussendlich sind die Kosten für das TIA "kleinkram".
Hi Alexander M. schrieb: > 1. Ich möchte keine tausende Euros für eine Programmierumgebung zahlen, > nur weil es einfach immer schon so gemacht wurde (Stichwort TIA Portal) Aha, du glaubst also, wenn Siemens und Co ihre Programmierung in Open Source anbieten würden, würde ein Programm, das nicht tausendfach vervielfältigt wird, weil es ja nur für eine Anlage von Bedeutung ist, keine tausend € kosten. Also, das wäre wirtschaftlicher Selbstmord. Jeder auf dieser Welt lebt von irgendwelchen erwirtschafteten Leistungen, der Millionär genauso wie ein H4 Empfänger. Wenn also jeder Leistung supergünstig, ja vielleicht sogar kostenlos seine Dienste anbietet, was glaubst du, wie dann der Bäcker seine Brötchen abgibt? Kostenlos, aus Nächstenliebe? Nächstes Thema: Alexander M. schrieb: > Ich wünschte > es mir persönlich vielleicht einfach nur anders (auch wenn das dann eher > weniger wirtschaftlich bzw. nicht wartbar etc. für die Firmen wär) Warum? Was hast du davon? Willst du auch an die Maschinensteuerung ran? Reichen die Grundlagen eines Informatikers aus, um mit Elektrizität und der Kraft von Maschinen umzugehen? Klar, es wird ja nur ein Bit gesetzt und ein Relais oder Schütz angesteuert, oder ein Fahrbefehll an irgendeinen Frequenzumrichter geschickt. Was ist da schon großartig zu beachten? Dafür braucht man doch höchstens nur Grundlagen der Physik. Außerdem, ich wünschte mir auch, das die Programme in Assembler geschrieben werden, ich kann kein C. Glaubst du, es interessiert hier jemanden? Jeder wird mir sagen, wenn du C anwenden mußt, weil es das Ziel fordert, dann lern es, oder bleib auf der Strecke. Es gibt genug, die das Ziel erreichen, da fällt es gar nicht auf, das du nicht dabei bist. Also, finde dich damit ab, das es außer Assembler, C, Pascal, Basic und noch viele weiteren Programmiersprachen auch noch welche gibt, die so gestaltet sind, das es geschultem Personal (von Betriebselektrikern bis zu Elektroingenieren) möglich ist, jederzeit Programmabläufe zu beobachten, zu analysieren und auch zu verbessern. Es gibt nicht nur kleine Maschinen, deren Funktion einmal festgelegt und dann vervielfältigt werden. Selbst in Roboterstraßen können Roboter von "Einrichtern" umprogrammiert werden. Dafür braucht es manchmal nicht einmal eine Programmiersprache. Da ist das Anlernprogramm Teil des Betriebssystems. Glaub mir, da sitzen Leute dran, die sehr viel Erfahrung haben. Und du meinst, mit Open Source wäre das alles viel einfacher und eine Community könnte da viel bewegen? Allein aus diesen Beiträgen hier kannst du erkennen, wie schwer es für dich ist, zu akzeptieren, das wenn man etwas können will, dieses auch lernen muß. Du bist ja immer noch der Meinung, du würdest KOP, FUP oder AWL mit Open Source ersetzen können und begreifst nicht, das auch C nicht so einfach Open Source ist, sondern ein fertiges Werkzeug. Und mit einem fertigen Werkzeug werden nicht nur Endprodukte geschaffen, sondern auch weitere Werkzeuge. Bei C wär es bspw. eine Library und bei SPS ein Funktionsbaustein. Alexander M. schrieb: > Es geht mir ja nicht darum, dass jeder "mitpfuschen" kann an der > Software, sondern eher darum, dass jeder die SW einsehen kann und dann > evtl. natürlich Anträge zur Verbesserung einreichen kann... Wo? Bei VW in Wolfsburg oder Mercedes in Stuttgart? Oder bei Thyssen oder was weiß ich wo noch? Oder kennst du jemanden, der sich eine SPS in sein Wohnzimmer gebaut hat? Unbekannt U. schrieb: > Heutige Anlagen und Maschinen sind technisch viel zu komplex, > vertragliche und rechtliche Rahmenbedingungen sprechen auch dagegen, > dass da ein Kunde dran rumfummelt. Steuerungssoftware wird heute von > Informatikern entwickelt. Unbekannt U. schrieb: > Klar gibt es noch Horden von "SPS-Programmierern", Elektriker und > sonstige Nicht-Informatiker die sich das irgendwie und irgendwo mal > beigebracht haben und mit fragwürdigen Methoden irgendetwas zusammen > basteln. Sorry, das zeigt mir, das du von der Materie wenig, vielleicht gar keine Ahnung hast. SPS ist heutzutage Standartausbildung der Industrieelektroniker. Und wie in jedem Beruf gibt es da Menschen, die mit dem erlernten zufrieden sind und welche, die mehr draus machen und Meister oder Techniker nachschieben. Selbst Studiengänge zum Ingenieur oder moderner Bachelor und Master sind nicht selten. Informatiker hingegen sind nicht unbedingt geeignet, Maschinen zu programmieren. Es sei denn, sie haben Steuerungs- oder Regelungstechnik studiert oder besser beides. Aber dann sind wir wieder im Ingenieursbereich. Und fragwürdig sind deren Methoden und Arbeiten sicherlich nicht, denn die Maschinen laufen nicht nach Fragwürdigkeit, sondern nach wohl durchdachten Abläufen. Was anderes würde der Abteilungsleiter gar nicht zulassen. Wenn du von 10 Programmänderungen auch nur eine verpatzt, dann wird dir sehr schnell klargemacht, das du da die Finger von lassen mußt. Zu teuer sind die Ergebnisse von fragwürdigen Eingriffen. Egon D. schrieb: > Spannend ist eigentlich die umgekehrte Richtung der > Frage: Warum ist Steuerungsprogrammierung ein von der > "richtigen" Informatik dermaßen verachtetes Gebiet, > dass zwar im Wochentakt neue Programmiersprachen für > PCs und ähnliche Geräte erscheinen, aber die Zahl der > Versuche, die Steuerungsprogrammierung zu verbessern, > SEHR überschaubar ist? Egon hat da völlig recht. Eine Programmiersprache für eine SPS ist eine ziemlich vertrackte Angelegenheit. Zum einen muß sie die Möglichkeit bieten, jedes Bit in einer Steuerung sichtbar zu machen, jeden Wert anzuzeigen und nicht irgendwann, sondern so, das daraus auch Rückschlüsse gezogen werden können, also übertrieben gesagt in "Realtime". Und das ohne den Programmablauf auszubremsen. (Bitte, nagelt mich jetzt nicht auf Realtime fest, ich weiß, das es etwas anders ist, aber um das zu erklären brauch ich mindestens zwei Tage. ) Ich denke, mit der Einführung der Sprachen für die gängigen Maschinen ist eine gut erlernbare Basis für das Servicepersonal geschaffen. Ich selbst habe Inbetriebnahmen durchgeführt und weiß, wie beweglich man dabei sein muß. Nicht immer ist das was in der Theorie am grünen Tisch geplant wurde, physikalisch umsetzbar und dann ist ein Programmierer gefragt, der auch die Maschine und ihre Möglichkeiten und Grenzen kennt. Gruß oldmax
:
Bearbeitet durch User
Martin V. schrieb: > Zum einen muß sie die Möglichkeit > bieten, jedes Bit in einer Steuerung sichtbar zu machen, jeden Wert > anzuzeigen und nicht irgendwann, sondern so, das daraus auch > Rückschlüsse gezogen werden können Unerlässlich für die Programmiermethodik "Versuch und Irrtum" ;-) Uwe
Unbekannt U. schrieb: > Aber schaut mal den Altersdurchschnitt an, das sind alles > Leute, die in den nächsten 10 bis 15 Jahre in Rente sind. Maschinen werden heute von jungen Informatikern programmiert die nach dem Studium kaum Berufserfahrung aufbauen konnten? Weil sonst zu alt? Nicht gut! Uwe
Hi Uwe B. schrieb: > Unerlässlich für die Programmiermethodik "Versuch und Irrtum" ;-) Nun, auch das gibt es, aber in der Regel dient eine Visualisierung des Programms dazu, Fehler zu lokalisieren. Der "alte" Elektriker hatte dafür seinen Duspol, der mit der Zeit ein Multimeter wurde und in einem Display mit einer aktiven Visualisierung der Schaltung endete. Haltet euch nicht so sehr fest, das eine SPS "ständig" programmiert wird, aber es kommt schon mal vor, das sich Produktionsbedingungen ändern und eine Maschine angepaßt werden muß. Kommt auch ein wenig auf die Maschine an. Uwe B. schrieb: > Maschinen werden heute von jungen Informatikern programmiert die nach > dem Studium kaum Berufserfahrung aufbauen konnten? Weil sonst zu alt? > Nicht gut! Woher nimmst du denn diese Weisheit? Ich hab da ziemlich ausführlich geschrieben, das eine Programmierung einer Maschinensteuerung Grundlagen in der Ausbildung von Industrie-Elektronikern ist. Es gehört ein etwas anderes Verständnis zu einer Maschinensteuerung wie zur Programmierung einer Datenbankanwendung. Natürlich schließe ich nicht aus, das ein Informatiker eine Maschine programmiert, aber das ist eher die Ausnahme, genauso, wie ein Maschinenprogrammiereer eine Datenbankanwendung schreibt. Frag mal einen Informatiker, ob er aus dem Kopf heraus eine Kreuzschaltung hinbekommt. Der weiß wahrscheinlich gar nicht, wozu die gut ist. Eine SPS steuert eben nicht nur eine Drehbank, sondern auch große Fertigungsstraßen. Die "Alten" haben noch Steuerungen mit Schützen gebaut und sich durch meterlange Reihen von Schaltschränken kämpfen müssen, immer die Pläne im Arm und Meßwerkzeug. Glaubt mir, die konnten noch Maschinensteuerungen und Schaltpläne lesen. Und wenn sie denn den Anschluß nicht verpaßt haben, waren es auch gute Programmierer von Steuerungen. Gruß oldmax
:
Bearbeitet durch User
Martin V. schrieb: > Uwe B. schrieb: >> Maschinen werden heute von jungen Informatikern programmiert die nach >> dem Studium kaum Berufserfahrung aufbauen konnten? Weil sonst zu alt? >> Nicht gut! > > Woher nimmst du denn diese Weisheit? Ich fürchte ich wurde mißverstanden. Erstmal bin ich nicht der Meinung daß studierte Informatiker Maschinensteuerungen programmieren sollen. Das ist ein völlig anderer Job. Andererseits bin ich der Meinung daß die Programmierung von Maschinensteuerungen ab einer gewissen Komplexität Ingenieurs- oder Technikerarbeit ist. Gerne auch aus dem Bereich Maschinenbau. Der Industrie-Elektroniker macht da Inbetriebnahmen und ggf. Fehlersuche. Das war übringens auch in der "guten alten Zeit" so, die Schaltpläne für die laufenden Meter Schaltschrank kamen aus dem Konstruktionsbüro, die hat sich nicht der Verdrahter nebenbei überlegt. Tatsächlich ändert sich in der Welt der Maschinesteuerungen derzeit viel, die Grenzen zur "richtigen Programmierung" verschwimmen zunehmends. Wurde ja schon geschrieben. Ich mußte kürzlich mit der aktuellen Codesys Version arbeiten und habe mir mal die Programmierung der B&R-Steuerungen angesehen und getestet. Das ist nichts mehr für nebenbei wenn man das ernst nimmt. Was auch ein Thema der Zeit ist wäre die Bedienerführung. Durch die Möglichkeiten wachsen die Ansprüche. Das kann schnell, wie bei der Erstellung von PC-Software, die meißte Arbeit machen. Die Zeiten wo man eine schlichte SPS-Steuerung am Display erkennen konnte sind definitiv vorbei. Und dann, der wichtigste Teil: Mit 15 Jahren vor der Rente hat man gerade genug Berufserfahrung um souverän diesen Job machen zu können. Uwe
Uwe B. schrieb: > Andererseits bin ich der Meinung daß die > Programmierung von Maschinensteuerungen ab einer gewissen Komplexität > Ingenieurs- oder Technikerarbeit ist. Gerne auch aus dem Bereich > Maschinenbau. Der Industrie-Elektroniker macht da Inbetriebnahmen und > ggf. Fehlersuche. Der Industrie-Elektroniker ist aber auch ganz glücklich, wenn er in die SPS-Steuerung reingucken kann um nachzusehen, was sich da tut und auch mal den einen oder anderen Parameter verstellen kann. Dazu muss er auch nicht das komplette Programm von vorne bis hinten verstehen, sondern nur einen Teilbereich. FUP & KOP machen das aber deutlich einfacher. Uwe B. schrieb: > Was auch ein Thema der Zeit ist wäre die Bedienerführung. Durch die > Möglichkeiten wachsen die Ansprüche. Das kann schnell, wie bei der > Erstellung von PC-Software, die meißte Arbeit machen. Die Bedienführung (respektive HMI) macht dann i.d.R. aber auch nicht mehr die SPS sondern ein spezieller dafür bereitgestellter Rechner (resp. PC - damit wären wir bei der PC-Software). Da muss dass ganze dann auch nicht mehr zeitkritisch oder besonders "safety" laufen. Ob ein Informatiker aber für die Entwicklung eines solchen HMI der richtige ist? Ich denke da eher an einen "Anwendungsprogrammierer". In meinem alten und meinen aktuellen Bereich kenne ich jeweils gerade mal zwei Anlagenhersteller, die dafür auf Linux setzen: Datacon und Waagner Biro.
Alexander M. schrieb: > - Verwendet ihr in der Automatisierungstechnik z. B. schon Linux? Wie Linux wird gerne in Visualisierungsgeräten eingesetzt, z.B. schon seit über 15 Jahren in den Mobbilsterungsdisplays von IFM. Da ist dann allerdings noch ein Codeys Laufzeitsystem drübergestülpt. Man kann aber eigene Prozesse laufen lassen. Erwähnt sei auch LinuxCNC, gerne genommen für Retrofit von "richtigen" CNC-Maschinen. > - Was haltet ihr von Vertreibern von Open-Source Komponenten wie z. B. > https://www.industrialshields.com/industrial-automation-solutions-home-20210212-lp > oder https://revolution.kunbus.de/. Merkwürdige Konstrukte. Mit den Raspberrys an Sich habe ich durchwachsene Erfahrung gemacht, haben alle irgendwelche Macken. Die "SPSe" mit dem Raspberry sind oberflächlich nur billig. Die Sache mit den Arduinos kann ich eher verstehen, zumindest was die Softwareseite betrifft, der Zugang zur Programmierung ist leicht. Für einfache Maschinen kann man sich das vorstellen. Billig ist das aber auch nicht. > - Glaubt ihr die Maschinensteuerungen werden zukünftig weiterhin mit > Sprachen wie FUP AWL etc. programmiert oder geht's vielleicht mal > (mMn hoffentlich) in Richtung Hochsprache wie C / C++ ,... Die Programmierung von SPSen ist natürlich mühsam gewachsen, wirkt teilweise altertümlich. "Strukturierter Text" ist aber ernsthaft erwachsen geworden. Die Anforderungen sind deutlich anders, macht am Ende schon Sinn. Es hat sich in den letzten Jahren viel getan bei den Herstellern. Es lassen sich mittlerweile auch eigene C-Programme einbinden. Ich bin eigentlich ein Fan von Open Source und mag diese Quasimonopole nicht. Dieses Codesys z.B. läuft mittlerweile auf nahezu jeder Steuerung wo nicht Siemens, B&R, und Co draufsteht. Es gibt kaum Wettbewerb. Open Souce Projekte poppen immer mal auf sind aber schnell tot. Was die Kosten für die Programmierumgebung betrifft, zumeißt kann man sich das kostenlos bei den Herstelellern der Steuerungen herunterladen, die Lizenzen sind mit der Hardware bezahlt. Das bremst vermutlich auch die Motivation eine eigenes Betriebssystem mit Programmiertool zu entwickeln. Uwe
Moin, ja, das Thema ist ein Dauerbrenner und es prallen immer wieder die Automationsspezis auf die Physiker, die 'alles' koennen, nur nix richtig :-) Grundsaetzlich gilt ja immer: Das Rad nicht neu erfinden, sofern das alte Rad bezahlbar ist und Risiken vermeidet. Aber es tritt auch mal der Fall ein, wo eine SPS unzureichend ist, um irgend ein embedded-Geraet elegant anzusteuern - faengt schon damit an, wenn man ein altes serielles Protokoll einer PLC implementieren muss. Der Kunde hat damals eingesehen, dass es Sinn macht, eine neue Hardware aufzuziehen, mit der Anforderung, dass das gesamte System simuliert/verifiziert werden kann. Das kostet schon eine Stange Geld, aber der so erstellte VHDL-Code kann auch noch in 20 Jahren auf eine aktuell laenger verfuegbare Architektur gebrannt werden. Fuer den Kunden ist das somit Opensource. Fuer mich stellt sich a priori nicht die Frage ob man sich das SIL-X-PASS aufs Produkt kleben darf, sondern wie Haftungsszenarien mit schwerwiegenden Konsequenzen ausgeschlossen werden koennen. Ansonsten findet man da auch eine Menge Farce in Zertifizierungsprozeduren. Was die Linux-Thematik angeht: es gibt auch hier im Umkreis eine Menge SCADA-und Test-Systeme, die seit 20 Jahren auf Linux- oder QNX-Basis laufen, weil die Kunden keine Lust mehr auf LabVIEW-Gefrickel haben, was nach der Erstellung keiner mehr warten kann/will. Nur sollte man tunlichst Linux in sicherheitsrelevanten Systemen vermeiden. Ahja, sogar Siemens macht laengst den OpenSource/Arduino-Hype mit (siehe IOT2020). Schlussendlich ist es eine Frage, von wem man sich abhaengig machen will. Bei der heutigen Volatilitaet im Geschaeft ist es wahrscheinlicher, dass eine Geschaeftssparte kaputtgekauft oder als unrentabel abgestossen wird, als dass der Opensource-Entwickler wegstirbt (und wenn, gibt es 200 andere, die sich reinfuchsen koennen).
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.