Fertigungsleitsystem programmieren

B

bpnktmpnktcpnkt

Level-2
Beiträge
20
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
Zuletzt bearbeitet:
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.
 
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.
 
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.
 
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?
 
bpnktmpnktcpnkt schrieb:
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.
Zum Vergrößern anklicken....

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 :p

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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
... 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.)
 
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.)
Zum Vergrößern anklicken....

Naja Fertigungsleitsysteme ist eine spezielle Sache :p
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
 
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 ;)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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...
Zum Vergrößern anklicken....

Ü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 ;)
 
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 ;)
Zum Vergrößern anklicken....

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ß.
 
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ß.
Zum Vergrößern anklicken....

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 :p
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
 
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 :p
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
Zum Vergrößern anklicken....


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 schrieb:
Senkung der Fehlerrate bei der Anbindung von Anlagen.
Security
Diagnose
Zum Vergrößern anklicken....

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.
 

Similar threads

G
OPC UA Clienttoolkit
Antworten
0
Aufrufe
3K
GuseMann
G
Zurück
Oben