TIA Schneller Datenaustausch PC<->SPS

S

statix

Level-2
Beiträge
117
Reaktionspunkte
7
Zuviel Werbung?
-> Hier kostenlos registrieren
Tach zusammen,

ich muss in bälde mit einem PC-Messsystem Daten austauschen und das zügig.

Als ersten Ansatz würde ich OPC UA wählen, wobei Siemens selbst von einer minimalen Kopplungsgeschwindigkeit von 100ms ausgeht.
Das könnte/sollte ausreichend sein, aber es ist unklar ob das tatsächlich eingehalten werden kann.
Denn es tummeln sich noch weitere Daten auf dem OPC.
Diese sind zwar nicht so zeitkritisch, aber ich habe kaum Erfahrungen wie leistungsfähig der OPC-Server ist.

Ich suche also nach Plan B oder gleich nach einem besseren Plan A.

Perfekt wäre eine Profinet Karte für den PC, dann könnten wir eine I-Device Kopplung machen.

Hat jemand Erfahrung in dem Bereich?
 
Wie schnell meinst Du mit "schnell"?
Wieviele Daten müssen in welcher Zeit übertragen werden?
Könnte die PLC die Daten auch eine Weile zwischenpuffern?

Harald
 
Unter "schnell" verstehe ich möglichst unter CPU-Zykluszeit, also ~10ms.

Datenmenge: 21 Realwerte die an einem Positionier-Antrieb übergeben werden.
Die 21 Antriebe sollen also den auf dem PC gemessenen Positionen folgen und das natürlich möglichst unverzögert.

Die Wahl der PC-Komponenten steht mir nicht frei, daher die Frage: was braucht es für die Soft SPS?
Nur die Software oder auch Hardware?
 
Grundsätzlich die Software, Hardware währe gut.
Damit hast du erst einmal eine Zykluszeit die sehr, sehr klein ist.
Zusätzlich könntest du tatsächlich die Daten zyklisch übergeben.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hab gerade parallel gegoogelt.
Verstehe ich das richtig? Die PC-Software würde dann innerhalb der Soft-SPS abgewickelt?
Falls ja, dann ... oh-oh.
Glaube nicht, dass die Firma die das Messystem bereit stellt dazu bereit ist oder das das überhaupt funktioniert.
 
Hier: #35

hatte ich mal "gemessen", wie schnell ein paar Daten aus einer 1517 mit ca. 13ms Zykluszeit von meinem Laptop gelesen und in eine Datenbank geschrieben werden.
Lief über Ethernet mit Snap7 und Python. Das kannst du selbst testen, wenn du eine 1500-er SPS hast. Ist die SPS schneller, legt auch die Übertragung noch etwas zu.

Schnellste Variante wird der Vorschlag von RN sein.
 
Ich habe zum Spaß mal 512 Byte einfach per TCP verschickt und empfangen, und komme bei 2ms SPS-Zykluszeit auf 4ms für 512Byte lesen und schreiben.
Vermutlich wird aber die Datenmenge nicht die größte Sorge bereiten, solange sie in ein Telegramm passt.


Grüße

Marcel
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Statix

eine Profinet Interface Karte wäre auch noch eine Möglichkeit z.b von Siemens Cp16xx oder von Hilscher. Hier solltest du doch unter 5ms kommen die Menge an Daten dann wohl recht sicher. Hier solltest du Theoretisch sogar auf 1 ms runter kommen können.

Gruß Tia
 
Und es gibt noch einen Profinet-Master-Stack für .Net.

Was mich noch stutzig gemacht hat, warum will ich Variablen aus einer SPS schneller als die SPS Zykluszeit lesen oder schreiben.
Das bringt doch gar nichts.

Grüße

Marcel
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Also das Messsystem erkennt auf vorbeilaufenden bahnförmigen Materialien bis zu 21 "Gassen" im Material.
An diesen Stellen sollen wiederum bis zu 21 Messer die Gassen der Länge nach aufschneiden.
Die Messer sind an je einem Antrieb gekoppelt, den ich bewegen muss.

Driften die Gassen ein wenig hin und her, müssen die Messer da nahtlos hinter fahren um die Gassen nicht zu verlassen.
Der Abstand des Messystems zu den Messern ist sehr gering und die Bahngeschwinidigkeit nicht unerheblich.
Daher darf die Zeit zwischen Messen und Stellen nicht zu groß werden.

Ist die Transferzeit geringer als die Zykluszeit der CPU, fällt sie als Problem komplett heraus, da das ganze System eh nicht schneller laufen kann als meine CPU.
Ich denke es wird auch mit größeren Zeiten noch funktionieren, aber wenn ich schon im Vorfeld Probleme ausschließen kann durch die Wahl einer besseren Kopplungsart, dann tue ich das.

Das Messsystem ist zugeliefert (nicht gekauft, das tut der Kunde) und da kann ich eben nicht bestimmen wie es laufen soll, nur Vorschläge machen und bitten.
 
Naja ... die Frage bleibt immer noch was für Daten du bekommst und wie schnell du sie bekommst ...
Wie sieht es denn mit deinen Verstellantrieben aus ? Können die denn ggf. geänderte Positionsdaten auch schnell genug aufnehmen ? Manche Servoregler sind da noch "ein bisschen" träge was das anbelangt ...

Gruß
Larry
 
Die Aufgabe ist natürlich den ganzen Weg von der Messung bis zur Stellung so schnell wie möglich zu bekommen.
Wie ich das bei der CPU und den Antrieben schaffe weiß ich schon recht gut, nur bei der Kopplung nicht.

Wie bereits gesagt, 21 Real oder DINT Werte werden es wohl sein, die zeitkritisch sind.
Darüber hinaus sind noch Daten für die allgemeine Kommunikation nötig, die ich aber noch nicht benennen kann.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wie stellt dieses "Messsystem" üblicherweisen die Daten zur Verfügung? Die werden sowas doch nicht zum ersten mal bauen?

Wenn Du denen nen PNIO-PC-Karte einbaust, hilft das erstmal auch nicht viel, wenn deren Softare nicht mit dieser Karte reden kann...

Also ich würd den Hersteller von dem Messsystem mal anrufen und Beratschlagen.

Die Aufgabe ist natürlich den ganzen Weg von der Messung bis zur Stellung so schnell wie möglich zu bekommen.
Zum Vergrößern anklicken....

Solche Aussagen helfen wenig... man muss schauen, welche Reaktionszeit physikalisch notwendig ist und das dann umsetzen.

Und wenn das Messystem z.B. die Position nur alle 100ms erfassen kann, dann nützt es auch nix, das alle 2ms zur SPS zu übertragen :rolleyes:

Gruß.
 
Ich stehe in Kontakt zu der Firma.
Deren Idee ist entweder OPC UA oder je eine analoge Verbindung (4..20mA) pro Wert.
Ich finde das etwas vorsintflutlich und habe mich nun auf die Suche nach Alternativen gemacht.

Das Messystem kann schneller als 10 Hz, aber der OPC Server eben nicht.

man muss schauen, welche Reaktionszeit physikalisch notwendig ist und das dann umsetzen.
Zum Vergrößern anklicken....
Ja, das ist richtig.
Tatsächlich werde ich wohl am Ende die jeweils anliegende Bahngeschwindigkeit mit einrechnen, damit das Messer nicht zu schnell ist.
Sonst hat Das Messer einen Schlenker ausgeglichen, der noch gar nicht angekommen ist.

Eine künstliche Totzeit einführen ist leicht. Ein grundsätzlich zu langsames System beschleunigen dagegen schwer.
Daher will ich zunächst Zeit sparen wo es geht, ohne dazu große Investitionen zu tätigen.
Wenn ich das TCP-Protokoll bei denen platzieren kann, bin ich doch schon einen großen Schritt weiter.
2ms sind super!
 
statix schrieb:
Deren Idee ist entweder OPC UA oder je eine analoge Verbindung (4..20mA) pro Wert.
Zum Vergrößern anklicken....

Bei Analog hast dann aber auch noch die Wandlungszeiten der Analogen Ausgangs bzw. Eingangskarte, da brauchts dann auf beiden Seiten wenigstens die HighSpeed-Karten.

Ansonsten ist Analog mit nichten "vorsintflutlich"... Bei wenigen Signalen ist das noch immer das beste Mittel der Wahl, weil einfach und schnell umgesetzt... Mit Busprotokollen zwischen zwei verschiedenen Parteien steckt man schnell ganz viel Arbeitszeit rein.... aber naja...

hört sich irgendwie nach ner "fliegenden Säge" an?

Gruß.
 
Zurück
Oben