TIA Anregungen für WinCC Rezepturverwaltung gesucht

fabey

Level-2
Beiträge
109
Reaktionspunkte
7
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin,

ich stehe am Anfang eines kleinen Projekts.
Es geht um eine Rezepturverwaltung in TIA v16 WinCC Advanced.

Diese soll ungefähr folgenden Aufbau haben:
SchrittBezeichnungFunktion 1Funktion 2Funktion 3Funktion 4
1AufwärmenHeizungBeleuchtung
2WartenTimer

Es muss ein Gesamtrezept wählbar und abspeicherbar sein.
In diesem Rezept kann man Schritte konfigurieren ("Bezeichnung" frei wählbar = Notiz), die nacheinander ablaufen sollen.
Pro Schritt sollen eine oder mehrere Funktionen an die PLC mit jeweils weiteren am HMI einstellbaren Datenpunkten übergeben werden.
Hier z.B. bei der Heizung eine Temperatur und eine Überwachungszeit in der diese erreicht werden muss.

Ich suche nun erstmal nach ein paar Denkanstößen, wie man grundsätzlich so etwas angeht. Über ein paar Anregungen würde ich mich sehr freuen. Die Aufgabe ist ja durchaus komplex.
 
Also da hat du dir ganz schon was vorgenommen.

Ich beschäftige mich gerade mit den T-CPU und der Kinematik.
Dazu gibt es eine Bibliothek und Demo von Siemens: https://support.industry.siemens.com/cs/de/de/view/109755891
Die läuft auch im Simulator. Da haben die etwas ähnliches gemacht, um die Bewegungen in einzelnen Schritte vorzugeben.
Erschrick nicht, es ist wirklich ganz schön umfangreich, aber du kannst dir da sicher ein paar anregungen holen.
Direkt mit Siemens-Rezepten hat das noch nichts zu tun, aber das kann man dann hinten anhängen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Unsere Anlagen haben im Prinzip eine ähnliche Funktion.
Der Ablauf ist unterteilt in x Programmschritte und für jeden Programmschritt kann der Einrichter unter mehreren Funktionen relativ frei auswählen.

Dazu habe ich ein universellen Schritt-udt erstellt, der die erforderlichen Daten für jegliche Art an Funktionen enthält.
Sowas derart:
Code:
TYPE "udtStep"
VERSION : 0.1
   STRUCT
      Operation : USInt;                          // Auszuführende Aktion
      Zone :      Array[1.."ZonesMax"] of Bool;   // Beteiligte Kreise
      ...
      Worktime :  Time;                           // Dauer der Durchführung
      Limit :     Int;                            // Grenzwert
      Breaktime : Time;                           // Pausenzeit
      Log :       Bool;                           // Eintrag ins Logbuch
   END_STRUCT;

END_TYPE
Daraus habe ich dann ein Programm-udt mit einem Array of udtStep erstellt:
Code:
TYPE "gdbProgram"
VERSION : 0.1
   STRUCT
      Recipe : Struct                           // Allgemeine Infos zum Programm
         Title  : String[20];                   //    Programmname
         Nr     : Int;                          //    Programmnummer    
         User   : String[10];                   //    Ersteller des Rezepts
         ...
      END_STRUCT;
      Step : Array[1.."StepsMax"] of "udtStep"; // Daten der Programmschritte
   END_STRUCT;

END_TYPE
Mit Programmstart arbeite ich dann die Programmschritte 1 bis "StepsMax" in einer Schleife ab.
Also immer
Code:
MyCurrent.Step := gdbProgramm.Step[x];
und mit den MyCurrent.Step-Daten wird dann bis zum nächsten Schritt-Index gearbeitet.


Über den Wert "Operation" wird dabei am Beginn eines jeden Schleifendurchlaufes entschieden, welche spezielle Funktions-Schrittkette abgearbeitet werden soll (0 = Aus, 1 = Heizung ein, 2 = ...).
Die speziellen Funktions-Schrittketten wissen dann, was z.B. beim Aufwärmen (bei Dir Heizung ein, Beleuchtung ein...) genau gemacht werden soll.
Die Schritte arbeiten bei uns je nach Funktion nach Zeit und/oder dem Erreichen von Vorgabewerten.


Am Ende jeder Funktions-Schrittkette wird der Programmschritt-Index weitergeschaltet.
In den Anlageneinstellungen kann der Benutzer noch auswählen, ob das Programm bei Erreichen eines AUS-Programmschritts (Operation = 0) das Programm direkt beendet oder trotzdem dann mit dem nächsten Schritt fortgefahren werden soll.


Alles ist mit globalen Konstanten programmiert, damit die Anzahl an möglichen Programmschritten ggf. einfach angepasst werden kann.
U.a. weil sich das Programm den arg begrenzten remanenten Speicher der genutzten S7-1200 mit dem Logbuch teilen muss. Je nach Priorität beim Benutzer kann man so schnell das eine hoch- und das andere dafür runterstellen.


(Zeit-)aufwendig war allerdings das Rezepterstellen im HMI, weil in ein Rezept leider nur Einzelvariablen und keine Arrays und/oder gar udts eingetragen werden können.
Insbesondere beim Erhöhen der Programmschritte muss dann jede neu entstandene Variable einzeln ins Rezept nachgetragen werden.
Für das Erstellen eines Programms durch den Benutzer habe ich eine eigene Eingabemaske programmiert, wo jeder Schritt einzeln durchgeblättert wird und je nach Funktion nur die relevanten udtStep-Daten angezeigt werden (Heizen braucht z.B. bei uns keine Zonenwahl).
In der Siemens-Rezeptverwaltung ist das Programmerstellen zwar auch möglich, allerdings ist dies dann nicht gerade benutzerfreundlich.
 
Zuletzt bearbeitet:
Hallo fabey,

bitte noch ein paar zusätzliche Infos:
+ Wieviele Schritte sollen maximal abgearbeitet werden?
+ Könnten die einzelnen Schritte auf ein gemeinsames Mengengerüst an Parametern fußen?


Ich arbeite bei einem Maschinenbauer für Anlagen und Einzelmaschinen im Bäckereiwesen.
Bei einem Knetsystem oder (kleiner) bei einem Einzelkneter besteht die Rezeptur aus frei zusammenstellbaren Schritten fest vordefinierter Typen mit bestimmten Parametern.

Zum Beispiel:
1. Schritt: Hauptdosieren (Parameter sind u.a. Dosierprogrammnummer, Aktion nach Dosierende)
2. Schritt: Mischen (Parameter u.a. Zeit, Drehzahlen für Bottich und Spirale, Aktion nach Schrittende)
3. Schritt: Restteigzugabe (Parameter u.a. Gewicht)
4. Schritt: Kneten (siehe Mischen)
5. Schritt: Teigtransfer zur Folgeanlage (Parameter u.a. Auskippzeit, Zeit für Schabereinsatz)
Mögliche weitere Schritte wären "Nachdosieren", "Vorteigruhe", "Fertigteigruhe"etc.

Eine Rezeptur besteht dann aus max. 10 Schritten, die alle auf dem gleichen (vollausgebauten) Parametersatz für ALLE Schrittypen aufsetzen.
Bedeutet in unserem Fall: 10x 35 Parameter-Variablen = 350 Variablen

Ich habe für die Parametrierung eines Rezeptur-Datensatzes mehrere Bilder projektiert (pro Schrittyp mindestens eins, quasi einen Rezepteditor), welche ich mit Hilfe von Scripten, Multiplexvariablen etc. steuere und so den Bediener befähige, zur Laufzeit jede beliebige (stimmt nicht ganz: jede vernünftige) Schrittkombination innerhalb der Mengengerüstgrenzen zu konfigirieren.

Zugegebenermaßen arbeite ich hier nicht mit Siemens-Rezepturen (war damals zwar mein erster Ansatz, hat aber zu viele Einschränkungen nach sich gezogen), sondern habe eigene Textdateien, die ich je nach Bedarf erzeuge, einlese, beschreibe oder lösche.


So: viel Text zur Erläuterung, wie ich es gemacht habe.
Die Essenz daraus -und für dich relevant- ist m.M.n.:
+ Datenbasis kann ein Array of Struct oder besser UDT sein, wo dieser UDT ALLE möglichen Parameter für ALLE Schritttypen beinhaltet.


Gruß, Fred


PS: Und hucki hat seeehhhrr recht, wenn er sagt "(Zeit-)aufwendig war allerdings das Rezepterstellen im HMI..."
 
Danke euch für die umfangreichen Antworten.

@Ralle: Danke, schaue ich mir mal an.
@hucki: Danke, interessant von deiner Umsetzung zu lesen, ich werde sie dann nochmal etwas durchdenken.

@faust:
+ Wieviele Schritte sollen maximal abgearbeitet werden?
Im Moment gibts das mit einer anderen HMI Software bereits, dort ist es wie eine Art Excel-Tabelle ausgeführt in der man einfach neue Zeilen hinzufügen kann (zwischendurch, hinten dran, ...) und sogar ganze (oder auch mehrere) Zeilen kopieren kann. Das ist natürlich wunderbar flexibel. Aber sowas kann ich mir mit WinCC Advanced noch garnicht vorstellen. Wenn dann habe ich nur grobe Ideen für eine "Schritt für Schritt" - Auswahl. Somit ist dort die Anzahl der Schritte beliebig, aber es sollten schon so 20-30 Schritte sein.

+ Könnten die einzelnen Schritte auf ein gemeinsames Mengengerüst an Parametern fußen?
Ich bin mir nicht ganz sicher wie ich die Frage verstehen soll. Aber die Funktionen die in den Schritten ausgeführt werden sollen, sind immer identisch (vlt. 5-15 Stück) und sollen halt in den Schritten beliebig aufgerufen werden können.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo fabey,

...
Im Moment gibts das mit einer anderen HMI Software bereits, dort ist es wie eine Art Excel-Tabelle ausgeführt in der man einfach neue Zeilen hinzufügen kann (zwischendurch, hinten dran, ...) und sogar ganze (oder auch mehrere) Zeilen kopieren kann. Das ist natürlich wunderbar flexibel. Aber sowas kann ich mir mit WinCC Advanced noch garnicht vorstellen. Wenn dann habe ich nur grobe Ideen für eine "Schritt für Schritt" - Auswahl. Somit ist dort die Anzahl der Schritte beliebig, aber es sollten schon so 20-30 Schritte sein.
...
Das ähnelt ja im Prinzip meinem Ansatz, nur das dort das Rezept außerhalb des HMI editiert wird.
Setze Excel-Dokument (wahrscheinlich eher CSV-Datei) gleich Rezept-Datei, dann hast du es.
Hast du eventuell eine Beispiel-Excel-Tabelle zur Hand?



...
Ich bin mir nicht ganz sicher wie ich die Frage verstehen soll. Aber die Funktionen die in den Schritten ausgeführt werden sollen, sind immer identisch (vlt. 5-15 Stück) und sollen halt in den Schritten beliebig aufgerufen werden können.
Das beantwortet meine Frage mit "Prinzipiell JA", wobei ich noch eine Frage hinterherschießen möchte:
+ Wird ein Schritttyp/Funktionstyp jedesmal mit den gleichen Parameterwerten ausgeführt, wenn er in der Schrittkette vorkommt?

Wenn ja, dann könnte man das Parameter-Mengengerüst nämlich splitten, z.B.:
1. Schrittkette
(so wie in deinem Eingangs-Post)
2. Schritttypen/Funktionstypen
Schritttyp 1Parameter1Parameter2usw.

Schritttyp 2Parameter1Parameter2usw.

Funktionstyp 1Parameter1Parameter2usw.

Funktionstyp 2Parameter1Parameter2usw.
usw.

Würde die reine Variablenanzahl merklich reduzieren.


Gruß, Fred
 
Setze Excel-Dokument (wahrscheinlich eher CSV-Datei) gleich Rezept-Datei, dann hast du es.
Hast du eventuell eine Beispiel-Excel-Tabelle zur Hand?
Das hatte ich bis jetzt auch so geplant. Ich arbeite mich seit gestern noch etwas in die VB-Scripte ein und habe es schon geschafft eine CSV-Datei zu schreiben mit ein paar Beispielwerten. Gerade bin ich dabei mich in das einlesen einzuarbeiten, was ja leider etwas komplizierter als das Schreiben ist. Der Kollege vom dem das bestehende HMI ist, ist derzeit leider nicht hier, deswegen habe ich nichts dergleichen zur Hand. Er arbeitet aber auch mit irgendeiner Text-Datei die man dann auch in einer Liste im HMI auswählen kann um so das entsprechende Rezept zu laden bzw. zu speichern.

+ Wird ein Schritttyp/Funktionstyp jedesmal mit den gleichen Parameterwerten ausgeführt, wenn er in der Schrittkette vorkommt?
Leider nicht. Die Funktionen können mehrmals mit unterschiedlichen Parametern verwendet werden. Sogar mehrmals in einem Schritt, wobei sich der zuletzt aufgerufene durchsetzt. Wobei ich auch nicht alles aus dem bestehenden HMI 1:1 umsetzen muss, nur dass es ähnlich nützlich ist.


Danke für deine große Mühe, Fred!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Vielen Dank erst nochmal für die Antworten und die freundliche Hilfe von @faust
Ich wollte nochmal kurz Rückmeldung geben wie ich es umgesetzt habe, kann ja mal für andere interessant sein.

Basis ist ein Bildschirm mit sehr vielen EA-Feldern (siehe Aufbau aus Beitrag #1), pro Funktion ein Feld. Je nachdem wie viele Schritte benötigt werden, werden mehr oder weniger Zeilen angezeigt.
Die Struktur aus Schritten mit Funktionen habe ich wie in diesem Beitrag beschrieben angelegt. Per Script-Lösung schreibe und lese ich die Schritte mit den Funktionen und deren jeweiligen Werte in eine CSV-Datei.
Wenn ich eine Funktion bearbeiten möchte klickt man auf das entsprechende EA-Feld (Script öffnet Popup mit dem Editor und übergibt um welche Funktion in welchem Schritt es sich handelt). Je nach Auswahl der Funktion erscheinen wiederum per Skript die passenden EA-Felder für die Parameter. Die Funktion lässt sich per Drop-Down-Menü auswählen. Alle Funktionen und deren Parameter sind zentral in einem Script beschrieben, aus diesem holt sich der Funktionseditor alle Infos die angezeigt werden müssen.
 
Zurück
Oben