# Linearisierung der Messwerte / Gauß'sche Glockenverteilung / CPK-Werte / S7-400



## Draco Malfoy (21 Juni 2014)

Hallo Zusammen!

Wollte fragen, ob es zum Thema mathematische Verarbeitung der Messwerte wie etwa deren Linearisierung bzw. Erstellung quadratischer Korrelationsgeraden (methode der kleinsten Quadrate), sowie die Ausgabe der Messergebenisse in Form einer Gauß'schen Glockenverteilung mit Angaben standardmäßiger mathematischer Normgrößen wie Konfdenzintervall (Wahrscheinlichkeits-Niveau) und CPK Wert schon irgendwelche öffentlich zugängliche Programm-Bausteine beispielsweise in SCL gibt ? Ich gedenke das Zeug in einer S7-416er Steuerung zu verwenden, mit Ausgabe auf einem standardmäßigen Siemens-Panel wie z.B. OP270 o.Ä.

Für alle sachdienlichen Anregungen danke schon mal im Voraus!


----------



## Blockmove (21 Juni 2014)

Also üblicherweise brauchst du bei Statistik gerne mal XY-Diagramme und das kann ein OP270 nicht.
Also ich würd da was moderneres zur Visu vorziehen.


----------



## Draco Malfoy (21 Juni 2014)

Blockmove schrieb:


> Also üblicherweise brauchst du bei Statistik gerne mal XY-Diagramme und das kann ein OP270 nicht.
> Also ich würd da was moderneres zur Visu vorziehen.


D.h. was würdest Du hier stattdessen empfehlen ? Die modernen Comfort-Panels gehen doch alle nur mit TIA, oder irre ich mich da.
Das Projekt wird jedenfalls in STEP 7 erstellt, bzw. PCS 7 und WinCCflexible. XY-Diagramme auch nicht unbedingt, sondern ein einfacher Balkengraph würde reichen, wo etwa 20-30 Balken gemäß der Anzahl der Messwerte mir die Ergebnisse anzeigen.


----------



## INSEVIS-Service (22 Juni 2014)

Hallo

Unsere Panels können die xy -Funktionen abbilden. Die Werte liegen in einem DB vor. Die 20 Bargraphen natürlich auch. 
Details: www.insevis.de

Geht auch als "Zweitpanel".


----------



## Draco Malfoy (22 Juni 2014)

Und wie programmiere ich die ? Bestimmt mit irgendeiner proprietären Software, die ich erst mal erlernen muss ? Ne bin gerade nicht so für Experimente zu begeistern.


----------



## INSEVIS-Service (22 Juni 2014)

Hallo

Ja, aber wer Flexible kennt wird unsre Visustage lieben.

Voll lauffahig für 30 Tage (auch für das erste Projekt) zum freien Download.

Die Firmenlizenz kostet einmalig 300,-.

Support gibts hier oder telefonisch mit mir.

Gruß


----------



## Draco Malfoy (22 Juni 2014)

Also wenn es eine Serienmaschine wäre, würde ich möglicherweise darüber nachdenken, aber bei so einer Einzelentwicklung wie hier, muss ich leider dankend ablehnen ;-( Der Lernaufwand für eine neue Software ist bei diesem Projekt einfach nicht drin. Die Aufgabenstellung is ja an sich schon komplex genug. Also nur ProTool, WinCCflexible / WinCC. Und kein TIA.


----------



## INSEVIS-Service (22 Juni 2014)

Hallo

Hast Du Dir die Visustage mal runtergeladen und angeschaut ?

Tipp: Variablen direkt im Step. 7 Projekt browsen. 
Dann hast Du in 10 Minuten deine xy Kurve auf dem Panel. 
Die Werte in den DB zu schreiben dauert bestimmt länger


----------



## Blockmove (22 Juni 2014)

Wenn du dein Diagramm aus 20-30 Einzelbalken aufbauen kannst, dann erfüllt das OP270 seinen Zweck. Ist halt schlichtweg ziemlich veraltete Hardware und nervt beim Retrofit, da man die meisten Bilder / Tasten stark nachbearbeiten muss.
Mit dem Proxy-Device ist die Kopplung TIA <-> Classic eigentlich ganz gut gelöst. Abgesehen davon, dass man nun 2 Projekte hat, kann man damit - meiner Meinung nach - leben.

Bin mal gespannt, in wie weit Rundungsfehler aufgund der 32Bit-Realzahlen in der S7 Ärger in deinem Projekt machen.

Gruß
Dieter


----------



## Draco Malfoy (22 Juni 2014)

INSEVIS-Service schrieb:


> Hast Du Dir die Visustage mal runtergeladen und angeschaut ?


Werd ich mal versuchen...

@*Blockmove*: über das Proxy-Device bin ich gerade nicht im Bilde. Nen Link ?
Die Werteverarbeitung mit den 32 Bit Real ist tatsächlich eine Sache für sich. Um zurück zum Thema zu kommen, gibts denn überhaupt irgendwelche mathematische Funktionen für S7 wie Linearisierung, Kalibrierung etc. als Open Source oder muss man das alles selber schreiben ? Gibt doch bestimmt irgendwo eine oder andere Vorlage in Hochsprache woraus man sich nen SCL Script bauen kann ?

wegen Panels: Runtime auf nem IPC ist noch etwas, worüber ich nachdenke.


----------



## Thomas_v2.1 (22 Juni 2014)

Gegenfrage: Hast du schonmal irgendwo ein Opensource Projekt für SPS-Programme gesehen?
Das einzige was es gibt ist Oscat, falls du es noch nicht kennst.

Du kannst ja deine Bausteine schreiben und sie dann in einer Art Math-Lib Oscat zur Verfügung stellen. Dann kommst du auch in den Genuss deinen Code von den Experten hier im Forum zerreißen zu lassen.


----------



## Draco Malfoy (22 Juni 2014)

Thomas_v2.1 schrieb:


> Gegenfrage: Hast du schonmal irgendwo ein Opensource Projekt für SPS-Programme gesehen?


Andere Gegenfrage: ich habe nicht vom SPS-Programm geredet ? Möglicherweise gibt es offene Algorithmen oder C-Code, den man zu SCL verarbeiten kann


----------



## Ing_Lupo (22 Juni 2014)

Hallo

Wenn der IPC vorhanden ist ist das die funktionelste Loesung. Mit Siemens RT allerdings nicht billig.

Das o. angesprochene Panel in 10 " kostet bei Insevis 950,- €.

Voraussetzung CPu mit Ethernet oder ein S7Link.

Dann bist Du aber auch Zukunftssicher für die nächsten Jahre.


----------



## Larry Laffer (22 Juni 2014)

Hallo Draco,

ich bleibe hier jetzt mal bei der Gauss-Kurve (Häufigkeits-Verteilung ?).
Wie sieht denn dein Quelldaten-Stamm aus. Ist der schon in der SPS (wie so eine Art Trend) oder für die greifbar ?
Eine Verteilungskurve kann du dir m.E. recht einfach aus einem Datenstamm errechnen und den hinterher auf einer 1D-Kurve (die dein OP m.E. kann) abbilden - dafür hätte ich bei Bedarf auch ein Beispiel.

Mit den anderen Gischichten, die du auch noch hinterfragt hast, kann ich so ohne weitere Erläuterung nichts anfangen ...

Gruß
Larry


----------



## Draco Malfoy (22 Juni 2014)

Larry Laffer schrieb:


> Hallo Draco,
> 
> ich bleibe hier jetzt mal bei der Gauss-Kurve (Häufigkeits-Verteilung ?).
> Wie sieht denn dein Quelldaten-Stamm aus. Ist der schon in der SPS (wie so eine Art Trend) oder für die greifbar ?
> ...



Beispiel ist immer gut ;-)
Also die Messdaten werden von der SPS in einem bestimmten Zyklus erfasst. Der Sensor fährt eine bestimmte Oberfläche auf und ab und vermisst dabei die Sollgröße X. Diese Sollgröße muss 1) mit den Kalibrierwerten, die vorher einmal eingemessen und in der SPS aufbewahrt werden, "geradegebogen werden" (um eine natürliche Illinearität des Sensors auszuklammern) und dann halt auf einem Balkengraph dargestellt werden. Dabei ist jeder Balken aber nicht 1x einziger Messwert, sondern Y Messwerte, da der Sensor diese Oberfläche nicht nur 1x mal, sondern Y Mal auf-und-abfährt. Somit erhalten wir einen Balkengraph wo die Messwerte entlang der zu vermessenden Obefläche angeordnet sind. Zu jedem einzelnen Balken muss aber auch eine Gauß-Glocke der Messwerte nochmal separat darstellbar sein. So in etwa der Sachverhalt.


----------



## ducati (22 Juni 2014)

Draco Malfoy schrieb:


> Das Projekt wird jedenfalls in STEP 7 erstellt, bzw. PCS 7 und WinCCflexible.



Was hast Du denn für nen Projekt an der Backe???

hier PCS7 + WinCCflex + Statistikfunktionen in SCL, im anderen Thread Migration von Step7/300 nach TIA/1500, im nächsten Thread Antriebe mit Positionierung, ...

Hut ab, falls Du das alles sauber hinkriegst... Aber die ganze Arbeit können wir hier für Dich auch nicht machen.

Gruß.


----------



## Draco Malfoy (22 Juni 2014)

ducati schrieb:


> Was hast Du denn für nen Projekt an der Backe???
> hier PCS7 + WinCCflex + Statistikfunktionen in SCL, im anderen Thread Migration von Step7/300 nach TIA/1500, im nächsten Thread Antriebe mit Positionierung, ...
> Hut ab, falls Du das alles sauber hinkriegst... Aber die ganze Arbeit können wir hier für Dich auch nicht machen.
> Gruß.


Gibt halt viel zu tun. Antriebstechnik hat sich mittlerweile quasi erledigt, da ist jetzt ne ziemlich billige Regelung implemetiert worden, zwar nicht 100% exact aber es läuft und ist erst mal OK so. Wenn ich Zeit habe, werde ich mir dazu weitere Gedanken machen. Migration ist auch noch so ne Altlasten-Aufbereitung die aber dennoch gemacht werden muss.

Niemand spricht von ganze Arbeit machen, ich habe ja eine ganz konkrete Fragestellung, ob es Vorlagen in Hochsprachen wie z.B. C# oder fertige Algorithmen gibt, die mir eine mathematische Aufbereitung der Messwerte nach der Gauß-Verteilung erlauben könnte, auf SPS Plattformen übertragbar.


----------



## ducati (22 Juni 2014)

Draco Malfoy schrieb:


> Vorlagen in Hochsprachen wie z.B. C# oder fertige Algorithmen gibt, die mir eine mathematische Aufbereitung der Messwerte nach der Gauß-Verteilung erlauben könnte, auf SPS Plattformen übertragbar.



Naja, Pseudocode gibt's bei Google doch jede Menge. Ich seh hier eher das Problem in der richtigen Anwendung der richtigen Formel. Da muss man schon in Statistik einigermaßen gut gewesen sein, um überhaupt das richtige mit Deinen Messdaten anzufangen. Ich hätte schon mal nen Problem, überhaupt zu verstehen, was Du machen willst, bzw. die richtigen Allgorithmen auszuwählen. Ob das ganze dann auch auf ner SPS läuft ist das nächste Thema. Hängt natürlich davon ab, wie viele Daten das sind und in welcher Geschwindigkeit sie reinkommen bzw. verarbeitet werden müssen.

Aus dem Bauch heraus seh ich bei solch einer Anwendung anstatt einer SPS eher Matlab oder Labview. 

Die 416 hat zwar in Punkto Speicher auch schon einige Möglichkeiten, aber die schnellste ist sie aber nicht.

Gruß.


----------



## Draco Malfoy (22 Juni 2014)

> Naja, Pseudocode gibt's bei Google doch jede Menge. Ich seh hier eher  das Problem in der richtigen Anwendung der richtigen Formel. Da muss man  schon in Statistik einigermaßen gut gewesen sein, um überhaupt das  richtige mit Deinen Messdaten anzufangen. Ich hätte schon mal nen  Problem, überhaupt zu verstehen, was Du machen willst, bzw. die  richtigen Allgorithmen auszuwählen.


Ich habe in Statistik zufälligerweise in der Tat ein Bisschen aufgepasst, und weiß zumindest mathematisch recht genau, was mit meinen Daten passieren muss. Nach der Linearisierung der Messergebnisse wird halt auf dem von dem Bediener vorgegebenen Sicherheitsintervall (sagen wir mal, ro = 5%) die "Glocke" zu jedem Messwert gebildet, die Ergebnisse die innerhalb vom 95% Interwall liegen ausgewertet und die restlichen 5% verworfen. Dann hat der Bediener die Möglichkeit, sich entweder den gemittelten Wert aus den 95% (den "Balken" ) in dem Gesamtgraph oder eben die Einzeldarstellung der Messwerte zu einer bestimmten X-Position des Sensors in dem Einzelgraph anzuschauen. Recht simpel eigentlich.

Mathlab und Labwiev ist auch ne coole Sache, aber man sollte es nicht übertreiben mit irgendwelchen Auswert-Rechnern im industriellen Umfeld. Da kommt einfach ne Steuerung rein und gut ist.
Wegen der 416er CPU: Wieso, die ist doch eigentlich mit wenigen mS Zykluszeit doch recht fit, gerade für schnelle Abläufe ? Klar muss sie in der Anlage auch noch etwas anderes machen, als die Messwete verarbeiten, aber trotzdem die 400er steuern ja ganze Produktionsstraßen problemlos. Mein Sensor fährt etwa 10 Messwerte ab pro Sekunde, das sind 100mS für nen Messwet. Sollte reichen ?


----------



## rostiger Nagel (23 Juni 2014)

um bei Mathlab zu bleiben, du hattest doch über einen IPC nachgedacht, dann nimm doch
gleich die Soft SPS mit rein. Zusätzlich hat Siemens ein ODK für Mathlab. Preiswerter und
Leistungsfähiger als eine 416 ist der der IPC eh. Irgenwo hatte der JesperMP auch mal ein über
ein preiswertes Tool gepostet womit du deine Kurve auch darstellen kannst.


----------



## ducati (23 Juni 2014)

Draco Malfoy schrieb:


> Wegen der 416er CPU: Wieso, die ist doch eigentlich mit wenigen mS Zykluszeit doch recht fit, gerade für schnelle Abläufe ? Klar muss sie in der Anlage auch noch etwas anderes machen, als die Messwete verarbeiten, aber trotzdem die 400er steuern ja ganze Produktionsstraßen problemlos. Mein Sensor fährt etwa 10 Messwerte ab pro Sekunde, das sind 100mS für nen Messwet. Sollte reichen ?



Hast Du schon mal eine PCS7 Anlage gebaut?

Bei unseren PCS7-Anlagen (Prozessautomatisierung) ist ne 416 in der Regel schon sehr ausgelastet. Und selbst ne 417 hat bei Verwendung der APL schon ne Menge zu tun. Das liegt einfach an der Größe der Bibliotheken. Unter 100ms Zykluszeit kommt bei uns selten eine CPU. Durch die Weckalarme kann man aber etwas Code in nen schnellen (50ms) legen und etwas in nen langsamen (500ms).

Ob bei Dir jetzt noch was reinpasst hängt einfach davon ab, was schon drin ist und wie aufwändig Deine Statistikberechnung ist und wie schnell die Berechnungen ausgeführt werden müssen.

Gruß.


----------



## Larry Laffer (23 Juni 2014)

```
// Häufigkeit berechnen -----------------------------------------------------------------------------------------------
   // letzte Kurve löschen
   FOR i:= 1 TO cCheck_max BY 1 DO 
      Kurven_Werte.Haeufigkeit [i] := 0 ;
   END_FOR ;    
   // Schrittweite für das Häufigkeits-Array errechnen
   // -> aus maximalem und mininimalem Wert der Quelldaten
   intern.Raster_Haeufigkeit := (Kurven_Werte.Haeufigkeit_max_XSkala - Kurven_Werte.Haeufigkeit_min_XSkala) / INT_TO_REAL(cCheck_max) ;
   // Quelldaten durchsuchen und feststellen in welches Häufigkeits-Raster die Werte fallen
   FOR i:= 1 TO cCheck_max BY 1 DO 
      h_Wert := Kurven_Werte.Trend [i] - Kurven_Werte.Haeufigkeit_min_XSkala ;
      j := REAL_TO_INT(h_Wert / intern.Raster_Haeufigkeit) ;
      IF (j < 1) THEN j := 1 ; END_IF ;
      IF (j > cCheck_max) THEN j := cCheck_max ; END_IF ;
      Kurven_Werte.Haeufigkeit [j] := Kurven_Werte.Haeufigkeit [j] +1 ; 
   END_FOR ;    
   Kurven_Werte.Haeufigkeit_max_YSkala := Int_to_Real(cCheck_max) ;
   
   // Scheitelpunkt der Häufkeitskurve bilden
   intern.Haeufigkeit_Peak := 0 ;
   FOR i:= 2 TO cCheck_max-1 BY 1 DO 
      IF (Kurven_Werte.Haeufigkeit [i] > intern.Haeufigkeit_Peak) THEN intern.Haeufigkeit_Peak := Kurven_Werte.Haeufigkeit [i] ; END_IF ;
   END_FOR ;    
  
   // min.-Anstiegs-Gradient der Häufkeitskurve bilden  (linke Seite)
   intern.Haeufigkeit_minGrad := 0.0 ;
   FOR i:= 2 TO cCheck_max-1 BY 1 DO 
      IF (Kurven_Werte.Haeufigkeit [i] > (intern.Haeufigkeit_Peak / 3)) THEN
         intern.Haeufigkeit_minGrad := (INT_TO_REAL(i) * intern.Raster_Haeufigkeit) + Kurven_Werte.Haeufigkeit_min_XSkala ; 
         EXIT ;
      END_IF ;
   END_FOR ;    
   
   // max.-Anstiegs-Gradient der Häufkeitskurve bilden  (rechte Seite)
   intern.Haeufigkeit_maxGrad := INT_TO_REAL(cCheck_max) ;
   FOR i:= cCheck_max-1 TO 2 BY -1 DO 
      IF (Kurven_Werte.Haeufigkeit [i] > (intern.Haeufigkeit_Peak / 3)) THEN
         intern.Haeufigkeit_maxGrad := (INT_TO_REAL(i) * intern.Raster_Haeufigkeit) + Kurven_Werte.Haeufigkeit_min_XSkala ; 
         EXIT ;
      END_IF ;
   END_FOR ;  
   
   // wo liegt die Kurve im Auswertebereich und wie "breit" ist sie  
   Kurven_Werte.Haeufigkeit_Streuung := intern.Haeufigkeit_maxGrad - intern.Haeufigkeit_minGrad ;
   Kurven_Werte.Haeufigkeit_ScheitelLage := (Kurven_Werte.Haeufigkeit_Streuung / 2.0) + intern.Haeufigkeit_minGrad ;
```

Hallo Draco,
hier mal ein Code-Beispiel von mir, so wie ich es verwende - ich hoffe, du kannst damit etwas anfangen - sonst einfach Rückfragen ... 8)

Bei deiner Problematik mit der Kurven-Linearisierung bin ich mir nicht sicher, ob ich es richtig verstanden habe.
Du scannst mehrfach den gleichen Bereich ab und speicherst die Daten als eine Art Profilkurve f(x) ab.
Nun möchtest du diese "mehreren" Kurven zu einer neuen kumulierten (und ggf. geglätteten) Kurve umrechnen ?

Ansonsten kann ich die hier geäußerten Bedenken bezüglich der Fähigkeit einer SPS derartige Aufgaben zu bewältigen nicht teilen.
Es ist natürlich hierbei immer auch noch eine Frage, was die SPS sonst noch zu tun hat ...

Gruß
Larry


----------



## ducati (23 Juni 2014)

rostiger Nagel schrieb:


> um bei Mathlab zu bleiben, du hattest doch über einen IPC nachgedacht, dann nimm doch
> gleich die Soft SPS mit rein. Zusätzlich hat Siemens ein ODK für Mathlab. Preiswerter und
> Leistungsfähiger als eine 416 ist der der IPC eh. Irgenwo hatte der JesperMP auch mal ein über
> ein preiswertes Tool gepostet womit du deine Kurve auch darstellen kannst.



Hmm, früher gabs nen Matlab AddOn auch für PCS7 (dass lief aber m.M. nach auf nem IPC und nicht innerhalb der WinAC). Bei den neuen PCS7 Versionen bin ich mir da nicht sicher.

@rn Du meinst das WinAC Target? http://support.automation.siemens.com/WW/view/de/56969417


Zum WinAC, das gibt's als mEC, als Microbox für PCS7 oder auch auf dem BOX PC 627C, aber ob es generell auf jedem IPC für PCS7 freigegeben ist, würde ich auch erstmal prüfen, ich denke eher nein.

Gruß.


----------



## ducati (23 Juni 2014)

Larry Laffer schrieb:


> Ansonsten kann ich die hier geäußerten Bedenken bezüglich der Fähigkeit einer SPS derartige Aufgaben zu bewältigen nicht teilen.
> Es ist natürlich hierbei immer auch noch eine Frage, was die SPS sonst noch zu tun hat ...



Die PCS7-SPSn sind in der Regel ziemlich voll, zumindest wenn es sich um reale Anlagen handelt und nicht um ne akademische Labor-Versuchsanlage... Das liegt einfach an den dicken PCS7-Bibliotheken (PTE400 oder APL egal)... und daran, dass PCS7 in der Regel für große Anlagen verwendet wird, und nicht für ne kleine Minimaschine.

Wenn jetzt für die Statistikberechnung alle 100ms ausreicht, wird es sicherlich klappen. Bei 10ms und langem Code wird's schon schwieriger. Also wie Du und auch ich ja schon geschrieben haben, es kommt drauf an, wie aufwändig die Berechnung ist.

Gruß.


----------



## Draco Malfoy (23 Juni 2014)

Moin !



> Bei deiner Problematik mit der Kurven-Linearisierung bin ich mir nicht sicher, ob ich es richtig verstanden habe.
> Du scannst mehrfach den gleichen Bereich ab und speicherst die Daten als eine Art Profilkurve f(x) ab.
> Nun möchtest du diese "mehreren" Kurven zu einer neuen kumulierten (und ggf. geglätteten) Kurve umrechnen ?


Nun, sagen wir mal ich scanne einen Messwert f(x) an der Stelle x. Jetzt ist es so, daß die Messgröße keinen linearen Zusammenhang zu dem Sensorsignal aufweist. Daher werden die Kalibrierwerte auf den Plan gerufen, welche insgesamt eine Korrelationsgerade (Methode der kleinsten Quadrate) ergeben. Anhand dieser Geraden wird ausgewählt, welcher Realwert F(x) meinem gemessenen Fiktivwert f(x) entspricht.

Jetzt habe ich aber diese eine Stelle x nicht 1 mal, sondern Y mal abgefahren, und alles zusammen ergibt natürlich eine Gauß'sche Verteilung, wo möglicherweise auch ein Paar "krumme" Werte drin liegen. Diese werdem auf meinem vorher gewählten Sicherheitsinterwall (sagen wir mal, ro = 5%) ausgefiltert und die restlichen 95% gemittelt und dem Kunden in einem Balken dargestellt. Wenn er aber diesen Balken anklickt, so möchte er aber die zu dieser Stelle X zugehörige Glockenkurve mit allen Y gemessenen Werten und deren Verteilung sehen.

Die Idee mit einem separaten IPC + MathLab ist in der Tat nicht völlig abwegig, allerdings müsste man hier schon sowohl die Lizenzkosten als auch den realen Implementierungsaufwand korrekt rechnen. Wie heißt denn dieses Verbindungsgateway zwischen PCS 7 und dem Mathlab ? Da weiß ich noch gar nicht so viel von.

Wegen Kostenlage: 400er gibts derzeit in guter Kondition bei Händlern für wenig Geld, ich muss nicht alles neu von Siemens kaufen. Und möglicherweise haben einige Kollegen ja schon etwas rumliegen.

Was da sonst noch laufen soll: Verfahrbausteine für ne gewisse Postionierungsgeschichte + möglicherweise Überwachung vom Extrusionsvorgang.


----------



## Larry Laffer (23 Juni 2014)

Draco Malfoy schrieb:


> Nun, sagen wir mal ich scanne einen Messwert f(x) an der Stelle x. Jetzt ist es so, daß die Messgröße keinen linearen Zusammenhang zu dem Sensorsignal aufweist. Daher werden die Kalibrierwerte auf den Plan gerufen, welche insgesamt eine Korrelationsgerade (Methode der kleinsten Quadrate) ergeben. Anhand dieser Geraden wird ausgewählt, welcher Realwert F(x) meinem gemessenen Fiktivwert f(x) entspricht.



Das heißt, du ermittelst für jeden eingehenden (gemessenen) Wert wo er zu deiner Vorgabe-Kurve liegt ...?
Dein Ergebnis (ungeachtet von Linearisierungen und Anpassungen) müßte dann also eine Art Gauß-Hügelkette sein (also eine Anzahl n Gauß-Kurven, die abhängig von der x-Position hintereinander liegen). Innerhalb dieser Kurven willst du dann den jeweiligen Peak ermitteln (vermute ich mal) um daraus die wahrscheinlichste Ausgabe-Kurve zu bestimmen - passt das so in etwa ?

Von wie vielen x und y-Werten sprechen wird denn hier pro Messung (also pro 1 Fahrt) ?

Gruß
Larry


----------



## Draco Malfoy (23 Juni 2014)

Larry Laffer schrieb:


> Das heißt, du ermittelst für jeden eingehenden (gemessenen) Wert wo er zu deiner Vorgabe-Kurve liegt ...?
> Dein Ergebnis (ungeachtet von Linearisierungen und Anpassungen) müßte dann also eine Art Gauß-Hügelkette sein (also eine Anzahl n Gauß-Kurven, die abhängig von der x-Position hintereinander liegen). Innerhalb dieser Kurven willst du dann den jeweiligen Peak ermitteln (vermute ich mal) um daraus die wahrscheinlichste Ausgabe-Kurve zu bestimmen - passt das so in etwa ?


Sehr richtig, genau so möchte ich verfahren.


> Von wie vielen x und y-Werten sprechen wird denn hier pro Messung (also pro 1 Fahrt) ?


Eine Fahrt sind etwa 28 Messungen (je nach Rollenbreite). Eine Rolle läuft ca. 3,5h und pro Fahrt braucht mein Sensor 3-4 Sekunden etwa. Könnten schlimmstenfalls auch 5-6 sein.
D.h. es sind etwa 4200 Messungen je eine x Position. Wobei die müssen natürlich nicht einzeln dargestellt werden.


----------



## GFI (23 Juni 2014)

Hallo Draco,

ich glaube die gleiche/ähnliche Aufgabe hatte ich bereits vor ein paar Jahren bei einem Kunden gelöst,
handelt es sich vielleicht um Flachfolienextrusion und Profilmessung?

Die mathematischen Aufgaben hatte ich in meinem Visu Fontend ausgelagert (Korrelationsgerade und cpk Werte), dies war ein IPC, der Code dazu wurde damals in Pascal geschrieben, dieser sollte relativ einfach in SCL portierbar sein, 
nur habe ich bedenken diese Berechnungen in einer SPS ablaufen zu lassen, da es sich um mathematische Operationen handelt, die in einer "Schleife, FOR TO NEXT" laufen müssen. 

Eine normale SPS (S7-400er) ist nicht besonders schnell bei mathematischen Operationen, und wenn man diese Aufgaben in der SPS programmiert, steigt bei Berechnung die Zyklus Zeit immens an.

Falls DU Interesse an den Code (Biblio) in Pascal für die Funktionen hast kurze Meldung.


----------



## ducati (23 Juni 2014)

Draco Malfoy schrieb:


> Die Idee mit einem separaten IPC + MathLab ist in der Tat nicht völlig abwegig, allerdings müsste man hier schon sowohl die Lizenzkosten als auch den realen Implementierungsaufwand korrekt rechnen. Wie heißt denn dieses Verbindungsgateway zwischen PCS 7 und dem Mathlab ? Da weiß ich noch gar nicht so viel von.
> 
> Wegen Kostenlage: 400er gibts derzeit in guter Kondition bei Händlern für wenig Geld, ich muss nicht alles neu von Siemens kaufen. Und möglicherweise haben einige Kollegen ja schon etwas rumliegen.
> 
> Was da sonst noch laufen soll: Verfahrbausteine für ne gewisse Postionierungsgeschichte + möglicherweise Überwachung vom Extrusionsvorgang.


Ist das ne Neuanlage welche Du komplett in PCS7 umsetzen sollst??? Oder ist PCS7 nicht zwingend? Wenn Du auch noch ne komplette PCS7 Anlage ohne entsprechende Kenntnisse aufbauen sollst dann viel Erfolg. Das ist überhaupt nicht mal eben gemacht!

Bei PCS7 sollte man nix basteln, da gibt es genaue Regeln, was, wie und warum gemacht werden muss. Ohne Einarbeitung wird das nix ordentliches. Da hast Du mal noch ne schöne Nebenbaustelle aufgemacht.

Welche Matlabkopplung funktioniert und zugelassen ist, hängt von der verwendeten PCS7-Version ab.


viel Spass.


----------



## ducati (23 Juni 2014)

Draco Malfoy schrieb:


> Wie heißt denn dieses Verbindungsgateway zwischen PCS 7 und dem Mathlab ? Da weiß ich noch gar nicht so viel von.



Matlab/Simulink DDE Client: http://www.automation.siemens.com/w...SIMATICPCS7_STPCS71_complete_English_2010.pdf Seite 29

für PCS7 8.x gibt's das aber scheinbar nicht mehr. Also nur bis 7.1

Gruß.


----------



## Draco Malfoy (23 Juni 2014)

ducati schrieb:


> Ist das ne Neuanlage welche Du komplett in PCS7 umsetzen sollst??? Oder ist PCS7 nicht zwingend? Wenn Du auch noch ne komplette PCS7 Anlage ohne entsprechende Kenntnisse aufbauen sollst dann viel Erfolg. Das ist überhaupt nicht mal eben gemacht!
> 
> Bei PCS7 sollte man nix basteln, da gibt es genaue Regeln, was, wie und warum gemacht werden muss. Ohne Einarbeitung wird das nix ordentliches. Da hast Du mal noch ne schöne Nebenbaustelle aufgemacht.
> 
> ...


Ich weiß nicht, warum bei Dir jeder meiner Posts den Eindruck erweckt, als ob ich irgendwie so gar nichts können würde. Also mit nem CFC Plan komme ich so gerade noch zurecht  Das PCS 7 wurde speziell wegen der Spezifik der Extruder-Steuerung ausgewählt weil es da schon fertige Bausteine bzw. Librarys für PCS 7 gibt und wegen der Anbindung an die Prozessleitstelle. Möglicherweise kommt da aber ne separate 400er für den Extruder an sich zum Einsatz. Man muss sich das so vorstellen, ein Extruder is ne große Anlage aber die Messausrüstung ist nur ein kleiner Teil davon. Außerdem ist nicht gesagt worden, daß ich komplett alles alleine mache. Um mal einen Klassiker zu zitieren: "Meine Aufgabe heute Nacht ist Saruman" ...also in meinem Fall die Messausrüstung. 

P.S. Danke für den Link zum Gateway


----------



## Blockmove (23 Juni 2014)

PCS7 für einen Extruder?
Ist das nicht etwas Overkill?

Also unsere Extruder sind auch nicht gerade klein, aber als SPS reicht ne 315-CPU.
Temperierung wird bei uns durch Hardware-Regler erledigt und die Antriebstechnik erfolgt durch Masterdrives.
Dicken- / Profilmessung läuft auf einem IPC.

Gruß
Dieter


----------



## Thomas_v2.1 (23 Juni 2014)

Du kannst die Berechnung auch in den OB90 auslagern. Bei den geforderten Berechnungen sollte es doch egal sein wenn das Ergebnis erst in 5 oder 10 Sekunden vorliegt.

Und nur mal abgeschätzt: Bei einer 416 ist für Gleitkommaberechnungen eine Zeit von 90ns angegeben. Das wären theoretisch ~ 10 Millionen Operationen pro Sekunde. Mal angenommen du zwackst dir nur 1% der Leistung für deine Berechnungen ab, kannst du schon einiges in der SPS machen. Für so einen einfachen Anwendungsfall kommt doch keiner mit Matlab, das ist mit Kanonen auf Spatzen geschossen.


----------



## Draco Malfoy (23 Juni 2014)

Thomas_v2.1 schrieb:


> Du kannst die Berechnung auch in den OB90 auslagern. Bei den geforderten Berechnungen sollte es doch egal sein wenn das Ergebnis erst in 5 oder 10 Sekunden vorliegt.


Korrekt, die "Ankunftszeit" der Berechnung interessiert in der Tat eigentlich keinen.


> Und nur mal abgeschätzt: Bei einer 416 ist für Gleitkommaberechnungen  eine Zeit von 90ns angegeben. Das wären theoretisch ~ 10 Millionen  Operationen pro Sekunde. Mal angenommen du zwackst dir nur 1% der  Leistung für deine Berechnungen ab, kannst du schon einiges in der SPS  machen. Für so einen einfachen Anwendungsfall kommt doch keiner mit  Matlab, das ist mit Kanonen auf Spatzen geschossen.


Naja, da haben wir ja erst mal wie Du sieht geteilte Meinungen. Ich habe selber noch keine empirischen Erfahrungen mit den 400er CPUs und mathematischen Berechnungen, aber oben schreiben Leute daß es irgendwie nicht so cool sein sollte. Ich seh das auch so, daß ich die Sachen prinzipiell eher lieber in die SPS packen würde, vorausgesetzt, daß man damit allen Anwendungen gerecht wird.


----------



## Thomas_v2.1 (23 Juni 2014)

Du musst auch noch dabei miteinrechnen, dass wenn du die Datenanalyse in WinCC oder einem Programm was die Daten aus WinCC ausliest, diese Kosten Verursachen. Je nach Lizenzmodell kosten 4000 PVs schon einiges, bzw. bei PCS7 mit Abrechnung nach Prozessobjekten werden dir für so viele Variablen entsprechende POs abgebucht. Und dann hast du eine Lösung die du aus dem PCS7 Wust für andere Projekte nie mehr herauslösen kannst.

Wenn man sowas auf PC Ebene macht, dann mit einem separaten Programm das einen eigenen Kommunikationstreiber mitbringt. In PCS7 würde ich das nur machen, wenn das eine Lösung werden soll die auch auf dieser Ebene vermarktet werden soll.

Ich würde mir als erstes für deine Berechnungen ein paar Quellcodes anschauen, und abschätzen wie viele Iterationensschritte für die Berechnungen notwendig sind. Kommen dabei hunderttausend oder hundertmillionen bei raus. Und wie erhöht sich die Laufzeit wenn die Anzahl der Messwerte erhöht wird, linear, quadratisch etc.


----------



## Draco Malfoy (23 Juni 2014)

Blockmove schrieb:


> PCS7 für einen Extruder?
> Ist das nicht etwas Overkill?


Du hast den Extruder dazu nicht gesehen. Wobei, vielleicht denke ich einfach etwas zu formalistisch und man würde es auch mit einer kleineren Steuerung lösen können.


> Also unsere Extruder sind auch nicht gerade klein, aber als SPS reicht ne 315-CPU.
> Temperierung wird bei uns durch Hardware-Regler erledigt und die Antriebstechnik erfolgt durch Masterdrives.
> Dicken- / Profilmessung läuft auf einem IPC.


Die Hardware-Regler sollen eben entfallen und alle über PID-Control in die CPU integriert werden. Antriebstechnik wird auch irgendwie mit S120 oder ähnlichem laufen. Denke ich. Jedenfalls mit Antrieben, die nativ Gleichlauf können. Die Idee dazu ist, der Produktionsleiter wirft aus seinem Büro die Vorgabe runter, welche Folie in wie lang produziert werden soll, und die Extruder Steuerung weiß dann schon sofort, wie sie den Extruder zu fahren hat, und welche Granulatzusammensetzung dazu gehört. So in Etwa.


> Ich würde mir als erstes für deine Berechnungen ein paar Quellcodes  anschauen, und abschätzen wie viele Iterationensschritte für die  Berechnungen notwendig sind. Kommen dabei hunderttausend oder  hundertmillionen bei raus. Und wie erhöht sich die Laufzeit wenn die  Anzahl der Messwerte erhöht wird, linear, quadratisch etc.


Das wäre sicherlich ein sinnvoller Ansatz.


----------



## ducati (23 Juni 2014)

Draco Malfoy schrieb:


> Ich weiß nicht, warum bei Dir jeder meiner Posts den Eindruck erweckt, als ob ich irgendwie so gar nichts können würde.



Nee, dass Du nix kannst hab ich nicht geschrieben. Nur Dein Projektleiter oder wer auch immer hat Dir schone einige Nüsse aus verschiedenen Bereichen zum Knacken gegeben... (Wenn man mal alle Threads im Zusammenhang betrachtet). Jetzt suchst Du überall nach fertigen Bausteinen oder fertigem Code...

Wenn ich PCS7 und WinCCflex in einem Satz lese, krieg ich schon immer Bauchschmerzen. Sicherlich kann man das händisch verbinden, der Sinn von PCS7 ist aber u.a. dass die WinCC (nicht Flex) Bilder mehr oder weniger automatisch generiert werden. Zumindest was die Variablenanbindung und Erstellung der Bausteinsymbole angeht. Das hast Du für WinCCflex alles nicht. 

Zur 416 hab ich nicht geschrieben, dass es nicht funktioniert. Sondern nur dass Du prüfen sollst, ob noch genügend Rechenkapaziät vorhanden ist. Da meiner Erfahrung nach es bei PCS7-Anagen schnell eng werden kann.

Wenn Ihr aber PCS7 eigentlich nur als Step7+CFC+SCL nutzt und auch nicht viel von der APL dann siehts schon wieder anders aus. Aber dazu hast Du im Detail ja noch nichts geschrieben.

Gruß.


----------



## Blockmove (23 Juni 2014)

Draco Malfoy schrieb:


> Die Hardware-Regler sollen eben entfallen und alle über PID-Control in die CPU integriert werden.



Haben wir beim Retrofit damals auch andiskutiert aber wieder verworfen. Wir geben die Sollwerte und die Betriebsmodi über Profibus vor und den Rest machen die Regler alleine.
Mit simplen PID ist es bei einem großem Extruder mit x Zonen unserer Erfahrung nach nicht getan.

Antriebstechnik ist heute kein riesen Thema mehr ... Es sei denn du willst eine automatische Regelung abhängig vom der Dickenmessstation.
Irgendwie ist so ein Extruder wie eine alte Dampflok. Du hast viele Räder zum Drehen

Gruß
Dieter


----------



## Draco Malfoy (23 Juni 2014)

ducati schrieb:


> Nee, dass Du nix kannst hab ich nicht geschrieben. Nur Dein Projektleiter oder wer auch immer hat Dir schone einige Nüsse aus verschiedenen Bereichen zum Knacken gegeben...


Möglich. Wir sind hier nicht bei "Wünsch Dir Was" wie ein Schulkamerad von mir zu sagen pflegte. Einige Aufgabenstellungen sind ja auch teilweise bereits gelöst worden, und auch recht erfolgreich, möchte man sagen.


> Mit simplen PID ist es bei einem großem Extruder mit x Zonen unserer Erfahrung nach nicht getan.


Wie machen es denn die Hardware-Regler, das sind doch auch PID Regler oder etwa nicht ? Bloß, jeder einzelne steuert eine ihm zugewiesene thermische Zone ?

@*ducati:* bei allem Respekt, ich find es nicht korrekt so darzustellen als wollte ich nur andere für mich meine Arbeit machen lassen (Zitat "suchst überall nach fertigen Bausteinen und fertigem Code") weil anzugucken wie es andere machen schadet erst mal nicht, und im Normalfall gibt es ja fast zu jedem Thema irgendwas Open Source, um die Arbeit zu erleichtern und das Rad nicht zwei mal erfinden zu müssen. Die Zusammenschaltung der Komponenten und die Anpassung an die konkrete Anwendung verbunden mit der Erstellung der HMI und dem Tuning im Feld macht sich dadurch ja immer noch nicht von alleine.


----------



## Larry Laffer (24 Juni 2014)

Hallo,

ich muß Draco hier zustimmen.
Auch ich kann weder in seiner Anfrage noch in seiner Idee etwas ehrenrühriges entdecken.
Und auch nach 3maligem Hinsehen wüßte ich im Moment nichts gegen den Ansatz an sich zu sagen - die Form der Visualisierung und der weitere Misch-Masch mal abgesehen. 

Gruß
Larry


----------



## ducati (24 Juni 2014)

Thomas_v2.1 schrieb:


> Bei einer 416 ist für Gleitkommaberechnungen eine Zeit von 90ns angegeben.



die 317 hat 160ns und die 319 54ns. Also soo viel schneller ist die 416 nun auch nicht im Vergleich. Aber durch den relativ großen Speicher verleitet sie dazu, viel Code reinzupacken, was dann eben die Zykluszeit ziemlich schnell erhöht.

Gruß.


----------



## bike (24 Juni 2014)

Draco Malfoy schrieb:


> , und im Normalfall gibt es ja fast zu jedem Thema irgendwas Open Source, um die Arbeit zu erleichtern und das Rad nicht zwei mal erfinden zu müssen..



Stellst du eure Entwicklung auch als Open Source zur Verfügung?
ducati hat recht, du stellst viele Fragen, aber die Ergebnisse, die ggF mit Hilfe von hier entstanden, habe ich noch nicht gesehen.
Viele hier würden gern erfahren wie das eine oder andere Problem gelöst werden kann. 
Daher meint er vermutlich, dass es nur eine Einbahnstraße ist.

Bitte teile uns mit wie du PCS7 mit WinCCflex angebunden hast, denn wir haben es nicht wirklich geschafft.
Es ging nur PCS7 und CPU 416 oder WinCCflex und Step7.


bike


----------



## ducati (24 Juni 2014)

bike schrieb:


> Bitte teile uns mit wie du PCS7 mit WinCCflex angebunden hast, denn wir haben es nicht wirklich geschafft.
> Es ging nur PCS7 und CPU 416 oder WinCCflex und Step7.



Naja, das geht schon  Du nutzt einfach PCS7 als Step7  Und verbastelst das über DBs irgendwie mit dem evtl. noch vorhandenen PCS7-Teil. Aber alles Handarbeit und nicht wirklich PCS7-konform und auch nicht wirklich schön 

Gruß


----------



## Draco Malfoy (24 Juni 2014)

bike schrieb:


> Stellst du eure Entwicklung auch als Open Source zur Verfügung?


Im Tausch geht einiges


> ducati hat recht, du stellst viele Fragen, aber die Ergebnisse, die ggF  mit Hilfe von hier entstanden, habe ich noch nicht gesehen.


Wat willst Du denn genau sehen ?


----------



## Blockmove (24 Juni 2014)

Draco Malfoy schrieb:


> Wie machen es denn die Hardware-Regler, das sind doch auch PID Regler oder etwa nicht ? Bloß, jeder einzelne steuert eine ihm zugewiesene thermische Zone ?



Nein, es sind nicht nur simple PID-Regler. Ich weiß nicht welches Material oder Granulat bei deinem Projekt verarbeitet wird, aber es gibt in den Plastifizierzonen schon nette thermische Effekte.


----------



## Draco Malfoy (24 Juni 2014)

Wie wird das denn dann geregelt ? So weiß ich weiß, kommt es bei unseren Reglern darauf an, möglichst schnell die Soll-Temperatur zu erreichen, und die dann eben einigermaßen schwingungsfrei zu halten. Solange der Nachschub an Material halbwegs konstant bleibt, lässt sich das mit richtig eingemessenen PID-Reglern auch realisieren. Das Granulat wird auch nicht schlagartig flüssig, aber so auf 1-2° Grad genau wird die T konstantgehalten. Wie wird das bei euch gemacht ?


----------



## Blockmove (25 Juni 2014)

Bei unseren Extrudern entsteht in der Plastifizierzone sehr viel Prozesswärme.
Hier muss dann Wärme abgeführt werden.


----------



## Draco Malfoy (2 Juli 2014)

Ich habe jetzt übrigens eine definitive Rückmeldung, daß der Sensor-Interface eine Aktualisierung der Messwerte lediglich alle 150mS vornimmt, d.h. schneller können wir sowieso nicht messen. Damit sollte doch auch eine maximal lahmarschige 400er CPU klarkommen. Jetzt noch die Frage, wie mache ich nochmal die Kopplung zwischen TIA und STEP 7 bzw. PCS 7, sollte ich zu einem Comfort Panel zwecks Graphdarstellung greifen wollen ? 

Bzw. wie würde es aussehen mit nem WinCC Runtime auf nem IPC, kann ich dort XY Grafiken darstellen ? Hätte den Vorteil, daß man systemtechnisch innerhalb von PCS 7 verbleibt und man kein unpassendes Zeug miteinander verkoppeln muss, was sich gegenseitig nicht mag...


----------



## Thomas_v2.1 (2 Juli 2014)

Draco Malfoy schrieb:


> Jetzt noch die Frage, wie mache ich nochmal die Kopplung zwischen TIA und STEP 7 bzw. PCS 7, sollte ich zu einem Comfort Panel zwecks Graphdarstellung greifen wollen ?



Für die Funktion einen FB anlegen. Alle Werte die angezeigt werden sollen auf einen Out-Parameter schreiben. Die Variablen die ins WinCC gemappt werden sollen mit dem Attribut S7_m_c versehen.
Für die Anbindung an ein Panel einen separaten Datenbaustein anlegen. Die DB-Nummer muss sich im dafür reservierten Bereich befinden (Einstellung CFC übersetzen). Out-Parameter des FBs mit den DB-Variablen verschalten. Das Panel greift dann nur auf diesen Schnittstellen-DB zu.


----------



## Draco Malfoy (7 Juli 2014)

Alles klar, danke.


----------



## Draco Malfoy (13 März 2015)

Da sich hier manche User für den Ausgang der Angelegenheit interssiert haben, hier ein Paar Fotos (leider nur Handypics).
Anlage ist erfolgreich in Betrieb gegangen. Der Anlagenteil, der für die Fragesteller hier von Relevanz war, besteht aus

1x S7-416-2DP + TP700 Comfort + WinCC am Arbeitsplatz des Hallenwarts.


----------



## Knaller (13 März 2015)

Moin.  
Was macht denn der MKD Antrieb in der Anlage?
Gruß Herbert


Sent from my iPhone using Tapatalk


----------



## Draco Malfoy (13 März 2015)

Knaller schrieb:


> Moin.
> Was macht denn der MKD Antrieb in der Anlage?



Positionieren. Zusammen mit DKC 03.3-100-7-FW.


----------

