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

Zuviel Werbung?
-> Hier kostenlos registrieren
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ß.
 
Code:
// 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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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ß.
 
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ß.
 
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
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.
 
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
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.
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
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
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.
 
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
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.
 
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ß.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
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.
 
Zuletzt bearbeitet:
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
 
Zurück
Oben