TIA Schnell Daten verschicken

  • Ersteller Ersteller Gelöschtes Mitglied 103809
  • Erstellt am Erstellt am
Zuviel Werbung?
-> Hier kostenlos registrieren
Leider sind die Links auf diese Siemens Seite tot.
Ich fragte für ein Paar Wochen her ob sie irgendwann wieder funktionieren werden. Antwort von Siemens, sie arbeiten dran.

Für 25 ms, und wenn es deterministich sein muss, vielleicht Profinet IO ? Es gibt Profinet stacks für PCs.
 
4 MByte/s für die Visu direkt von der CPU?
Oder sind da noch andere Geräte (Kamera, Scanner, Messtechnik, ...) dabei?
Bei der Bandbreite macht es schon mal Sinn sich Gedanken über Topologie und Netzwerkmanagment zu machen.

Ja in dem Netzwerk sind zu der Visu noch ein Messwerterfassungssystem was über die Schnittstellen mehrerer SPSen nochmal ordentlich Daten absaugt.

@Harald
Danke für den Link, leider haben die wohl die Webapplication gesperrt oder steht nicht mehr zur Verfügung. :(

Es geht ja bei uns im Werk nicht nur um diese eine Anwenung aktuell, die "flott" Daten liefern soll. Ich hab in den letzten Jahren immer wieder Projekte bekommen, wo eine neue Messeinrichtung an eine Anlage kommt, die entweder Datenpakete unter 100ms liefern soll oder Daten unter 100ms brauch. Ob das nun Sinn mach oder nicht.

Ich nehme daher für mich mit:
- denzentrale also anlagenahe Kommunikationspartner (nicht irgendwo in der "Werkscloud")
- bessere logische Trennung der Netze in Aufgabenbereiche: SPS-XYZ Datenschleuder PC Netz, Visu Netz, Messerfassungsnetz, Anlagenbus
- Der IT auf die Füsse treten, dass wir zukünftig QoS haben, wo wir bestimmte Kommunikationswege bevorzugen können
- Eventuell TCP/IP-Verbindungen, gerade zwischen SPSen ändern auf UDP - mir fallen da einige Verbindungen ein auf unserer Seite, wo es einfach egal ist ob mal ein Telegramm nicht ankommt oder nicht
- Ich werde mich mit der Forschung nochmal intensiver auseinandersetzen, ob gerade für diese Anwendungen überhaupt Zykluszeiten von 25 ms notwendig sind (ich kanns mir eigentlich gar nicht vorstellen). Wir haben uns jetzt für den Anfang erstmal auf 100ms geeinigt.

Für diejenigen die es interessiert, worum es in dem Projekt geht. Ich arbeite im Stahlwerk und nachdem das Eisen aus dem Hochofen gekommen ist, wird erst eine Bramme und dann zu einem Stahl-Coil aufgewickelt. Dieses Coil unterläuft dann unterschiedliche Prozesse. Aber vor jedem Prozess muss das Coiil abgewickelt werden und wieder plan gemacht werden. Dazu werden an den Anlagen Richtmaschinen eingesetzt. Es gibt da verschiedene Ausführungen aber prinzipiell hat man immer 3 Rollen unten und 2 verstellbare oben, die in das Band drücken, die sogenannte Tauchtiefe.

Das Problem ist dabei, dass dieser Richtprozess aktuell vom Bediener durchgeführt wird. Er fährt das Band mehr oder weniger mehrmals vor und zurück durch die Richtmaschine und verstellt dabei die Tauchtiefe, bis das Band plan rauskommt. Da im Werk das Produktspektrum so unterschiedlich ist, lässt sich leider keine allgemeine Aussage treffen, wie die Richtrollen bei Material XY angestellt werden müssen. Es gab vorher schon Versuche über eine selbstlernde Automatik, die pro Produkt die Werte wegspeichert und dann wenn das gleiche wiederkommt als Vorgabe lädt, aber es funktioniert nicht. Das Forschungsprojekt ist jetzt, das eine optische Bandanfangserkennung scannen soll, ob das Band plan ist und dazu werden die Antriebsdaten an die Forschung geschickt, die da später ein System draus basteln will anhand der Antriebsdaten und welches Ergebnis erhalte ich am Bandanfang.

Das Ziel wird sein, dass der Bandanfang nur noch einmal durch die Richtmaschine muss und sofort Plan rauskommt unabhängig davon, ob es der 13mm dicke ultraharte Chromstahl ist oder die 3 mm weiche Papierstahl.
 
Leider sind die Links auf diese Siemens Seite tot.
Ich fragte für ein Paar Wochen her ob sie irgendwann wieder funktionieren werden. Antwort von Siemens, sie arbeiten dran.

Für 25 ms, und wenn es deterministich sein muss, vielleicht Profinet IO ? Es gibt Profinet stacks für PCs.

Uhh, guter Hinweis - nehme ich auch noch mit!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Vielleicht hätte die Diagnose aber auch gemeldet, dass noch 5 weitere unbedingt getauscht werden müssen :rolleyes:

Vielleicht, vielleicht auch nicht. Bei uns werden einmal im Jahr Inspektionen gemacht ( was bei den großen Abfüllern / Palettierern auch nötig ist, die laufen
6 Tage / 24h ), dort werden solche Diagnosen vom erfahrenen Mechaniker zuverlässig gestellt ( natürlich vor der Inspektion, damit dann gleich reagiert werden kann ).

Kostet nicht viel, 1 Mann, Anreise, je nach Größe 1-2 Tage vor Ort und alles inspizieren... Das einmal im Jahr.

Aber gut, vielleicht haben diese Systeme irgendwo ihre Berechtigung. Bei uns sehe ich dies nicht.
 
Vielleicht, vielleicht auch nicht. Bei uns werden einmal im Jahr Inspektionen gemacht ( was bei den großen Abfüllern / Palettierern auch nötig ist, die laufen
6 Tage / 24h ), dort werden solche Diagnosen vom erfahrenen Mechaniker zuverlässig gestellt ( natürlich vor der Inspektion, damit dann gleich reagiert werden kann ).

Kostet nicht viel, 1 Mann, Anreise, je nach Größe 1-2 Tage vor Ort und alles inspizieren... Das einmal im Jahr.

Aber gut, vielleicht haben diese Systeme irgendwo ihre Berechtigung. Bei uns sehe ich dies nicht.

Das Ziel ist, den erfahrenen (hochbezahlten) Mechaniker einzusparen...

So wie an der Tanke auch niemand mehr Wechselgeld rausgeben können muss...

Schöne neue Welt, wohin das führt, werden wir sehen :rolleyes:
 
@Clyde82.

Wie du es beschreibst, ist es ein Prozessinterne Datenerfassung und Bearbeitung.
Ich wurde es nicht mit das übergeordnete Firmennetzwerk mischen.

Über das übergeordnete Firmennetzwerk kann das Resultat von die Datenbearbeitung verschickt werden.
Und in die andere Richtung kommt es eventuell Rezepte, Produktionsanforderungen usw.
Nichts dass 25ms deterministisch sein muss.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das Ziel ist, den erfahrenen (hochbezahlten) Mann einzusparen

Wer spart denn da?

-Der Kunde muss erst mal tief in die Tasche greifen und ggf. auch irgendwelche Gebühren bezahlen ( Cloud, Lizenzen... )
-Dann müssen alle Beteiligten hoffen, das das installierte System funktioniert ( und dies auch 20 Jahre )
-Dann müss das System ggf. jährlich oder in noch kürzeren Intervallen hochgerüstet werden da neue Funktionen, bessere Ergebnisse => Kosten


Und dann kommt irgendwann der Punkt, wo ein Lager festsitzt weil 2 Jahre nichts getauscht weil System sagt alles gut, Maschine steht.
Was wird der Kunde dann sagen? Ich habe euch 100.000 € bezahlt für ein System das nichts bringt, wer kommt für den Ausfall auf?

Lass dem gut bezahlten Mechaniker seine Daseinsberechtigung, ihm traue ich mehr als jedem System. Außerdem muss er so oder so eine
Vorabinspektion machen da es auch viele Verschleißteile gibt die man nur findet, wenn man sie begutachtet, mit Hand und Auge.....

Oder soll man ein PM System an jedem Kleinartikel montieren.
 
@Clyde

Hol dir am besten den Antriebshersteller mit ins Boot.
Es gibt vielleicht aussagekräftigere Reglerparameter als den Motorstrom.
Zudem kann man Umrichter auch direkt ohne Umweg über die SPS auslesen.
 
@Clyde

Hol dir am besten den Antriebshersteller mit ins Boot.
Es gibt vielleicht aussagekräftigere Reglerparameter als den Motorstrom.
Zudem kann man Umrichter auch direkt ohne Umweg über die SPS auslesen.

Das Problem ist eher, dass selbst die Anlagenhersteller das mit der Biege bzw. dem Richten nicht richtig hinbekommen - zumindest nicht für das Produktspektrum.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Gerade mal geschaut "Simatic Softnet PN IO" müsste das richtige sein, um einen PC als profinet Device bereitzustellen, den ich über die SPS dann einbinden kann, richtig? Wie läuft das dann auf der PC seite, wie bekomme ich dort die Daten dann aus dem Device raus in die Software der Forschungsabteilung?
 
Das Problem ist eher, dass selbst die Anlagenhersteller das mit der Biege bzw. dem Richten nicht richtig hinbekommen - zumindest nicht für das Produktspektrum.

Ich meinte ja auch den Antriebshersteller und nicht den Anlagenhersteller :-)

Es ist eigentlich nix aussergewöhnliches, dass beim Betrieber oft mehr Prozess-KnowHow ist als beim Hersteller.
Viele unserer Anlagen haben nix mehr mit der Orginalanlage gemeinsam.
 
Gerade mal geschaut "Simatic Softnet PN IO" müsste das richtige sein, um einen PC als profinet Device bereitzustellen, den ich über die SPS dann einbinden kann, richtig? Wie läuft das dann auf der PC seite, wie bekomme ich dort die Daten dann aus dem Device raus in die Software der Forschungsabteilung?
Das Standard-Antwort wäre dass die Software der Forschungsabteilung muss OPC DA Client sein und Simatic Net die OPC DA Server. Nur .. ich bin nicht 100% dass OPC DA mit 25 ms aktualisiert werden kann. Da habe ich nicht genug Erfahrung.
Alternativ wäre die Siemens spezfikke Schnittstelle SAPI-S7 zu verwenden. SAPI S7 sollte weniger Overhead haben als OPC. Aber SAPI S7 wurde seit vielen Jahren nicht mehr aktualisiert.

Noch eine Alternativ wäre Softings Profinet Stack für Windows:
https://industrial.softing.com/uplo.../PROFINETDeviceWindows_D_EN_160501_300_01.pdf
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich hab das mal bei mir testweise laufen lassen:

SPS 1517-F3 Zykuszeit auf Minimum 10 ms eingestellt, das heißt, die Zykluszeit ist nie kleiner als 10ms. Wenn ich recht erinnere lief die SPS im Schnitt mit 10-15 ms Zykluszeit.

Auf meinem Laptop Python 2.7 mit der Library Snap7 für Phyton und SQLite3 für Phyton.
Auf der SPS lese ich jeden Zyklus die Time mit Time_TCK.
Über Phyton lasse ich in einer Schleife ebenfalls freilaufend 10000 mal 4 Werte abholen, inklusive eines kurzen Strings.

Was ich sehen kann:

Pro Sekunde werden etwa 280 Mal die 4 Daten eingelesen.
Der Timerwert ist 3-5 Mal gleich.
Dann wird er um ca. 15ms größer.

280 Werte in 1000 ms macht ca. 3,6 ms.

D.h. für mich, der Laptop könnte alle 4 ms neue Daten holen und in einer Datanbank ablegen.
Die SPS liefert bei mir jede Zykluszeit (10-15ms) neue Daten, der PC bekommt also 3-5 Mal die selben Werte, da die Zykluszeit der SPS hier langsamer als der Zyklus in Phyton ist.
Da könnte man jetzt noch viel testen --> mehr Daten, kürzere SPS-Zykluszeit.

Kurzer Datenauszug:

1449144811:12:48620060.75710+620060710
1450144911:12:48620060.75710+620060710
1451145011:12:48620060.75710+620060710
1452145111:12:48620060.75710+620060710
1453145211:12:48620060.75725+620060725
1454145311:12:48620060.75725+620060725
1455145411:12:48620060.75725+620060725
1456145511:12:48620060.75739+620060739
1457145611:12:48620060.75739+620060739
1458145711:12:48620060.75739+620060739
1459145811:12:48620060.75739+620060739
1460145911:12:48620060.75739+620060739
1461146011:12:48620060.75755+620060755
1462146111:12:48620060.75755+620060755
1463146211:12:48620060.75755+620060755
1464146311:12:48620060.75755+620060755
 
Gerade mal geschaut "Simatic Softnet PN IO" müsste das richtige sein, um einen PC als profinet Device bereitzustellen, den ich über die SPS dann einbinden kann, richtig? Wie läuft das dann auf der PC seite, wie bekomme ich dort die Daten dann aus dem Device raus in die Software der Forschungsabteilung?

Besteht nicht die Möglichkeit einen IPC mit Soft-SPS als Datensammler einzusetzen?
Der könnte die Daten dann auf der eigenen Festplatte als zb. CSV Datei Zwischenspeichern.
Später könntest du dann die Datei Zeitunkritisch versenden.
 
Ich glaube dass die SPS weniger das Problem mit den 100 Byte/25ms haben wird als dein Netzwerk Vorort.
Dafür muss die nötige Struktur geschaffen sein und gegeben sein dass das Netzwerk auch unter höherer Last nicht gleich eine zu hohe Latenzzeit bekommt.

Du arbeitest mit TSEND_C usw. damit habe ich im Moment noch weniger Erfahrung als mit dem normalen TSEND.
Du kannst theoretisch mit deiner Applikation am PC auch ein eigenes Telegramm als Quittierung senden, somit könntest du theoretisch eine Statistik aufstellen ob auch alle Telegramme richtig angekommen sind.

Mich würde interessieren wie du es auf deiner Seite am PC bewerkstelligst die Daten zu empfangen und abzuarbeiten?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hey,

@rostiger Nagel
Ich schlag das mal vor mit dem IPC bzw. wir haben ja genug Pause zwischen den Produkten, um einen Ringspeicher in der SPS zu leeren. Ich hab das Telegramm gerade fertig gemacht - es sind 74 Byte.

@Rabi
Das weiß ich nicht genau, das sitzt halt ein Herr Doktor mit seiner virtuellen Linux-Maschine und einem ANSI-C Programm (soweit ich weiß).
Hab gerade nochmal mit dem Instandhalter telefoniert, wir haben Montag ein Brainstorming mit der IT, wie wir unser Netz optimieren können um hohe Latenzen zukünftig zu vermeiden.
 
Zuletzt bearbeitet von einem Moderator:
@Clyde82:
Wenn du über TSEND_C bzw. TSEND (soweit ich weiß macht TSEND_C gleichzeitig die Verbindung auf (TCON)) - bei TSEND brauchst du noch separat ein TCON bzw. TDCON.

Dann kommt es eben darauf an ob der "Herr Doktor" die aktive Verbindung anstößt oder die SPS den aktiven Teil übernimmt.
In beiden Fällen eigentlich egal weil die SPS dann, sobald die Verbindung eingerichtet ist, eigentlich zyklisch Telegramme schicken kann.

Wenn das dann z.B.: über ISO-on-TCP (RFC1006) passiert, hast du die Möglichkeit ein Telegramm von der SPS zu schicken dass 100 Byte groß bzw. erweitern könntest auf 106 Byte damit du auch ein Date_and_Time mitschicken kannst bzw. einfach ein DINT damit du die aktuelle Systemzeit oder auch lokale Zeit der SPS ausliest und im Telegramm als Zeitstempel in Millisekunden mitschicken kannst.
In diesen Fall würde, laut deiner vorgegebenen Zykluszeit (sagen wir mal ~4ms) die Daten ganz einfach rausgehen.
Es könnte dann die Gegenseite mit einer "logischen Quittierung", sozusagen einem leeren Telegramm darauf antworten und du wärst dir somit sicher ob das Paket angekommen ist.
Diese Information erhältst du nämlich nicht von einem TSEND_C oder TSEND, damit weißt du nur dass die Daten abgeschickt wurden.

Somit stellt sich für mich noch die Frage ob du die Daten innerhalb der 25ms brauchst und auch auswerten bzw. darauf reagierten musst oder ob du sie nur für ein Logging bzw. für eine Aufzeichnung benötigst damit du dann ggf. mit der Maschine auf veränderte Daten reagieren kannst.
 
Besteht nicht die Möglichkeit einen IPC mit Soft-SPS als Datensammler einzusetzen?

Ich würde auch in etwa diesen Weg gehen - nein eigentlich würde ich das in der SPS schon vorauswerten (z.B. für einen Zeitraum "x") und dessen Ergebnis dann weitergeben. hier kommt es dann auch gar nicht mehr auf die Zeitgenauigkeit an.
Ich habe etwas Ähnliches schon mal für pneumatisch Zylinderbewegungen gemacht. Die SPS hat die Dauer einer Bewegung (für jede Bewegung) gemessen. Wenn dir der Wert wegläuft (also größer wird) dann tut er es über hunderte oder tausende von Bewegungen. Im Grunde habe ich einen Stunden-Mittelwert weggeschrieben - hier lässt sich dann auch viel einfacher eine Gradienten-Steigung erkennen ...

Gruß
Larry
 
Zurück
Oben