WinCC Unified Rezepturverwaltung

Matze001 · 12 März 2024

Hallo Zusammen,

(Info: Viel Text - TL/DR am Ende)

ich habe mich entschlossen ein eigenes Thema zu erstellen, nachdem ich erst den Beitrag "Erfahrungen mit Unified" gekapert habe.
Da meine Fragen und Themen jetzt aber zu speziell werden, und ich mir als Ziel gesetzt habe meine Lösung die sich aus diesem Thema ergibt auch für alle öffentlich zu machen, erstelle ich gleich einen eigenen Beitrag. Ich erhoffe mir davon eine rege Diskussion und eine Lösung für alle, die vor die gleiche Aufgabe gestellt werden.

Hier zunächst die Aufgabenstellung:

Da es in WinCCUnifified Stand heute keine Rezepturverwaltug mehr gibt, wie wir sie von WinCCflex und Co kennen, muss etwas eigenes her.
Die Parametersatztypen sind für diese Funktion leider unbrauchbar, da sie nur mit einem Datentyp versorgt werden können, der nicht verschachtelt werden kann.

Das Ziel:

Eine funktionsfähige und "einfache" Rezepturverwaltung erstellen.

Mein Ansatz aktuell:

Mehrere Scripte erstellen, die die Funktionen der Rezepturverwaltung nachahmen.

Es soll einen Satz lokale HMI-Variablen geben, die mit den Werten des aktuell zu editierenden Datensatzes gefüllt sind.
Diese können dann in allen möglichen HMI-Elementen wie Buttons, Slidern, Eingabefeldern, etc verwendet werden, und man kann sich seine eigenen Seiten gestalten, in denen man seine Variablen manipulieren kann. Ich verzichte auf die Tabellenform, da ich sie nicht brauche, gern kann sie aber jemand beisteuern.

Dann gibt es einen Satz PLC-Variablen, welche die Werte des aktuell angewählten Datensatzes enthalten.

Nun kommt der spannende Part: Wie werden die Datensätze gespeichert?

Mein Favorit aktuell wäre es eine SQLite-Datenbank zu verwenden.

Als Diskussionsgrundlage:

Vorteile:

Einfaches lesen und schreiben von Datensätzen durch Datenbankfunktionen
Einfaches Erweitern der Datensätze möglich
Backuplösung über Dump möglich

Nachteile:

Bisher weiß ich nicht ob es auf den WinCCUnified Panels (ggf. mit Lizenz?) läuft. Die Handbücher sind dazu sehr dürftig (weiß jemand mehr?)
Datenbanken bringen eine gewisse Komplexität mit sich.

Ich bin auch offen für andere Vorschläge wie z.B. Textdateien (CSV, XML, JSON,...)

Ich habe aktuell zum Teste TIAV19 und die WinCCUnified PC Rumtime im Demo Modus.
Ich freue mich über Tester die z.B. Panels im Einsatz haben.

Damit ich starten kann sollten folgende Fragen beantwortet sein:

1. Interessiert sich jemand dafür? Lohnt es sich also das zu machen?
2. Weiß jemand zu meiner Frage mit dem SQLite bescheid? Bzw. hat eine gute Lösung für die Persistenz?

TL/DR: Ich will eine gescheite Rezepturverwaltung für Unified bauen und freue mich auf eure Unterstützung und will es auch allen zur Verfügung stellen.
Wenn das hier gescheit wird, kann ich mir auch sehr gut einen FAQ-Artikel dazu vorstellen.

Grüße

Marcel

nekron · 12 März 2024

Hallo Marcel,

ich bin nach meinen ersten Gehversuchen mit Unified regelrecht erschrocken ... Bis zur Rezepturverwaltung bin ich gar nicht erst vorgedrungen.

Wir haben schon für Flexible ein Frontend für die Standart-Rezepturverwaltung geschrieben, welches uns erlaubt zu sortieren, zu suchen, komfortabel durch Listen zu blättern. Als Backend nutzen wir aber immer noch die Rezepturverwaltung. Aber selbst das war eine ganz schöne Hausnummer.

Bei solchen Aktionen bin ich gerne dabei, wäre jedoch eher für XML/JSON, vermutlich wird SQLite schon am Panel scheitern. Lasse mich aber gerne eines besseren belehren.
Bei einer Datenbank musst du halt entweder jedes mal eventuelle neue Felder anlegen als auch alte löschen, meiner Meinung nach (jedoch kein JavaScript sondern halt eher C#) bei XML/JSON etwas einfacher.

Wenn man das Thema Unified ein wenig passiv verfolgt, ist es erschreckend, das Siemens die Comfort Panels verschwinden lassen will und mit so einem Nachfolger auftrumpft.

Gruss,
michael

Matze001 · 12 März 2024

Moin Michael,

ja so geht es mir auch.

Ich habe an die Datenbank gedacht, weil Siemens überall die SQLite für ihre Archive nutzt, wie ich lese auch auf den Panels.
Nur ob die zur "freien Verwendung" auch möglich sind, kann ich aus dem Siemens-Talk nicht rauslesen.

Ich komme genau so aus der C# Welt, und mir würde ein JSON-File vollkommen reichen.
Es muss halt geprüft werden wie man dann mit solchen Situationen umgeht.

Ein Objekt erweitern sollte keine Probleme machen, alle alten Datensätze bekommen für das Feld einen Default-Wert und der Nutzer darf es dann nachtragen.

Ein Objekt reduzieren, das würde ich ggf. vermeiden und die "Leiche" weiterhin im Objekt lassen, und einfach in der GUI nicht anzeigen / im Programm nicht verwenden. Außer der JSON-Parser ist so schlau, dass er beim Wandeln in das Objekt die Leichen einfach übersieht, und beim nächsten Speichern ohne diese speichert, dann reguliert es sich ja mit der Zeit von selbst.

Grüße

Marcel

nekron · 12 März 2024

Matze001 schrieb:
Ich habe an die Datenbank gedacht, weil Siemens überall die SQLite für ihre Archive nutzt, wie ich lese auch auf den Panels.
Nur ob die zur "freien Verwendung" auch möglich sind, kann ich aus dem Siemens-Talk nicht rauslesen.

Also alles was ich bisher zu dem Thema gefunden habe waren eher fails via ODBC usw. Und selbst wenn es auf einem PC Runtime möglich wäre - da was zu "basteln" was dann auf einem Panel eventuell nicht funktioniert - leider habe ich aktuell noch kein Unified Panel hier liegen.

Matze001 schrieb:
Ein Objekt reduzieren, das würde ich ggf. vermeiden und die "Leiche" weiterhin im Objekt lassen, und einfach in der GUI nicht anzeigen / im Programm nicht verwenden. Außer der JSON-Parser ist so schlau, dass er beim Wandeln in das Objekt die Leichen einfach übersieht, und beim nächsten Speichern ohne diese speichert, dann reguliert es sich ja mit der Zeit von selbst.

Genauso mache ich das ganze hier auch - beim erneuten Speichern fliegen die Leichen dann raus, neues bekommt Default-Werte.

Mal schauen, was mir in den kommenden Monaten an Zeit übrig bleibt, eventuell wirklich mal genauer mit Unified beschäftigen.

Gruss,
michael

Matze001 · 12 März 2024

Also schon einmal ein Update von mir:

Wenn man aus der C# Welt kommt ist Javascript nicht so wild.
Das Nutzen von Datenbanken habe ich verworfen, es werden Textdateien,

Das Lesen und Schreiben von Variablen in Javascript funktioniert sehr einfach.
Das Lesen und Schreiben aus und in Dateien sollte auch leicht gehen, scheitert in meiner Simulation aber an Benutzerrechten aktuell.

Das Zusammenfassen zu Strukturen um gescheite JSON-Dateien zu schreiben, und diese wieder in Variablen zu zerlegen ist auch recht einfach möglich.

Somit denke ich, dass hier relativ schnell mal ein erster Entwurf zur Diskussion gestellt werden könnte.

Grüße

Marcel

schwimmer · 13 März 2024

Mir geht es da wie @nekron, derzeit steht mir das erste von 3 Unified-Projekten bevor und was ich hier im Forum bereits gelesen habe, da stellen sich mir auch die Nackenhaare auf.
Auch wenn ich nur eine sehr einfache Rezepturverwaltung benötige, finde ich den Vorschlag von @Matze001 prima. Leider habe ich mich mit Javascript noch gar nicht befasst und kann deshalb wohl nicht sehr viel zu diesem Projekt beitragen, werde es dennoch gerne im Rahmen meiner bescheidenen Möglichkeiten probieren.

Matze001 · 13 März 2024

So nun ein paar Gedankengänge als Gesprächsgrundlage:

Die Rezepturen werden anhand von Datensatznummern unterschieden.
Es gibt eine Liste für die Zuordnung von Namen zu Datensatznummern.
Die Datensatznummer würde ich als DINT anlegen, damit diese in der SPS verwertbar wäre.
Diese wird natürlich einmalig sein.

Für jeden Datensatz wird ein Ordner im Filesystem erstellt.

Beispiel:

Code:

ID   Name
01   Test01
02   Test02
03   Test03
...

Dann sieht meine Ordnerstruktur wir folgt aus:

Code:

..\\Rezepturverwaltung\\01
..\\Rezepturverwaltung\\02
..\\Rezepturverwaltung\\03
---

In jedem Ordner liegen dann die JSON-Dateien.
Aktuell würde ich mehrere JSON-Dateien für eine Rezeptur erstellen, um nicht einen riesigen Monolithen zu erhalten,
sondern nach Aufgaben getrennt die Daten zu halten.

Beispielhaft könnte dies sein:

Code:

AllgemeineParameter.JSON
Roboterpositionen.JSON
Palettierfunktionen.JSON
....

Damit lässt sich die Rezepturverwaltung recht flexibel erweitern oder reduzieren, gerade für Kollegen mit Anlagen die unterschiedliche Ausbaustufen haben könnte dies von Vorteil sein.

Ich freue mich über Feedback!

Grüße

Marcel

van · 13 März 2024

Matze001 schrieb:
So nun ein paar Gedankengänge als Gesprächsgrundlage:

Die Rezepturen werden anhand von Datensatznummern unterschieden.
Es gibt eine Liste für die Zuordnung von Namen zu Datensatznummern.
Die Datensatznummer würde ich als DINT anlegen, damit diese in der SPS verwertbar wäre.
Diese wird natürlich einmalig sein.

Für jeden Datensatz wird ein Ordner im Filesystem erstellt.

Beispiel:

Code:

ID Name 01 Test01 02 Test02 03 Test03 ...

Ist das mit den Datensatz-Nummern sinnvoll?
Bzw. welchen Grund hat das.

Ich arbeite immer mit dem Datensatz-Name.
Das ist dann meistens die Artikelbezeichnung (oft Alphanumerisch)

Da nochmal eine Zwischenebene einfügen ist dann immer eine Stufe mehr.
Und macht auch das Alphabetische sortieren nach Datensatz-Name schwieriger, gerade bei einer Ordnerstruktur auf dem File System

Und wer Nummern möchte kann ja den Datensatz-Name als Nummer nutzen

Matze001 · 13 März 2024

Klar kann ich auch direkt den Namen nutzen.
Ist weniger Arbeit. Ich dachte aber daran, dass viele die aktuelle Programmnummer ggf. in der SPS auswerten, und da tut man sich mit nem WSTRING manchmal etwas schwer.

Grüße

Marcel

schwimmer · 13 März 2024

Bei unseren Anlagen arbeiten die meisten Kunden auch eher mit dem Namen, ist für sie dann leichter zu finden. Weil sich zu der ProgrammNummer noch den Namen merken wird schwierig, zumal der Name vielleicht auf jeder Anlage eine andere Nummer hat.

Matze001 · 13 März 2024

Also zur Info:

Die Nummer ist nur für die Ordnerstruktur und internen Zuordnung. Natürlich wird der Programmname in einer Liste (?) angezeigt.

Grüße

Marcel

van · 13 März 2024

genau darin sehe ich den Nachteil

Ordnerstruktur
du hat Ordner von 1 bis 1000, und möchtest mal schnell die Raw Daten von Datensatz-Namen "ABC" anschauen ...

internen Zuordnung
Du musst immer eine Liste pflegen Datensatz-Name zu Datensatz-Nummer
Und wenn man jetzt mal die Datensätze außerhalb des HMI erstellen will, muss man immer die Liste auch noch mitpflegen

Strings kann man in einer SPS mittlerweile auch gut vergleichen

Und mit dem alten Bereichszeiger Steuerungsauftrag 69/70 möchte man jetzt ja auch nicht mehr arbeiten.

Wenn für dich die Datensatznummern Sinn ergeben, ist das natürlich nichts falsches.

the_elk · 13 März 2024

Wir nutzen aktuell die Parametersatzverwaltung von Unified. Den größten Vorteil sehe ich hier, dass sich die Parametersätze als tsv-Datei exportieren kann und so die Daten übersichtlich in einer Tabelle bearbeiten kann, um beispielsweise Massenupdates einspielen zu können. Aktuell wurde zum Beispiel ein Sensor getauscht und die Grenzwerte mussten angepasst werden. Das ist in einer Tabelle schnell für alle Artikel erledigt. Bei einer Ordnerstruktur stelle ich mir das schwieriger vor. Parametersatznummern verwenden wir auch nicht, nur den Namen.

Von was wir schon länger träumen ist, dass ein Rezept aus Unterrezepten für die einzelenen Anlagenteile besteht. Das würde vieles vereinfachen.

nekron · 14 März 2024

Also Grundsätzlich sehe ich Vorteile bei beiden Arten ...

eine Art Index-File zu pflegen bietet nur Vorteile, die ist im Normalfall schneller geladen um durch sie zu browsen.
Eine Nummer bietet in der Kommunikation mit mehreren Gewerken leider heute immer noch eine große Rolle, wenn die Visu das nicht unterstützt mussten wir zum Teil schon noch mit Tabellen arbeiten (0=ABC, 1=DEF etc)

Zum Speichern auf Karte würde ich fast auch den Namen bevorzugen, da dann ein externes Bearbeiten leichter wird. Nachteil ist dann jedoch - der Name muss den Filesystem-Konventionen entsprechen, das muss auch entsprechend geprüft werden. Mit einer Nummer als Dateibasis entfällt das.

Gruss,
michael

Matze001 · 21 März 2024

So ein Update. Beim Schreiben der Textdatei bekomme ich den Fehlercode: 2156935121
Laut Siemens-Forum habe ich keine Schreibe-Berechtigung. Ich habe diese auf Ordner-Ebene für JEDER und alles was irgendwie Siemens im Namen vermuten lässt auf Vollzugriff gestellt, aber irgendwie mag es nicht.

Ich nutze die Simulation aus dem TIAP heraus, vielleicht ist das der Fehler?

Hat das schon jemand von euch gehabt und ne Idee?

Grüße

Marcel

DCDCDC · 21 März 2024

Matze001 schrieb:
So ein Update. Beim Schreiben der Textdatei bekomme ich den Fehlercode: 2156935121
Laut Siemens-Forum habe ich keine Schreibe-Berechtigung. Ich habe diese auf Ordner-Ebene für JEDER und alles was irgendwie Siemens im Namen vermuten lässt auf Vollzugriff gestellt, aber irgendwie mag es nicht.

Ich nutze die Simulation aus dem TIAP heraus, vielleicht ist das der Fehler?

Hat das schon jemand von euch gehabt und ne Idee?

Grüße

Marcel

V17 - Data Export csv über Aufgabenplaner - Fehler 2156935121 - 293188 - Industry Support Siemens

HMIRuntime.FileSystem.ReadFile() -> errorCode 2156935125 - 264729 - Industry Support Siemens

Saving files to a network drive - 298893 - Industry Support Siemens

Matze001 · 22 März 2024

Die hatte ich alle schon gefunden, leider hat es nix gebracht.
Ich vermute es liegt an der Simulation, die Tage sollte die RT-Lizenz ankommen, dann kann ich auf nem IPC testen.

Grüße

Marcel

Matze001 · 26 März 2024

So ich hänge an der nächsten Aufgabe, und freue mich über Ideen.

Ich möchte mir nun eine Möglichkeit schaffen Programme anzulegen, zu löschen, umbennen, auswählen, etc.

Aktuell habe ich mir einen leeren ParameterdatensatzTyp erstellt, und nutze diesen ohne Werte nur für die o.g. Möglichkeiten.
Mit der Funktion bin ich aber sehr unzufrieden, da das Fenster dafür echt Müll ist.

Damit ich das alles selbst machen kann, hätte ich gern eine Tabelle aus der ich die Programme auswählen kann.
Um das zu realisieren wäre es meiner Meinung nach nötig die Einträge dynamisch aus einem Script erzeugen zu können.
Der "alte" Weg über X Ausgabefelder mit Buttons zum Scrollen kenne ich auch, hoffe aber das es etwas moderneres gibt.

Der Nachteil an der aktuellen Tabelle ich außerdem, dass durch das Feature der Mehrfachselektion und dem Datentyp DINT maximal 32 Einträge in einer Tabelle möglich sind. Ich muss also wenn es mehr als 32 Einträge gibt, auch die Einträge in der Tabelle austauschen, wenn mehr gesehen werden soll...

Grüße

Marcel

the_elk · 28 März 2024

Wir nutzen zur Darstellung der Parametersatznamen und deren Auswahl aktuell mehrere Listenfelder nebeneinander. So bekommt man schon einige Rezepte angezeigt. Zusätzlich kann man noch nach einzelnen Variablen filtern, oder den Namen der Rezepte mit einer Freitextsuche filtern.

Das Ganze könnte ich mir auch in einem CustomWebControl vorstellen. Von Siemens gibt es da ein Beispiel mit Tabulator. Das wäre vielleicht was für dich, wenn du eh alles extern löst.

WinCC Unified Rezepturverwaltung

Level-3

Level-2

Level-3

Level-2

Level-3

Level-3

Level-3

Level-2

Level-3

Level-3

Level-3

Level-2

Level-2

Level-2

Level-3

Level-3

Level-3

Level-3

Level-2

Similar threads

Wir schützen deine Privatsphäre