TIA CPU 1515SP Open Controller mit s7.NET oder ODK

bhmth

Level-1
Beiträge
77
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
CPU 1515SP Open Controller mit s7.NET/sharp7 oder ODK

Hallo zusammen,

ich habe mal einen Frage zu s7.NET in Verbindung mit einem CPU 1515SP Open Controller.

Ich möchte einen Druckeransteuerung in der Windows Ebene realisieren mit C# oder C++,
Dafür brauche ich 10 Strings und eine handvoll Bits aus der SPS. Meine Frage kann ich auf dem Open Controller mir die benötigten Variablen mit s7.NET rausholen oder brauche dafür das ODK.

da es wirklich keine komplexe Anwendung ist bzgl. des Datenaustauches würde ich ungern das ODK kaufen.

Danke !

EDIT:

um die Frage vielleicht etwas klarer zu stellen kann ich mit 127.0.0.1 und s7.NET/sharp7 mir Daten aus der PLC Ebene holen wenn ich eine Anwendung auf der Windows Ebene des Controllers laufen lasse
 
Zuletzt bearbeitet:
Hallo,
Ich bin mir nicht sicher, ob ich deine Frage richtig verstanden habe, aber ohne ODK hat der OpenController keine direkte Schnittstelle zwischen SPS-Seite und Windows.
Stattdessen müsste man das ganze dann über TCP-Pakete realisieren.
Aber das müsste machbar sein für die paar Daten, die du brauchst.
Edit: Oder eben generell über einen Kommunikationsmechanismus ;)

Gruß Käse
 
Zuletzt bearbeitet:
HAllo zusammen und danke für die Antworten

Hallo,
Ich bin mir nicht sicher, ob ich deine Frage richtig verstanden habe, aber ohne ODK hat der OpenController keine direkte Schnittstelle zwischen SPS-Seite und Windows.
Stattdessen müsste man das ganze dann über TCP-Pakete realisieren.
Aber das müsste machbar sein für die paar Daten, die du brauchst.
Edit: Oder eben generell über einen Kommunikationsmechanismus :wink:

Gruß Käse

quasi von der softSPS aus daten an meinen windows localhost senden ?

Konnte man das bei der RTX nicht mal mit OPC, ist das jetzt beim Open Controller anders?

das hatte ich mir auch schon überlegt

ich suche da alles natürlich zeitlich wie immer super knapp ist die einfachste Lösung

das wäre vermutlich das ODK ?
 
Meiner Meinung nach bist du mit OPC schneller am Ziel, wenn es
den so Funktioniert wie bei der RTX. Ein Kollege hat seine Bedienoberflächen
immer mit OPC und .Net erstellt.

Mit ODK habe ich mal etwas gemacht, das war dann schon etwas Arbeitsintensiver,
allerdings soll das ODK-Tool in der 1500er Welt besser zu händeln sein.
 
Zuletzt bearbeitet:
Auch wenn es ein bisschen spät ist, laut diesem Dokument, kann man direkt eine Verbindung zwischen Windows und PLC über eine Open-User-Communication aufbauen:

https://www.siemens.de/Digital-Fact...-2015-Vortrag_1-2-ET200SP-Open-Controller.pdf

Das habe ich eben auch schon gesehen. Aber wie bindet man den Netzwerkadapter auf Windowsseite ein? Ich meine wenn ich von der CPU aus in den Windowsbereich kommunizieren will, muss ich doch auch ne IP haben nicht nur die HardwareID.

mfG René
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das musst du gar nicht. Die Hardware-ID beschreibt quasi deine SPS-Seite, du hast ja bei einem OpenController theoretisch 3 Interfaces. Die IP würde ich einfach die IP des Windows-Rechners angeben oder mit 127.0.0.1 probieren, Port bestimmt deine Anwendung

Wenn du generell Hilfe brauchst zum Aufbau einer OpenUserCommunication(OUC), dann einfach mal im Forum suchen oder nochmal melden. Ich benutze die Verbindung sehr gerne allerdings habe ich sie noch nie zur direkten Verbindung zwischen PLC und Windows auf einem OpenController benutzt, nur immer PLC zu irgendwelchen Geräten.
 
Bei einer OUC schiebe ich ja einfach ein Datenpaket über den TCP-Stack oder?
Wenn ich jetzt aus der SPS mehrere Variablen mit einem externen Programm austauschen möchte, wäre das auch vom Prinzip her eine absolute Kommunikation oder ? Also zB. ich sende 500 Bytes und muss mir dann aus diesen Bytes wieder meine Variablen mit den passenden Werten "rausfischen".
 
Also ich hab das heute mal getestet:

Man benutzt das lokale Interface mit der HW-ID 59, IP ist die IP die du über Windows einstellst. Wichtig hierbei scheint zu sein, das auf der PLC-Seite RemotePort != Local Port ist, sonst entsteht wohl eine Art Loop.

Zum Senden über TCP:
Ja man schickt ein Array of Byte ( da bei S7-1500 Variant) und diese Bytes muss man dann auf Windows-Seite wieder zerlegen. Die Bytes werden 1:1 so verschickt wie sie im Speicher liegen. Inzwischen muss man ja nicht mehr aufpassen wegen Little und Big Endian.

Also wenn du z.B ein Struct/UDT:
Messwert1REAL0.0
Messwert2REAL4.0
TextString[10]8.0

Dann schickst du quasi 20 Byte.
Du kannst jetzt entweder das ganze als Bits rüber senden und verarbeiten oder du wandelst das ganze in einen langen String um und schickst quasi in etwa so etwas:
'Messwert1=123.456;Messwert2=456.789;Text=abcde12345\r\n'
Dann ist man flexibler bei der Verarbeitung auf Windows-Seite. JSON sollte eigentlich auch leicht möglich sein :)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ja man schickt ein Array of Byte ( da bei S7-1500 Variant) und diese Bytes muss man dann auf Windows-Seite wieder zerlegen. Die Bytes werden 1:1 so verschickt wie sie im Speicher liegen. Inzwischen muss man ja nicht mehr aufpassen wegen Little und Big Endian.
Eigentlich muss man jetzt noch mehr aufpassen wegen der Endianess, denn die ändert sich andauernd wohingegen sie vorher immer gleich war.
Bereich optimiert / nicht optimiert / optimiert mit Remanenz im DB setzen / UDT im EA-Bereich / und noch mehr Spezialitäten die ich mir nicht alle merken kann.
 
Bei einer OUC schiebe ich ja einfach ein Datenpaket über den TCP-Stack oder?
Wenn ich jetzt aus der SPS mehrere Variablen mit einem externen Programm austauschen möchte, wäre das auch vom Prinzip her eine absolute Kommunikation oder ? Also zB. ich sende 500 Bytes und muss mir dann aus diesen Bytes wieder meine Variablen mit den passenden Werten "rausfischen".


und wenn man REAL in Bytes für ne Kommunikation zerschnippelt, sollte man zumindest mal an Datenkonsistenz denken, wenn bei nem REAL die ersten Bytes neu und die letzten noch alt sind, kommt ganz großer Quatsch raus... aber nur am Rande.

Gruß.
 
Eigentlich muss man jetzt noch mehr aufpassen wegen der Endianess, denn die ändert sich andauernd wohingegen sie vorher immer gleich war.
Bereich optimiert / nicht optimiert / optimiert mit Remanenz im DB setzen / UDT im EA-Bereich / und noch mehr Spezialitäten die ich mir nicht alle merken kann.

Naja dann gibt es auch nicht mehr als 2 Möglichkeiten oder? Wusste nicht das optimiert mit Remanenz ein anderen Endian nutzt

@ducati: Warum sollte man ein Real für die Übertragung denn zerschnippeln? Ich versuche doch möglichst alles auf einen Rutsch zu senden, alles andere wäre für mich nonsense

edit: Solange ich symbolisch arbeite, konvertiert die PLC doch alles brav wieder zurück nach Big Endian? Zumindest hab ich mich noch nie darum gekümmert, ich lese zwar nicht direkt aus einen nicht-optimierten Bereich sondern über ein InOut aber zumindest dann muss man sich keinen Kopf mehr machen.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
@ducati: Warum sollte man ein Real für die Übertragung denn zerschnippeln? Ich versuche doch möglichst alles auf einen Rutsch zu senden, alles andere wäre für mich nonsense

Weil beim tollen TIA (1200/1500) halt eben mehr oder weniger parallel zum OB1 gesendet wird. Und wenn ich Bytes sende (und nicht das komplette REAL) kann es eben sein, das Bytes eines REAL vom letzten bzw. neuen OB1 stammen und somit nicht mehr aus dem selben REAL-Wert stammen... Es sei denn, man kopiert sich den DB nochmal komplett um bevor man ihn sendet...

gruß.
 
Naja gut, jetzt sind wir bereits im Bereich des Netzwerk-Treibers. Das man sich darüber gedanken machen sollte, wann man welche Daten sendet, das war meine Grundvoraussetzung. Bisher haben wir nur die Möglichkeit und die technische Umsetzung angerissen und wirklich keine Details hier präsentiert.
Ich gehe davon aus, das man sich grundlegend mit der Steuerung befasst hat, bevor man damit arbeitet...
 
Das musst du gar nicht. Die Hardware-ID beschreibt quasi deine SPS-Seite, du hast ja bei einem OpenController theoretisch 3 Interfaces. Die IP würde ich einfach die IP des Windows-Rechners angeben oder mit 127.0.0.1 probieren, Port bestimmt deine Anwendung

Hm über eine Lokale IP kriege ich einfach keine Verbindung zum laufen.
Die Verbindung läuft mit:
HWID: 59
RemoteIP: 192.168.1.110
RemotePort: 12345
LokalPort: 12335

Laufen tut sie nicht mit
HWID: 59
RemoteIP: 127.0.0.1
RemotePort: 12345
LokalPort: 12335

Eine Idee was ich noch versuchen könnte?

mfG René
 
Zuviel Werbung?
-> Hier kostenlos registrieren
ich hatte das ganze jetzt schon vor einiger Zeit mit Snap7/moka7 gemacht das funktioniert problemlos, allerdings ist es halt PUT/GET basierend.

hat jemand von euch Erfahrung mit dem "neuen" ODK geht da nur C/C++ ?
 
Zurück
Oben