TIA zügige Prozessdatenspeicherung

[ZottelMD]

Zuviel Werbung?
-> Hier kostenlos registrieren

Huhu,

ich habe mal eine Orientierungsfrage.

Ich bearbeite einen kleinen Leistungsprüfstand. Ich möchte 3 Messmodis fahren.

• Messmodus 1 - konstante Drehzahl:

Ich sage zwei vorhandenen SIEMENS PSSM's, die sich gegenüber stehen und durch eine starre Achse des DUT's verbunden sind, sie sollen z. B. die Solldrehzahl 100 rpm konstant halten. Dann 200. Dann 300. Usw.
Während dessen geben ich mit dem DUT z. B. Vollgas und es wirkt sogesehen eine Störgröße auf die Hinterachsse ein, die die Drehzahl gern beschleunigen will. Die Antriebstechnik (S1210) wird dagegen regeln und versuchen die Solldrehzahl zu halten. Anhand der sich einstellenden Momente, kann man so Stück für Stück eine Motorkennlinie vom DUT rekonstruieren/messen.
In diesem Messmodus speicher ich die Messwerte, bzw dem Mittelwert einer 3 Sekunden Mittelung, pro Frehzahlstufe in einer MS SQL Datenbank. Also je nachdem, wie zügig man misst, vielleicht alle 1 Minute ein Wert.

• Messmodus 2 - konstantes Lastmoment durch Servos

Hier sieht die Sache schon anders aus. In diesem Modus wird die Last der Servos durch MC_TorqueLimitting begrenzt. Z. B. maximal 20 Nm und die Solldrehzahl 0 rpm vorgegeben. Gibt man jetzt während dessen mit dem DUT z. B. Vollgas, so wird die im DUT enthaltene Motorkennlinie mal mehr oder mal weniger Drehmomentüberschuss zur konstanten Servolast-Kennlinie aufweisen und es werden sich mal größere und mal kleinere Drehzahländerungen einstellen. Aus der Kenntnis der Drehzahlkurz, die sich bei gewählter Servolast einstellt, kann man ebenfalls auf die vom DUT abgegebene Leistung über dem Drehzahlband schließen und eine Motorkennlinie rekonstrieren. Allerdings ist hier schon die Anforderung, möglichst viele Messpunkte zu haben, was in der AUswertung das Ergebnis verbessern wird. Ich denke hier z. B. an eine Abtastung von Drehmoment und Drehzahl in den Servoantrieben mit 20 bis 50 ms Abtastzeit. Heißt, wenn eine Messfahrt vielleicht 10 Sekunden dauern könnte, dann kommen schon so 500 Werte zusammen, die in der Zeit geloggt werden wollen.

• Messmodus 3 - konstante Beschleunigung

In diesem Modus ist es ähnlich wie in Modus 2. Hier sollen die Servos eine konstante Beschleunigung erfahren, sprich eine lineare Drehzahlrampe anfahren. Heißt man würde den Servos sagen, fahrt mal von 0 bis z. B. 1000 rpm hoch und das in 10 Sekunden. Kurz nach dem Start gibt man mit dem DUT wieder Vollgas und lässt die Störgröße wieder wirken. Auch hier muss die S120 Antriebstechnik der Störgröße entgegenwirken, damit die lineare Rampe ja realisiert wird. Auch hier müsste man viele Messpunkte/Prozessdaten loggen, und das zügig.



Prozessdaten wie effizient speichern?
Bisher habe ich berührung gemacht mit dem Speichern von Messdaten in einem Array und dann das Array Scheibchenweise in die SD-Card der CPU transferieren (Datenlogs anlegen). Von dort kann man dann via Webbrowser die Daten/die Logs als CSV herunter laden. Der Nachteil hier ist, dass die Kommandos langsam sind und eher am Ende einer Messung ausgeführt werden sollen. Der weitere Nachteil ist, dass Flash-Speicher immer nur eine begrenzte Anzahl von Öffnen, Lesen, Schreiben, Schließen abkann. Es ist also eigentlich keine Variante, wo man viele Prozessdaten häufig (im Millissekundebereich) abspeichern will.Will ich solche häufigen Speichervorgänge ebenfalls wie im Modus 1 durch eine SQL-Datenbank realisieren (TIA v15.1...das Anwendungsbeispiel für v16 geht nicht ohne Weiteres umzusetzen), bleibt das Problem der hohen Kommunikationslast und der Tatsache, dass die Prozessvariablen im HMI ja nie so genau zur Verfügung stehen, jedenfalls nicht so schnell. Derzeit triggere ich im Messmodus 1 das VBS-Script zum Speichern der gemittelten Werte für Drehzahl und Drehmoment, und Datum / Uhrzeit mit einem Bit bei Wertänderung und hoffe natürlich, dass die Prozessvariablen entsprechend aktuell im HMI ankommen.Alternativ könnte man ja wieder alle Daten in einem Array sammeln und am Ende der Messung ein Script triggern, was die Daten aus dem Array ZEile für Zeile in die Datenbank-Tabelle schreibt.Manche reden auch davon, dass sie Rezepte vergewaltigen, mit dem Hintergrund, dass dann Werte mit einem schlag zuverlässig aktualisiert im HMI ankommen.
Wie würde ihr mit der SIEMENS-Technik häufiges Loggen von vielen Daten betreiben.Ich beabsichtige immer

Datum (String)
+ Uhrzeit (String)
+ Drehmoment Servo 1 (LREAL)
+ Drehzahl Servo 1 (LREAL)
+ Drehmoment Drehmomentmesswelle 1 (LREAL)
+ Drehzahl Drehmomentmesswelle 1 (LREAL)
+ Drehmoment Servo 2 (LREAL)
+ Drehzahl Servo 2 (LREAL)
+ Drehmoment Drehmomentmesswelle 2 (LREAL)
+ Drehzahl Drehmomentmesswelle 2 (LREAL)

zu loggen. 10 Spalten.
Die Strings sind im Datum 4+1+2+1+2 = 10 Byte lang (10 Character "YYYY-MM-DD") und in der Zeit 2+1+2+1+2+1+6 = 15 Byte lang (15 Charakter "HH:MM:SS.xxxxxx). LREAL ist ja jeweils 8 Byte groß. Heißt pro Zeile mindestens 89 Byte an payload.
Wie wäre ein effizientes Speicherungskonzept, was die normale Profinet-Kommunikation zwischen PLC und S120 so wenig wie möglich beeinflusst? Wie realisiert ihr solche LoggingAufgaben?
Gruß Basti
p.s.:
- die DUT's sind Bambini GoKarts (max. 4.8 kW)
- Anlagenübersicht als Foto anbei
- Prüfstandsanlage:
1516 CPU
1 x TM_PosInput2
1 x CU320
1 x Rückspeiseeinheit
2 x Single Motor Module
2 x 1FT7-...-Servos
2 x KISTLER Drehmomentmesswellen

 

[JSEngineering]

Moin Basti,

ich würde den Zeitstempel schon erst einmal nicht als String abspeichern sondern als DWORD (Millisekunden seit...). Dann hast Du 4 Byte anstatt 15 Byte. Das Datum würde ich nicht bei jedem Mal abspeichern, sondern einmalig. Die Wahrscheinlichkeit, daß jemand genau zum Tageswechsel testet ist wohl gering. Somit sparst Du Dir weitere 10 Byte. Und die Drehmomente bekommst Du vermutlich aus dem Umrichter: Rohwerte speichern. Als LReal bekommst Du die bestimmt nicht, oder? Dann hast Du am Ende vermutlich nur 36Byte pro Messung.

Es geht zum einen darum, möglichst wenig Zykluszeit zu erzeugen, also möglichst wenig Bearbeitung der Werte während der Laufzeit der Messung.

Dann sollte es Dir eigentlich möglich sein, ein Array mit 1000 Elementen in einem DB zu erzeugen und das während der Laufzeit zu füllen.

Messwerte bearbeiten und wegschreiben kann man dann ggf. im Anschluß der Messung. Wenn der Anwender dann 10 Sekunden warten muß, ist das egal. Aber die Messwerte sind schnell und genau erfaßt.

Im Extremfalle müßte man mit externen Datenloggern arbeiten, die auf die Meßwerterfassung spezialisiert sind. Aber bei 10s Meßdauer bei Dir glaube ich nicht, daß man so weit gehen muß.

 

[ZottelMD]

Zuviel Werbung?
-> Hier kostenlos registrieren

...ich würde den Zeitstempel schon erst einmal nicht als String abspeichern sondern als DWORD (Millisekunden seit...). Dann hast Du 4 Byte anstatt 15 Byte.

Hast recht. Macht keinen Sinn. Hab das nur vom jetzigen Zustand abgeleitet. Jetzt logge ich ja via VBS-Script und SQL Datenbank im Messmodus 1. Da geht das noch, weil nur ein Datensatz vielleicht alle 1 Minute, je nachdem wie viel Messpunkte man erzeugen will.
Nur für Modus 2 und Modus 3 klappt das nicht mehr gut, weil die entsprechenden Variablen selbst bei Einstellung "Wertänderung" ja serienmäßig nur alle 1 s im IPC/HMI aktualisiert werden. Bestensfalls 500 ms und 100 ms. Da ist sozusagen die Kommunikation zwischen PLC und HMI der Flaschenhals. Auf jeden Fall hatte ich es die Tage nie sauber zum Laufen bekommen, dass z. B. meine SIEMENS Zeitstempel sauber mit Nanosekunden in der SQL Datenbank ankommen - Egal, welche Kombination von PLC-Variablen-Typ (DTL, TOD, LDT..etc) und SQL Datentyp (date, time, datetime2, etc.) ich gewählt hatte. Das Datum klappte, die Zeiten nie vollends. Deswegen bin ich dann dahin gegangen, dass ich mit der ladbaren LGF-Bibliothek den gesamten RD_LOC_T-Zeitstemepl in der PLC in einen String wandle und diesen im VBScript splitte. Ich schätze nur deswegen bin ich eben davon ausgegangen, dass ich das auch so in einen DB abegen würde, wenn man eine Lösung findet ohne HMI. Hast völlig recht macht keinen Sinn.

Das Datum würde ich nicht bei jedem Mal abspeichern, sondern einmalig. Die Wahrscheinlichkeit, daß jemand genau zum Tageswechsel testet ist wohl gering. Somit sparst Du Dir weitere 10 Byte.

Schreib ich mir genauso hinter die Ohren. Ich glaube ich geh lieber dahin, dass ich das Datum als einzelne Spalte völlig kicke und baue lieber einen etwaigen Tabellennamen/Dateinamen mit Datum und fortlaufender Nummer. Dann werd ich wie vorgeschlagen nur die ZEiten als DINT sammeln und irgendwo ein "how to" niederschreiben, wie der Benutzer davon auf die Zeiten kommt. Oder man verrechnet es noch einmal nachträglich mit einem VB-Script jau.

Und die Drehmomente bekommst Du vermutlich aus dem Umrichter: Rohwerte speichern. Als LReal bekommst Du die bestimmt nicht, oder? Dann hast Du am Ende vermutlich nur 36Byte pro Messung.

Bis jetzt muss ich ehrlich zu meiner Schande sagen, dass ich im Rahmen meiner Abschlussarbeit hier nur auf dem einfachsten Wege die Antriebe programmiere. Heißt ich nutze TOs und die ganzen "Vorteile" die einem unwissenden Inbetriebnehmer damit gestelltwerden. Ich programmiere die Antriebe nie mit Bits und Bytes schubsen und manuell sondern nutze stets die Motion Control Befehle zusammen mit Technologieobjekten (TO). Und in der Tat übertrage ich das Drehmoment aus den Antriebe über eine Telegrammverlängerung direkt als physikalische Größe [Nm] (LREAL). Genauso die Drehzahl. Vielleicht sind die Rohwerte ja auch im TO-DB enthalten und ich kann die manuell im Zeitpunkt,wenn ich die Messprobe nehmen will, abgreifen.

Es geht zum einen darum, möglichst wenig Zykluszeit zu erzeugen, also möglichst wenig Bearbeitung der Werte während der Laufzeit der Messung.

Dann sollte es Dir eigentlich möglich sein, ein Array mit 1000 Elementen in einem DB zu erzeugen und das während der Laufzeit zu füllen.

Auf jeden Fall, das unterschreibe ich und will ich auch versuchen. Ich habe gerade gesehen, weil ich bisher von 10 Spalten ausging, dass ich ein mehrdimensionales Array gar nicht mit mehr als 6 Spalten anlegen kann ^^ Würdest du für jede Messgröße pauschal ein (z. B.) Array mit 0..999 erstellen. Also z. B. 9 verschiedene Arrays, aber gleich lang oder sind mehrdimensionale Arrays speicherzugriffs-technisch irgendwie optimaler/schneller? Dann würd ich z. B. so wählen
Array 1 [0..999] of DINT (für Zeitstempel)
Array 2 [0..999, 0..999, 0..999, 0..999] of LREAL (für M_Ax1, n_Ax1, M_DMWAx1, n_DMWAx1) (also Drehmoment und Drehzahl aus Achse und zugehöriger Drehmomentmesswelle (DMW))
Array 3 [0..999, 0..999, 0..999, 0..999] of LREAL (für M_Ax2, n_Ax2, M_DMWAx2, n_DMWAx2) (also Drehmoment und Drehzahl aus Achse und zugehöriger Drehmomentmesswelle (DMW))

Messwerte bearbeiten und wegschreiben kann man dann ggf. im Anschluß der Messung. Wenn der Anwender dann 10 Sekunden warten muß, ist das egal. Aber die Messwerte sind schnell und genau erfaßt.

Das denke ich auch. Ich muss dann nur schauen, dass die Abtastrate und die Arraylänge stets passen, dass keine Messung den Rahmen sprengt. Ich würde tatsächlich nach einer Messung, wenn alle Messwerte in Arrays stecken, einen Taster im HMI anlegen a la "übertragung starten" und dann kann er meintwegen 5 min rödeln.

Im Extremfalle müßte man mit externen Datenloggern arbeiten, die auf die Meßwerterfassung spezialisiert sind. Aber bei 10s Meßdauer bei Dir glaube ich nicht, daß man so weit gehen muß.

Das hat mir ein befreundeter Ingenieur auch geraten, aber das musste ich schon verneinen. Weil Hochschule: Abschlussarbeit, darf kein Geld kosten und Zeit dafür keine. Hätte schon längst mit meiner Masterarbeit fertig sein sollen. Jetzt irgendwas langwierig zu beantragen und zu bestellen geht im öffentlich Dienst voll schief. >.<
Ich muss das mit meiner vorhandenen Technik und möglicherweise Freeware alles irgendwie selbst hinbekommen. Ich bin ehrlich und hatte mir von der Datenbank-Loggerei viel mehr versprochen. Hab jetzt soviele Tage verbracht mich darin einzuarbeiten, um jetzt festzustellen, doch kacke, nicht performant genug, um meine Sachen zu realisieren.

In einem Anwendungsbeispiel für TIA v16 bezüglich SQL-Logging hab ich gesehen, dass es da dann Bausteine gibt, die nicht über das HMI und VBScripte zur Datenbank kommunizieren. ALso tun sie dies direkt aus dem Programm heraus. Eine Anfrage bei SIEMENS lieferte keine Möglichkeit, dass sie mir das zu v15.1 downgraden. Sie sagten, das wäre nicht kompatibel. Kennt das jemand. Wäre das tendenziell performanter und könnte man damit wie ein Torpedo live Prozessdaten zu Hauf loggen ?

Danke für die Antwort JS

 

[rostiger Nagel]

Das WinCC Unified scheint für so etwas gut gerüstet zu sein,
da ist ein SQL-Lite Onboard und dieser soll große Arrays in 100ms
Takt weg speichern können. Das ganze aber erst unter V17.
So könntest du erst einmal die Vorverarbeitung auf Steuerungsseite
verringern.

 

[JSEngineering]

Kenn ich, Logging, soll schnell sein, viel aufzeichnen, aber nix kosten... hab ich alles hinter mir [emoji6]

Ich würde die Meßwerte nicht in einem mehrdimensionalen Array ablegen, sondern einen UDT machen, der alle zu erfassenden Daten enthält, also quasi eine Zeile Deiner Datenbank abbildet.
Und aus dem UDT dann ein Array machen.

Wie gesagt, intern sammeln, dass sollte bei Deiner Menge klappen.
Und dann am Ende in Ruhe wegschreiben.
Beim Wegschreiben kann man dann auch ggf. die Daten umwandeln, so dass sie z.B. dann mit SQL übereinstimmen.

 

[JSEngineering]

Zuviel Werbung?
-> Hier kostenlos registrieren

Gib mal hier, ob Dir das hilft:

https://www.sps-forum.de/simatic/97810-direkt-aus-steuerung-s7-1500er-sql-datenbank-schreiben-4.html


https://www.sps-forum.de/simatic/82160-s7-1200-1500-kommunikation-mit-sql-server-2.html

 

[ZottelMD]

Das WinCC Unified scheint für so etwas gut gerüstet zu sein,
da ist ein SQL-Lite Onboard und dieser soll große Arrays in 100ms
Takt weg speichern können. Das ganze aber erst unter V17.
So könntest du erst einmal die Vorverarbeitung auf Steuerungsseite
verringern.

Off Topic: cooles neues Layout im Forum ^^sieht alles weniger eckig aus und scheinbar findet man einige Sachen einfacher

On Topic: Nagel, sicherlich hast du recht mit WinCC Unified, aber wir haben hier für diese Anlage nur Winn RT Advanced mit 128 Tag Lizenz. Irgendwas neu kaufen ist nicht mehr drin. Und wenn ich jetzt die von dir genannten 100 ms nehme, ist das natürlich schon deutlich performanter als, das was ich bisher habe, aber inRrichtung 20 ms, 50 ms ist das immernoch nicht.
Beschleunigt man mit dem DUT Vollgas und erzeugt keine zusätzliche Last durch die beiden Servos (vgl. Abbildung vom Prüfstandaufbau), dann ist der Beschleunigungsvorgang in ca. 0.8 s von 0 auf maximal Drehzahl (950 rpm an der Hinterachse) vollzogen. Die Drehträgheiten sind also entsprechend gering. Natürlich sollte eine konstante Last, z. B. in Messmodus 2, dieses Vorgang etwas ausbremsen/verlängern, aber ich denke für solche transienten Vorgänge wären selbst 100 ms Samplezeit zu wenig, um mögliche Drehmomentmaxima zu erfassen.

 

[ZottelMD]

Kenn ich, Logging, soll schnell sein, viel aufzeichnen, aber nix kosten... hab ich alles hinter mir [emoji6]

Ich würde die Meßwerte nicht in einem mehrdimensionalen Array ablegen, sondern einen UDT machen, der alle zu erfassenden Daten enthält, also quasi eine Zeile Deiner Datenbank abbildet.
Und aus dem UDT dann ein Array machen.

Wie gesagt, intern sammeln, dass sollte bei Deiner Menge klappen.
Und dann am Ende in Ruhe wegschreiben.
Beim Wegschreiben kann man dann auch ggf. die Daten umwandeln, so dass sie z.B. dann mit SQL übereinstimmen.

Mit UDT kenn ich mich noch gar nicht aus das schau ich mir aber gleich mal an. Kann man da sonderlich viel falsch machen, in Richtung wie man die UDT deklariert? Gibt es da schnelle/effiziente/performante Wege vs langsame/schlechte Deklarationen?

 

[ZottelMD]

Zuviel Werbung?
-> Hier kostenlos registrieren

Gib mal hier, ob Dir das hilft:

https://www.sps-forum.de/simatic/97810-direkt-aus-steuerung-s7-1500er-sql-datenbank-schreiben-4.html


https://www.sps-forum.de/simatic/82160-s7-1200-1500-kommunikation-mit-sql-server-2.html

Schau ich mirgerade an.

Der erste Link geht schon einmal in die falsche Richtung. Dort wird genau das diskuttiert, was ich eingangs beschrieben habe, das TIA v16 Applikationsbeispiel. Direkt aus dem PLC Programm den SQL Server ansprechen. Das fällt bei mir theoretisch flach, weil der SIEMENS Support sagte, geht net mit v15.1. Ich kann das Applikationsbeispiel also nicht irgendwie nachbauen oder kopieren, scheinbar.

Der zweite Link geht in genau die gleiche Richtung. Ein User bietet das Applikationsbeispiel über sseine Website an, was mit v15.1 klappen soll. Also ist es vermutlich technologisch schon möglich. Allerdings budget Lösung und somit raus ^^

 

[Ralle]

Es würde auch gehen ohne das HMI zu bemühen.

Hier hatten wir das mal: #35

Wenn du Python und snap7 auf dem benutzten PC installieren kannst, kannst du die Daten evtl. auch direkt abholen.
Sollten es zu viele Daten auf einmal sein, dann kann man das ja auch hier am Ende machen.
Aber testen würde ich das schon mal, alle 50ms 10 Datenpunkte aus der SPS holen, sollte schon gehen.

 

[ZottelMD]

Mit UDT kenn ich mich noch gar nicht aus das schau ich mir aber gleich mal an. Kann man da sonderlich viel falsch machen, in Richtung wie man die UDT deklariert? Gibt es da schnelle/effiziente/performante Wege vs langsame/schlechte Deklarationen?

Die Frage streich ich, hab mir gerade youtube videos angeschaut. Ist nicht anderes als eine Struktur und das kenn ich schon und benutze ich schon. Gut find ich, dass es quasi als schnittstelle dient. Möchte ich eine EIgenschaft in der Struktur hinzufügen, fügt er es gleich für alle hinzu. das ist zum debuggen gut ^^ kann erstmal mit Zeitstempel + M_Ax1 anfangen, und wenn alles klappt, erweitere ich die UDT-Variable um die weiteren 7 (Spalten)Einträge

 

[ZottelMD]

Zuviel Werbung?
-> Hier kostenlos registrieren

Es würde auch gehen ohne das HMI zu bemühen.

Hier hatten wir das mal: #35

Wenn du Python und snap7 auf dem benutzten PC installieren kannst, kannst du die Daten evtl. auch direkt abholen.
Sollten es zu viele Daten auf einmal sein, dann kann man das ja auch hier am Ende machen.
Aber testen würde ich das schon mal, alle 50ms 10 Datenpunkte aus der SPS holen, sollte schon gehen.

Das ließt sich erst einmal super. Mit deinem Beispiel zeigst du ja schon einmal auf, wie schnell es gehen könnte.
Pro:
- mein Rechner, wo aktuell die MS SQL Datenbank installiert ist steht direkt neben der Prüfstandanlage
- wir müssen also erfasste Daten nicht irgendwo hin (Cloud, zentraler Server, was auch immer) schicken
Contra:
- Ich hab 0 Plan von Python etc. Das wollte ich mir nach dem Studium mal ein bisschen aneignen
- Ich kann das ohne Plan nicht mal eben umsetzen. Ich habe nur noch ca. maximal 4-5 Tage Zeit, dann müssen die 3 Messprogramme sauber laufen (da bleibt noch das Problem mit der nicht funktionierenden Lageregelung ( Link zum Lageregelungs-Fred )), und die Datenerfassung muss so umgesetzt sein, dass die Professoren das als gut empfinden. Dann habe ich nur noch ca 1 Monate Zeit, um die Arbeit zu schreiben und dazwischen Testmessungen zu machen und so zu sagen den Prüfstand zu Validieren. Anfang/Mitte Juli ist Verteidigung.

0 Chance, dass ich jetzt noch Python lerne und irgendwelche Netzwerke einrichte/optimiere

Ich denke ich muss dann eher irgendwie den Weg gehen von JS:

Daten zur Messzeit sammeln und nach der Messung zusammenhängend rausschaufeln.
"Raus" bedeutet dann entweder für alle 3 Messfahrten in eine MS SQL Datenbank, die ich bis jetzt ja nur funktionabel in Messung 1 einsetze und die für Messmode 2 und 3 nicht schnell genug ist (über VBScript im IPC).
Alternativ, könnte "Raus" auch bedeuten, ich mache es so wie im letzten Jahr testweise, dass ich die gesammelten Daten in ein Log auf der SPS speichere und über Web-Browser der PLC zugreife. Was mir daran nicht gefällt sind die vielen / gehäuften öffnen-, lesen-, schreiben-, schließen-Zugriffe des Flash-Speichers. SIEMENS gibt ihre Karten ja mit so Zyklenzahlen von 100 000 bis 500 000 an. Wenn man sagt man sammelt immer Daten in Clustergröße, also Vielfache von 256 Byte, damit Schreibvorgänge zügig gehen und eine Messfahrt fürht zum Beispiel zu 10 - 30 kByte an Daten, dann sind das schon 50 Schreibvorgänge allein für eine Messfahrt. Ist man fleißig und macht 100 Messungen am Tag, sind das schon 5000 Schreibvorgänge usw usf.

 

[ZottelMD]

@JSEngineering
p. s.: hab mich geirrt.
in meinem "physikalischen Schnittstellenbaustein" berechne ich das Drehmoment aus Achse 1 und 2 erst zu einer LREAL.

Heißt, durch die Telegrammverlängerung bekomme ich ein WORD, ..

.. was ich durch das Bezugsmoment und HEX#4000 umrechnen muss.

Insofern hast du auch da recht. Hier kann ich auch Array/Datengröße sparen, wenn ich direkt nur das Word übertrage und später, vor dem SQL-Export umrechne

Das gleiche gilt für die Drehmomentmesswellen. Da ich die ja mit 2 analogen Eingängen einlese, sind sie eigentlich INT

Auch hier spare ich massiv im vergleich zu LREAL.

 

[ZottelMD]

Schei... das Beitrag erstellen Beitrag-Erstellen macht ja jetzt richtig Spaß. Rucki zucki Bilder aus dem Clipboard einfügen BAM. Sieht alles sehr schick aus. Ein großes LOB an/für die Forum-Änderung

 

[Holzmichl]

Zuviel Werbung?
-> Hier kostenlos registrieren

Du könntest auch die beiden folgenden Beispiele vom Big-S direkt ausprobieren oder zumindest anschauen:

S7 1200/1500 ftp-Client Kommunikation

SIOS

support.industry.siemens.com

S7 300/1200/1500 TCP-Fileserver

SIOS

support.industry.siemens.com

Selbst habe ich damit noch nicht gearbeitet, könnte mir aber vorstellen, dass das für Dich passen könnte.

 

[ZottelMD]

Du könntest auch die beiden folgenden Beispiele vom Big-S direkt ausprobieren oder zumindest anschauen:

S7 1200/1500 ftp-Client Kommunikation

SIOS

support.industry.siemens.com

S7 300/1200/1500 TCP-Fileserver

SIOS

support.industry.siemens.com

Selbst habe ich damit noch nicht gearbeitet, könnte mir aber vorstellen, dass das für Dich passen könnte.

Das klingt auch interessant. Ich schmöker gerade den ersten Link durch und versuche irgendwie Angaben über Schnelligkeit herauszufinden.
Rein Datengrößen-technisch müsste das passen:

Rein Zeit-technisch stell ich mir das schwieirg vor: Verbindung aufbauen, Senden/Empfang, Acknowledge, Verbindung schließen. Das wird doch hundert pro den normalen Zyklus ausbremsen oder ?

Aus der zweiten Abbildung suggeriere ich, dass es im Bereich von 25 ms liegen kann ^^

 

[Matze001]

Wie wäre ein effizientes Speicherungskonzept, was die normale Profinet-Kommunikation zwischen PLC und S120 so wenig wie möglich beeinflusst? Wie realisiert ihr solche LoggingAufgaben?

Da Du eine 1516 hast, hast Du ja zwei getrennte Netzwerkschnittstellen. Somit könntest Du PN und Logging physikalisch trennen.
(Wobei das meiner Meinung nach bei Deiner Datenmenge nicht relevant ist)

Wie realisiert ihr solche LoggingAufgaben?

Ich habe soetwas schon einmal wie folgt gelöst:

S7 hat einen TCP-Server (oder Client).
Die Daten die zu Übermitteln sind werden in einen FIFO of UDT geschrieben
Wenn die Verbindung steht werden die Daten aus dem FIFO gezogen und versendet.

Die Gegenseite kann nun ein Python oder C#-Programm sein, dass die Daten entgegen nimmt und
(nach ggf. nötiger Wandlung) in die Datenbank schreibt).

Ich habe mit der Konstellation S7 - TCP-Server - C# - TCP-Client die Datenübertragung von 512 Byte alle 5ms hinbekommen.
Die SPS-Zykluszeit lag dabei bei 2-4ms (Safety + TO). Aber mit dem FIFO geht eh nichts verloren (wenn er groß genug ist).

Grüße

Marcel

 

[ZottelMD]

Zuviel Werbung?
-> Hier kostenlos registrieren

Da Du eine 1516 hast, hast Du ja zwei getrennte Netzwerkschnittstellen. Somit könntest Du PN und Logging physikalisch trennen.
(Wobei das meiner Meinung nach bei Deiner Datenmenge nicht relevant ist)

Ich habe soetwas schon einmal wie folgt gelöst:

S7 hat einen TCP-Server (oder Client).
Die Daten die zu Übermitteln sind werden in einen FIFO of UDT geschrieben
Wenn die Verbindung steht werden die Daten aus dem FIFO gezogen und versendet.

Die Gegenseite kann nun ein Python oder C#-Programm sein, dass die Daten entgegen nimmt und
(nach ggf. nötiger Wandlung) in die Datenbank schreibt).

Ich habe mit der Konstellation S7 - TCP-Server - C# - TCP-Client die Datenübertragung von 512 Byte alle 5ms hinbekommen.
Die SPS-Zykluszeit lag dabei bei 2-4ms (Safety + TO). Aber mit dem FIFO geht eh nichts verloren (wenn er groß genug ist).

Grüße

Marcel

Huhu, das klingt auch super und greift quasi den Gedanken von Holzmichl auf. Ich nehme das mal mit und behalte das im Hinterkopf, wenn ich gleichzeitig aber auch absolut kein Plan hätte, wie ich es nun konkret angehe.
Aktuell baute ich mir mein UDT so (man beachte die Kommentare):

Komme also pro Zeile in einer Tabelle auf mindestens 32 Byte, wenn ich jeden UDT-EIntrag als Spalteneintrag in einer Datenbank/CSV/whatever anlegen will. Ein FIFO Puffer bräuchte ich theoretisch auch nicht großartig nachprogrammieren. Die LGF-Bibliothek bringt einen mit:

Wenn ich mich richtig erinnere, steht in der Doku des ersten Links von Holzmichl
https://support.industry.siemens.co...kommunikation-mit-s7-1200-1500?dti=0&lc=de-DE ,
dass die FileZilla benutzen:

Denkst du ich muss jetzt großartig Einarbeitung betreiben (C#, Python, etc.), oder dass die gleichen Schlagzahlen auch mit der Variante, wie in der verlinkten Doku zu erreichen sind. Die Zeit ist bei mir jetzt ein großes, kritisches Ding, wie ich irgendwo oben erwähnt habe.

p.s. worauf ich vergessen hab zu reagieren: mit der Schnittstellen Trennung hast du recht. Ich habe die Anlage auch so verdrahtet, dass die Antriebe (in Form der CU) und die PLC mit ihrer PN1 Schnittstelle in einem eigenen Subnetz sind. Den IPC habe ich mit der PLC an der anderen 2. Schnitttelle angeschlossen und ein andere Subnetz vergeben. Das heißt die, wichtige Kommunikation zwischen PLC und CU ist schon immer gekapselt und die IPC/VBS Kommunikation lag nie mit auf dem selben PN

 

[JSEngineering]

Warum willst Du eigentlich immer jeden Datensatz einzeln während der Erfassung wegschreiben?
Gerade wenn bei Dir die Zeit für Deine Arbeit wichtig ist, erledige doch die Dinge, die Du einfach erledigen kannst, sofort:
Du erfaßt alle Datensätze in einem großen DB in der SPS.
Wenn dann am Ende die Übertragung der Daten in ein externes System fehlt, wird Dir keiner den Kopf abreißen, Du hast aber eine funktionierende Meßdatenerfassung.
Wenn Du dann am Ende noch ein paar Stunden Zeit hast, kannst Du versuchen, diesen DB in einem Rutsch als Datei auf einem FTP-Server abzulegen. Das ist dann nur noch eine Fleißaufgabe.

 

[ZottelMD]

Warum willst Du eigentlich immer jeden Datensatz einzeln während der Erfassung wegschreiben?
Gerade wenn bei Dir die Zeit für Deine Arbeit wichtig ist, erledige doch die Dinge, die Du einfach erledigen kannst, sofort:
Du erfaßt alle Datensätze in einem großen DB in der SPS.
Wenn dann am Ende die Übertragung der Daten in ein externes System fehlt, wird Dir keiner den Kopf abreißen, Du hast aber eine funktionierende Meßdatenerfassung.
Wenn Du dann am Ende noch ein paar Stunden Zeit hast, kannst Du versuchen, diesen DB in einem Rutsch als Datei auf einem FTP-Server abzulegen. Das ist dann nur noch eine Fleißaufgabe.

Huhu genau, das probier ich gerade. Ich möchte dir anderen Vorschläge nur nicht abschmettern. Stellt sich z. B. heraus, dass ich das auch "ruck zuck" mit meinem nicht vorhandenen Wissen erledigen könnte, würd ich das nebenläufig probieren. Aber ansonsten hast du vollkommen recht und ich bin gerade dabei, das so zu machen, wie du mir eingangs geraten hast. Alles sammeln und dann nach der Messung mit einem Knopfdruck alles raus.

Kurze Frage dazu:

Ich habe teste gerade und fange erst einmal mit einem Array of UDT mit 100 Zeilen an, bzw 101 ^^ Dann will ich gleich mit geringen Samplezeiten anfangen, also z. B. jede Sekunde mal die Przesswerte in mwArray[0], mwArray[1], usw. schreiben. "measRow" ist mein zuvor gezeigter UDT.

Will ich gewährleisten, dass in Messmodus 2 und Messmodus 3 die Messfahrten auch komplett erfasst werden, muss es ja immer ein Zusammenspiel von Messdauer/Aufzeichnungsdauer und Samplezeit sein. Man stelle sich vo ich taste Prozesswerte mit 2 ms Zykluszeit ab, dann wäre ein Array ruck zuck voll. Gibts da irgendwie eine Faustregel? Kann man sagen bei welchen Arraylängen sich die PLC noch wohlfühlt und nicht ausgebremst wird und bei welchen nicht? Ich stell mir das aus PLC Sicht schwierig vor: Es muss ja immer ein rieeeesen Array geladen werden. Auf wie viel Zeilen könnte ich mein Array schmerzfrei hochschrauben? Je mehr, desto besser kommts mir ja zu gute, wenn nicht die PLC-Zykluszeit irgendwie rumspackt ^^
p. s.:
zweite Frage: kann man irgendwie mit einer schicken kurzen Zeile dafür sorgen, dass z. B. mwArray[0], welcher ja 9 Elemente in sich verbirgt, mit einmal initialisiert wird? Ich denke da an z. B. irgendwie sowas " mwArray[0] := (0,0,0,0,0,0,0,0,0); Weil ist eine Messung getan muss ich das gesamte Array, was nicht immer voll sein wird ja löschen/reinitialisieren, damit vor der nächsten Messung wieder alles 0 drin stehen. So könnte ich dann bei dem nachträglichen Wegspeichern der Daten, z. B. wieder durch ein VBScript auf die erste 0 Zeile scannen, damit er nicht jedesmal das Gesamte Array (z. B. 999 Zeilen) in die Datenbank pflastert, wenn die untere Hälfte alles 0 wäre
Ziehe die Frage zurück. Habe kurz gegoogled und wahrscheinlich muss man einfach in einer Schleife 0en drüberbügeln: