# Fertigungsleitsystem programmieren



## bpnktmpnktcpnkt (20 Februar 2020)

Hallo zusammen,

gerne würde ich mit meinem Thread eine Diskussion anstoßen, vielmehr Erfahrungsberichte von Euch erhalten diese und meine Vorhaben diskutieren.

Folgend ein grober Blueprint meines Vorhabens:

Ziel ist es, Anlagenmodule(SPS-gesteuert) zu verketten mittels übergeordneten Leitsystem.

Das Leitsystem soll auf der Basis vom .NET Framework entwickelt werden.
Hierbei bevorzuge ich eine WebApplikation zu erstellen (ASP.NET). 

Die Kommunikation zwischen Leitsystem und den einzelnen Anlagenmodulen soll mittels herstellerunabhängiger Schnittstelle (OPC-UA) realisiert werden.
Auf Feldebene wird ProfiNet gesprochen.

Diesbezüglich würde ich gerne einige Erfahrungsberichte/Meinungen lesen/erhalten.

Ich freue mich auf rege Beteiligung. 

Beste Grüße
Bpnkt


----------



## Blockmove (21 Februar 2020)

Datenaustausch mit Leitsystemen ist für uns auf der SPS-Seite Alltagsgeschäft.
Bei OPC UA hast du noch einige Einschränkungen. Musst halt schauen, welche Steuerung wieviel kann.


----------



## bpnktmpnktcpnkt (21 Februar 2020)

Es wird mit der S7-1500 gearbeitet, diese bestitz einen integrierten OPC-UA Server.


----------



## MasterOhh (21 Februar 2020)

Kurze Zwischenfrage, hat es einen speziellen Grund, warum ihr ein eigenes System entwickeln wollt und kein fertiges verwendet? (es gibt da mittlerweile einige Anbieter).
Wir hatten vor Jahren mal so eine Idee und sind dann ziemlich schnell dran gescheitert ein bezahlbares OPC UA SDK zu finden.


----------



## bpnktmpnktcpnkt (21 Februar 2020)

Vorteile einer Eigenentwicklung:
-Maßgeschneidert
-Kurze Reaktionszeiten
-Nahtlose Integration in bestehende Systemlandschaften/Infrastruktur


Bzgl. der SDK kann ich eine starke Lösung empfehlen von Traeger. OPC-UA Client SDK .NET.
Softing hat ebenfalls Produkte in dieser Richtung.


----------



## Blockmove (21 Februar 2020)

bpnktmpnktcpnkt schrieb:


> Es wird mit der S7-1500 gearbeitet, diese bestitz einen integrierten OPC-UA Server.



Und je nach CPU ist der schnarchlangsam :roll:


----------



## malloc (21 Februar 2020)

Hallo,
was mir dazu spontan einfällt:
am besten von vornherein überlegen, wie ihr die Datenpunkte im Leitsystem flexibel haltet.
Für jeden geänderten oder neuen Datenpunkt den Source Code anfassen und eine neue Version deployen macht bestimmt schnell keinen Spass mehr.

Wie viele werden am System programmieren?


----------



## Blockmove (21 Februar 2020)

bpnktmpnktcpnkt schrieb:


> Vorteile einer Eigenentwicklung:
> -Maßgeschneidert
> -Kurze Reaktionszeiten
> -Nahtlose Integration in bestehende Systemlandschaften/Infrastruktur
> ...



Die Kommunikation von und zur Steuerung ist eigentlich der kleinste und auch einfachste Part.
Sowas kann man auch z.B. mit Kubernetes schön skalieren.
Interessant wird es mit den Datenbanken und der Businesslogik. Da hat man schnell ein Bottleneck.
Das Handling von Nacharbeit- und Ausschussteilen kann auch richtig Freude bereiten 

Aber auf jedenfall eine interessante Aufgabe. Und oft ist es wirklich besser Dinge selber zu entwickeln als die Fertigung an eine Kauflösung anzupassen und von einer Tretmine zr nächsten  zu stolpern.


----------



## zako (21 Februar 2020)

... ganz interessante  Berichte findet man z.B. bei 
https://www.artschwager-kohl.de

Oder auch Viastore usw.

Besuch doch die LOGIMAT in Stuttgart im März. Da stellen einige Softwareschmieden aus. 
Und ich würde trotzdem immer erst mal schauen was die Systeme der großen Automatisierungshersteller schon mitbringen - was es schon standardisiert gibt soll man auch nehmen (nach ein paar Jahren hat man womöglich ein System das keiner mehr beherrscht, aufgrund Personalwechsel usw.)


----------



## Blockmove (22 Februar 2020)

zako schrieb:


> Und ich würde trotzdem immer erst mal schauen was die Systeme der großen Automatisierungshersteller schon mitbringen - was es schon standardisiert gibt soll man auch nehmen (nach ein paar Jahren hat man womöglich ein System das keiner mehr beherrscht, aufgrund Personalwechsel usw.)



Naja Fertigungsleitsysteme ist eine spezielle Sache 
Nimmst du ein System von der Stange, dann musst du meist deine Fertigung, deine Anlagen und deine Organisation anpassen.
Nimmst du ein System, dass der Hersteller auf deine Bedürfnisse anpasst, dann bist du ihm im Prinzip ausgeliefert.
Machst du es selber, dann brauchst du sehr gutes Personal.
Fazit: Einen Tod musst du sterben.

Wenn man es selber macht dann hat man es heute durch den ganzen Hype um I4.0, Cloud, IoT aber einfacher.
Als "Abfallprodukt" hast du heute passende Frameworks, Protokolle, usw. zur Verfügung.

Gruß
Blockmove


----------



## ducati (22 Februar 2020)

wenn Du es selber machst, brauchst Du aber Leute die das wirklich können (und nicht nur behaupten es wäre doch kein Problem  )
Vorallem die Frage, wieviele Leute braucht man dafür?

Wie Blockmove schon sagt, einen Tod musst Du sterben 

Nur blöd, wenns nach 10 Mannjahren immer noch nicht läuft 

Und zur 1500er, die älteren Anlagen, TIA V13, können garkein OPC UA. Und wenn die DBs symbolisch sind dann wirds auch lustig, da Daten rauszuholen, ohne die Steuerungssoftware anzufassen...

Naja, die Hoffnung stirbt zuletzt


----------



## Blockmove (22 Februar 2020)

ducati schrieb:


> Und zur 1500er, die älteren Anlagen, TIA V13, können garkein OPC UA. Und wenn die DBs symbolisch sind dann wirds auch lustig, da Daten rauszuholen, ohne die Steuerungssoftware anzufassen...



Üblicherweise zieht man da eine Zwischenschicht ein und arbeitet mit Konnektoren für verschiedene Steuerungen / Protokolle.

Da hier schon Traeger erwähnt wurde, will der TE den SPS-Programmierer richtig Freude bereiten und den Client auf die Steuerung packen und mit Methoden arbeiten


----------



## ducati (22 Februar 2020)

Blockmove schrieb:


> Da hier schon Traeger erwähnt wurde, will der TE den SPS-Programmierer richtig Freude bereiten und den Client auf die Steuerung packen und mit Methoden arbeiten



Aha. Wie ich schon sagte, es gibt wenige Leute, die wissen, was nen Leitsystem ist, und wie man eins bauen sollte. Aber viele, die behaupten, es ist doch kein Problem.

Das SPS-Programm anzufassen ist immer ne ganz schlechte Idee...

Gruß.


----------



## Blockmove (22 Februar 2020)

ducati schrieb:


> Aha. Wie ich schon sagte, es gibt wenige Leute, die wissen, was nen Leitsystem ist, und wie man eins bauen sollte. Aber viele, die behaupten, es ist doch kein Problem.
> 
> Das SPS-Programm anzufassen ist immer ne ganz schlechte Idee...
> 
> Gruß.



Ein Fertigungleitsystem hat eigentlich die Aufgabe die Anlage / Steuerung mit fertigungsrelevanten Daten (Fertigungsmasse, Losgrößen, Teilenummern, Drehmomente, ...) zu versorgen und Anlagen- und Prozessdaten abzugreifen. Sowas geht eigentlich nie vernünftig ohne das SPS-Programm anzufassen. Am besten definert man klare Schnittstellenu nd hat so eine saubere Übergabe.
Hier ist OPC UA natürlich eine richtig schöne Sache. Keine Unklarheiten bei Adressen und Datentypen.
Solange man sich mit Polling oder Subscriptions zufrieden gibt, hat der SPSler ein schönes Leben. Da ist OPC UA ähnlich einfach wie eine Relaisschnittstelle 
Jetzt gibt es bei OPC UA auch so schöne Dinge wie Client auf der Steuerung und server- oder clientseitige Methoden.
Da ist dann die Freude vorbei. Da musst du die Steuerung richtig anfassen und dann lässt sich sowas auch nicht ohne weiteres beobachten.
Das Leitsystem startet auf der Steuerung dann z.B. den FB "SendeIstdrehmomente" oder "StarteBearbeitung".
Und wenn's nicht funktioniert, dann steht der Instandhalter abends um 11Uhr vor Anlage wie das Schwein vorm Uhrwerk.
Der Support-ITler sagt dann nämlich einfach: "Bei mir ist alles i.O. Aber deine Steuerung liefert keine Daten"

Bleibt der alte Spruch von den Methoden eine Firma zugrunde zurichten:
mit Aufträgen, das ist die einfachste;
mit Frauen, das ist die schönste;
mit Alkohol, das ist die schnellste;
mit Computern & Software, das ist die sicherste; 

Gruß
Blockmove


----------



## bpnktmpnktcpnkt (22 Februar 2020)

Blockmove schrieb:


> Und je nach CPU ist der schnarchlangsam





Blockmove schrieb:


> :roll:




Kannst du bzgl. der CPU eine Aussage treffen, welche Modele performance - technisch, gut sind?


----------



## bpnktmpnktcpnkt (22 Februar 2020)

Blockmove schrieb:


> Ein Fertigungleitsystem hat eigentlich die Aufgabe die Anlage / Steuerung mit fertigungsrelevanten Daten (Fertigungsmasse, Losgrößen, Teilenummern, Drehmomente, ...) zu versorgen und Anlagen- und Prozessdaten abzugreifen. Sowas geht eigentlich nie vernünftig ohne das SPS-Programm anzufassen. Am besten definert man klare Schnittstellenu nd hat so eine saubere Übergabe.
> Hier ist OPC UA natürlich eine richtig schöne Sache. Keine Unklarheiten bei Adressen und Datentypen.
> Solange man sich mit Polling oder Subscriptions zufrieden gibt, hat der SPSler ein schönes Leben. Da ist OPC UA ähnlich einfach wie eine Relaisschnittstelle
> Jetzt gibt es bei OPC UA auch so schöne Dinge wie Client auf der Steuerung und server- oder clientseitige Methoden.
> ...




Sehr schön Blockmove, ich mag deine Formulierungen!

Bzgl. SPS-seitiger Client bzw. Funktionen ist nichts vorgesehen. Das wird dem SPS´ler überlassen, er ist ja der Profi auf diesem Gebiet.
OPC-UA dient als saubere Schnittstelle um Produktionsdaten /Produktionsparameter auszutauschen sowie Status-Informationen zu abonnieren/loggen und ggf. als Leitsystem darauf zu reagieren.


Freue mich über die rege Diskussion. Weiter so ;-)


----------



## Blockmove (22 Februar 2020)

bpnktmpnktcpnkt schrieb:


> Kannst du bzgl. der CPU eine Aussage treffen, welche Modele performance - technisch, gut sind?



Für unsere Anforderungen geht es mit der 1515 los.


----------



## Thomas_v2.1 (22 Februar 2020)

Blockmove schrieb:


> Für unsere Anforderungen geht es mit der 1515 los.



Welche Gründe lagen denn für die Entscheidung zu einer Technik vor, die nur im Geringsten nach oben Skalierbar ist?


----------



## Blockmove (23 Februar 2020)

Thomas_v2.1 schrieb:


> Welche Gründe lagen denn für die Entscheidung zu einer Technik vor, die nur im Geringsten nach oben Skalierbar ist?



Senkung der Fehlerrate bei der Anbindung von Anlagen.
Security
Diagnose


----------



## Thomas_v2.1 (23 Februar 2020)

Blockmove schrieb:


> Senkung der Fehlerrate bei der Anbindung von Anlagen.
> Security
> Diagnose



Aber warum nicht ein dedizierter OPC-UA Server? Umgeht das Performance-Problem und ist nicht an Firmwareversionen oder Steuerungsvarianten gebunden. Und bei entsprechender Anzahl an OPC-UA Server auf den SPSen die schließlich auch lizensiert werden müssen, evtl. sogar günstiger.


----------



## Blockmove (23 Februar 2020)

Thomas_v2.1 schrieb:


> Aber warum nicht ein dedizierter OPC-UA Server? Umgeht das Performance-Problem und ist nicht an Firmwareversionen oder Steuerungsvarianten gebunden. Und bei entsprechender Anzahl an OPC-UA Server auf den SPSen die schließlich auch lizensiert werden müssen, evtl. sogar günstiger.



Bleibt aber immer noch das Thema Security.
Es ist klar, dass der 1500er OPC UA nicht das Optimum ist.
Aber die Richtung stimmt.


----------



## Mrtain (27 Februar 2020)

Wir nutzen für unsere Logistikanlagen nutzen wir einen eine SQL-Datenbank als Schnittstelle zwischen SPS und unserem Leitsystem.


----------



## bpnktmpnktcpnkt (27 Februar 2020)

Mrtain schrieb:


> Wir nutzen für unsere Logistikanlagen nutzen wir einen eine SQL-Datenbank als Schnittstelle zwischen SPS und unserem Leitsystem.



Interessant, welches Tool bzw. welche Schnittstelle nutzt Ihr um die Daten von der SPS in die Datenbank zu transferieren?


----------



## Blockmove (27 Februar 2020)

Mrtain schrieb:


> Wir nutzen für unsere Logistikanlagen nutzen wir einen eine SQL-Datenbank als Schnittstelle zwischen SPS und unserem Leitsystem.



Machen wir ähnlich.


----------



## Jochen Kühner (27 Februar 2020)

Also wir haben in unserer Visualiserung/Leitsystem AGLink von Deltalogic im Einsatz. Für die 1500er PLC's damit wir Symbolisch auslesen können. Der OPC auf der SPS war auch in einer 1517 ab >500 Datenpunkten nicht mehr nutzbar, über AGLink lesen wir 1000sende von Signalen innerhalb von ms. 
Wir definieren unsere Tag's nur in der Datenbank, speichern die werte dort aber nicht zwischen (aus perf. Gründen).
Wir haben unsere Software aber auch soweit Konfigurierbar gemacht, das auch Bildanpassungen, scripte, dynamiken usw. alles ohne Anpassung des Grundsystems möglich sind.
Oberfläche ist dann HTML5.
Ist im Endeffekt wie WinCC, nur eben mit dem was wir benötigen. In manchem etwas mehr als Wincc andere dinge brauchen wir davon aber eben gar nicht.


----------



## Jochen Kühner (27 Februar 2020)

PS den Aufwnad dahinter darf man aber eben auch nicht vergessen. In unserer Visu alleine Stecken bestimmt auch schon 10 Mannjahre Arbeit (Okay haben aber nun auch schon die 3te Ui Technologie (Silverlight => WPF => HTML5) (mit direkter Migration)). Aber bei uns ist auch noch MFR und WMS im Gesammtsystem integriert


----------



## Mrtain (28 Februar 2020)

..............


----------



## Mrtain (28 Februar 2020)

Jochen Kühner schrieb:


> PS den Aufwnad dahinter darf man aber eben auch nicht vergessen. In unserer Visu alleine Stecken bestimmt auch schon 10 Mannjahre Arbeit (Okay haben aber nun auch schon die 3te Ui Technologie (Silverlight => WPF => HTML5) (mit direkter Migration)). Aber bei uns ist auch noch MFR und WMS im Gesammtsystem integriert



Wir verwenden teilweise noch VBA unter Access. Wobei ich den Debugger dort sehr schätzen gelernt habe


----------



## Mrtain (28 Februar 2020)

bpnktmpnktcpnkt schrieb:


> Interessant, welches Tool bzw. welche Schnittstelle nutzt Ihr um die Daten von der SPS in die Datenbank zu transferieren?



Da wir Jetter Steuerungen benutzen, nutzen wir deren Programm JetWebSystem um aus der Steuerung Daten in die SQL zu senden oder zu lesen. Ich denke bei Siemens wird es sicherlich etwas vergleichbares geben (SQL for automation?). Man muss sich halt nur Gedanken über die Kommunikation machen. Wir nutzen dazu zum Beispiel zwei identische Tabellen, eine für die Maschinenseite, eine für das Produktionssteuerungsprogramm.


----------



## Blockmove (28 Februar 2020)

Kommunikationsmöglichkeiten gibt's eigentlich jede Menge.
Zum Testen nehm ich gerne Node RED. Kann auf der einen Seite zig verschiedene Protokolle (S7, Modbus, OPC UA, ...) und auf der anderen Seite auch zig Datenbanken.
Kann man auch mit einigen IoT-Gateways nutzen und dann in den Schaltschrank setzten.

Gruß
Blockmove


----------



## appsofting (1 September 2020)

War es möglich, das Projekt zu starten ?


----------



## bpnktmpnktcpnkt (2 September 2020)

Ja, es ist möglich und das auch sehr gut.
Sowie in vielen Pilotprojekten, lief es nicht geradlinig an, teilweise etwas holprig. Allerdings gibt es, bis jetzt, keine „ShowStopper“.

  [FONT=&quot]Aktuell kommunizieren wir mit zwei Steuerungen (1500er Reihe), einem HMI und einem IO-Link Master, ausschließlich mit OPC-UA.[/FONT]


----------

