Step 7 Möglichkeiten zur Anbindung an eine Datenbank

SudKnut

Level-1
Beiträge
16
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Schönen Guten Morgen,

nachdem ich mich gestern im Bereich "Stammtisch" vorgestellt habe, komme ich heute mit meinem ersten außerordentlichen Anliegen.

Die Suchfunktion habe ich bereits genutzt, allerdings handelt es sich immer um sehr genau definierte Probleme, die keine Alternativen darstellen. Dabei habe ich schon von Connectoren, Softwarepaketen, OPC-Systemen usw. gelesen, jedoch habe ich keines der Themen mehr als nur angerissen. Ich erhoffe mir mit diesem Thread eine Art Auflistung von Möglichkeiten, die es hier so m.M.n. noch nicht gibt. Wenn dem doch so sein sollte, dann entschuldigt mich bitte.

Nun zum eigentlichen Thema:

Mit der Teilautomatisierung von einfachen Kleinst-Maschinen - hauptsächlich deren Antrieb und Vorschub - sollen Prozessdaten über Betriebsaufträge aus Datenbanken entnommen und anschließend in einer Datenbank abgelegt werden.

Das Entnehmen aus den Betriebsaufträgen (kurz BA) könnte z.B. so aussehen, dass die BA über einen Barcodescanner eingelesen und somit die notwendigen Prozessdaten aus einer Datenbank ausgelesen werden können. Beispiel: Der notwendige Vorschub für Teil XY wird über den BA aus der Datenbank ausgelesen; der evtl. manuell veränderte Wert wird bei Fertigstellung als Vergleichswert in die Datenbank geschrieben.

Für Testzwecke möchte ich den Prototypen dieser Maschinen - dessen Entwicklung noch weit am Anfang in der Planungsphase steht - an eine SQL-Datenbank anbinden. Das angedachte Automatisierungssystem soll mit je einer S7-1200 pro Maschine + Basic- oder Comfort-Panel realisiert werden.

Die Fragen an Euch:
1. Welche Möglichkeiten habe ich, meine Aufgabe zu lösen?
2. Welche Software benötige ich? Also komme ich mit S7 Basic aus oder muss ich in den sauren Apfel beissen und mir die Professional-Version zulegen?

Beste Grüße

Hannes
 
Moin Hannes,

warum soll es eine SQL-Datenbank werden? Der Vorteil für dich erschließt sich mir nicht so ganz.

Die Prozessdaten könntest du strukturiert in der Steuerung ablegen. Ihre Eingabe & Verwaltung kann über die Visu erfolgen.
Vielleicht wird es dann kein Scanner, sondern eine Handeingabe des jeweiligen BA's.
Aber das Laden der notwendigen Parameter (Prozessdaten) und das Zurückschreiben bei Auftragswechsel - das lässt sich alles mit SPS / Visu machen, dafür brauchst du dir um Datenbanken keine Sorgen machen. Es kommt natürlich auf die Datenmengen an. SPS'n kommen da mal an ihre Grenzen (aber du sagtest: einfache Kleinst-Maschinen). Dann bliebe noch die Rezepturverwaltung über WinCC...

Also m.A.n. ist deine Aufgabe mit Step7 (ob Basic reicht, kann ich dir nicht sagen) und WinCC in den Griff zu kriegen.

Gruß
Jan
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
warum soll es eine SQL-Datenbank werden? Der Vorteil für dich erschließt sich mir nicht so ganz.

Stichwort: Datenmenge!

Es ist noch nicht ganz klar ob MDE und/oder BDE ... aber beides produziert einen riesen Haufen
außerdem läßt sich ab SQL sehr viel problemloser in der angeschlossenen Windows/Linux/XYZ Welt weiterarbeiten
und ein Report aus unterschiedlichen Daten ist über eine Datenbankstruktur wesentlich schneller zusammengestellt als aus unterschiedlichen Steuerungen

Anbindung ist auf unterschiedlichen Wegen möglich, es gibt fertige Lösungen, die man recht leicht ergoogeln kann und es gibt diverse dlls, mit denen man selber was verbrechen kann ... Snap7 z.b. soll unter bestimmten Voraussetzungen mit der 1200er reden können... http://snap7.sourceforge.net/snap7_client.html
 
Hi Jan,

für den Prototypen würde das mit Sicherheit reichen, jedoch ist der Prototyp nur der erste Schritt in die "neue Richtung".

Fakt ist, dass unsere Fertigungsleitung wünscht, dass irgend wann die "Bedienung durch einen Menschen" auf ein Minimum herunter gefahren werden soll. Da ist die Eingabe von Hand schon zu viel verlangt... die Vorgabe kommt leider nicht von mir. Daran kann ich also nichts ändern.

Die Daten, die ich benötige, stehen nun einmal leider in einer Datenbank und an die muss ich wohl oder übel ran. Die Frage ist, ob sowas ohne weiteres möglich ist. Was ich mir auch vorstellen kann, ist das reine Einlesen ohne später zurück zu schreiben. Ich muss die Maschine halt lt. Datenbank-Werten einstellen und kann dann immer noch in einer Art "Teaching-Modus" nachjustieren. Irgend wann sollte der Teaching-Modus der Maschine dann deaktiviert werden können und sie korrigiert die Werte von selbst. Da gibt es ja einiges an Möglichkeiten, jedoch komme ich um das Einlesen nicht herum.

Ich würd' sagen das ist nicht nur mein, sondern ein großes Problem bei der ganzen Kiste! Wobei... wenn man genau darüber nachdenkt, ist es doch mein Problem :p

Beste Grüße

Hannes
 
Zuviel Werbung?
-> Hier kostenlos registrieren
So, der Kaffee hat seine Arbeit getan!

Snap7 klingt nach einer sehr interessanten Lösung, zumal ich mich seit einer Weile vermehrt mit verschiedenen Linux-Distris und Python beschäftige. Das Ganze wäre also, ohne noch eine zusätzliche Programmiersprache wie C, C++ o.ä. zu lernen, für mich nutzbar.

Vllt. gibt es ja noch weitere Vorschläge oder Ideen!
 
Oder ich sollte deine Frage besser lesen. :)

https://support.automation.siemens....objaction=csview&extranet=standard&viewreg=WW

Die Webserver von Siemens, in einer S7-1200 lassen es zu Java Scripte auszuführen.
Die Frage ist nur, wieweit Siemens die Javascript Ausfühung eingeschränkt hat.

In der Doku steht leider nicht viel drin, ob und inwieweit eingeschränkt wurde ...

Aber Fragen kostet nichts, das Problem wird nur sein einen richtigen Ansprechpartner zu finden.
 
Die Webserver von Siemens, in einer S7-1200 lassen es zu Java Scripte auszuführen.

Ich habe auch schon darüber nachgedacht die "Web-Seite" der SPS zu nutzen, aber das ist m.M.n. keine saubere Lösung. Wenn man das Internet einmal ein bisschen danach durchforstet, stößt man gleich darauf, dass man sowas lieber sein lassen sollte. Solche Lösungen bringen zum Einen praktische Probleme mit sich und zum Anderen auch einige Probleme bezüglich der Sicherheit.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
In deinem Stammtischbeitrag hast du geschrieben, dass ihr erst langsam in die Automatisierung einsteigt.
Wenn du an vielen Anlagen mit übergeordneten Systemen (SQL-Datenbank) kommunizieren mußt, dann würde ich das Konzept mit der S71200 nochmal überdenken.
Sobald noch weitere Systeme wie Barcode-Scanner, RFID oder Kamersysteme hinzukommen, bist du vielleicht mit einer SPS und Visualisierung auf PC-Basis besser bedient.
Egal ob nun Siemens oder Beckhoff oder sonstwas in der Art.

Just my 2 Cents

Gruß
Dieter
 
Danke für Deine Meinung Dieter. Könntest Du mir näher erläutern, wo genau Du die Probleme siehst?

Die "normalen" SPS und Panel's sind in Hinsicht auf Anbindung zu Fertigungsleitsystemen leider strohdumm.
Zugriffe auf Datenbanken sind ohne Middleware nicht möglich.
Du kannst jetzt deine Midlleware zentral auf dem Server laufen lassen.
Damit bist du aber unter Umständen sehr unflexibel und hast Probleme bei Änderungen.
Oder du sorgst dafür, dass deine Maschinen so inteligent sind, dass sie selber ihr Datenhandling machen können.
In diesem Fall ist ein PC an der Anlage notwendig.
Und wenn schon ein PC an der Anlage ist, dann kannst du ihn auch zur Visualisierung und auch als Steuerung verwenden.
Auf dem Markt gibt es genügend Lösungen.
Von Siemens kannst du z.B. WinCC flexible PC-Runtime zur Visualisierung und WinAC als SPS verwenden.
Bei Beckhoff gibt es ebenfalls schöne Lösungen.

Schöne Beispiele für solche Anwendungen / Fertigungen sind z.B. Möbel- oder Fensterbau.
Du hast dort an vielen Arbeitsplätzen / Stationen Barcode-Scanner, Etikettendrucker und Bildschirme für die Auftragsdaten / Stücklisten.
Viele Montageplätze sind extrem einfache Vorrichtungen mit wenig Automatisierung.

Gruß
Dieter
 
Vielen Dank für die Erläuterung, Dieter!

Deine Lösung nehme ich mal in mein Gedankengut auf. Ich vermag sie nicht zu bewerten, ohne dass ich mir das Ganze ein bisschen durch den Kopf habe gehen lassen.

"Schick" würde ich auch eine Lösung finden, in der alle Maschinen aus einer Fertigungshalle in einem "Hallen-Maschinennetzwerk" verbunden sind. Dieses Netzwerk würde vllt. aus den einzelnen Maschinen und einem Mini-Linux-Server bestehen. In der Server-Datenbank können entweder von der Maschinen-SPS Einträge vorgenommen werden, oder die Datenbank holt sich bei einem bestimmten Ereignis per Profinet Einträge aus einer Maschinen-SPS (wenn ich die von vierlagig vorgeschlagene Snap7-Lösung richtig verstanden habe, sollte das ja evtl. möglich sein).
Als Beispiel nenne ich mal folgendes Szenario: An einem Computerterminal (das Hallen-Maschinennetzwerk wird gedanklich gerade größer ;)) wird ein BA eingescannt, der die Bearbeitungszeit für den durchzuführenden Arbeitsgang startet. Der BA wird der optimalen und freien Maschine zugeordnet, welche gleichzeitig bis zur Fertigmeldung für weitere BA gesperrt wird. Wenn der BA am besagten Terminal fertig gemeldet wird, holt sich der Server evtl. noch ein paar Daten aus der SPS und die Bearbeitungszeit wird beendet und in die DB eingetragen.

Kann jemand sagen ob das möglich wäre oder ob mir die Praxis ein Strich durch die Rechnung meiner Theorie macht?
 
@Knut:
Für Maschinen sollte eine klare Netzwerktrennung eingehalten werden.

  • Maschine (Profinet / Ethercat)
  • Fertigungslinezelle / Linie
  • MES / Office

Übergänge werden durch eigene Netzwerkbaugruppen / Gateways realisiert

Profinet sollte die eigentliche Maschine nicht verlassen. Snap7 hat NICHTS mir Profinet zu tun.

Ich bin zwar selber großer Linuxfan und nutze es privat intensiv.
Aber bei einer Lösung wie sie dir vorschwebt stellen sich mir die Nackenhaare auf.
Wer soll das ganze ausser dir betreuen? Was ist mit Wartung / Instandhaltung / Softwarepflege und Dokumentation?
Mit einer Fertigung soll Geld verdient werden, das ist keine Spielwiese und keine One-Man-Show :p
Such dir eine vernünftige MES-Lösung mit der du die Anforderungen gut abdecken kannst.
Du brauchst das Rad nicht neu erfinden ... Das haben schon genug andere getan und die verkaufen dir gute Räder :p

Gruß
Dieter
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Aber bei einer Lösung wie sie dir vorschwebt stellen sich mir die Nackenhaare auf.

Du merkst: Ich bin neu im Geschäft und muss anscheinend noch ordentlich in Zaum gehalten werden...

Ich werde mich wohl erstmal dem Automatisieren des eigentlichen Prozesses widmen müssen. Alles Andere scheint erst einmal ziemlich wenig Sinn zu haben.

Beste Grüße

Hannes
 
Zuletzt bearbeitet:
Ich werde mich wohl erstmal dem Automatisieren des eigentlichen Prozesses widmen müssen. Alles Andere scheint erst einmal ziemlich wenig Sinn zu haben.

Mach dir ruhig vorher Gedanken darüber welche Anforderungen später noch kommen.
Dementsprechend kannst / musst du jetzt schon dein SPS-System und deine Visualisierung auswählen.
Wenn du dich jetzt auf S7-1200 und Basic-Panels festlegst, dann kann es sein, dass du später bei MES ziemliche Klimmzüge veranstalten musst.
Ein Problem der Basic-Panels ist, dass sie kein VB-Script unterstützen.
Falls du mal wirklich nur ein paar Maschinendaten auf einen Netzlaufwerk protokollieren willst, dann kannst du mit VB-Script recht einfach passende CSV-Dateien erstellen.
Und das ohne Snap7, libnodave oder dergleichen.
Nimmst du anstelle von Siemens eine andere Visualisierung, dann ist vielleicht die Programmierung etwas weniger komforabel, dafür hast du abder evtl. gleich die Möglichkeit zur Kopplung zur DB.

Fazit:
Lieber vorher 1 Monat mehr suchen als nachher 10 Jahre ärgern.

Gruß
Dieter
 
Hallo Dieter,

es ist interessant zu sehen, wie Du für eine dezentrale Lösung kämpfst - hier also ein paar Sätze zu einer, ich nenn es mal zur besseren Gegenüberstellung "zentralen Lösung" mit z.B. snap7 oder libnodave oder einem kommerziellen Produkt.

Das wohl stärkste Argument ist in meinen Augen die Universalität der zentralen Datenanbindung. Habe ich die Siemens-Kommunikation mit "dll" verstanden und ein vernünftiges Node und Tag-Backend in der Datenbank hinterlegt, ist es ein einfaches auf eben dieser Basis andere Clients, andere Steuerungen anderer Hersteller in einer ähnlicher Form anzubinden.

Im Fehlerfall an der Maschine ist es der zentralen Lösung im besten Fall noch möglich,Fehlerzustände abrufen zu können. Darüber hinaus ist es in den meisten Unternehmen selbstverständlich, dass "IT-Komponenten" sehr viel besser gegen Ausfälle gesichert und für mögliches Fehlverhalten redundant ausgelegt sind. Eine Dezentralisierung erfordert entweder ein mehr anderartiger Sicherheitsmechanismen oder, was ich für wahrscheinlicher halte, sie werden einfach nicht zur Verfügung gestellt.

Tatsächlich soll es,so hab ich gehört und es teilweise sogar gesehen, da draußen noch Maschinen,Geräte und Apparate geben, die ohne einer umfangreichen Visualisierung auskommen - da ist selbst ein Basic Panel schon zu viel. Die zentrale Lösung bietet den Vorteil, auch diese Clients mit Daten versorgen und Maschinen- und Betriebsdaten abholen zu können.

Fakt ist, für beide Lösungen muss programmiert (oder eine fertige Lösung eingekauft) werden - beide Ansätze benötigen entsprechend Planung, vor allem aber Übersicht und Durchhaltevermögen...

Übrigens, die prophezeiten Klimmzüge entstehen nur, wenn man sich darauf verlässt, dass man alles schön verteilen kann... ich beobachte und unterstütze einen neue Welle der zentralen Organisation. Wobei zentral nicht ausschließt, dass man es auf gleichartige Systeme verteilt - redundant, nicht auf unterschiedliche Maschinen.

:TOOL:
 
Zuletzt bearbeitet:
Zurück
Oben