TIA HTTP-Request (GET und POST) - Von einer S7-1500 an einen Server

ASi-Master

Level-1
Beiträge
21
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin,

entweder ich suche mit den falschen Stichworten oder es geht mal wieder nicht:


Ich möchte mit REST-API Informationen von einem Server abholen. Im Browser (egal welcher) funktioniert das. In der SPS scheitere ich schon mit TSEND_C (Fehler 80A3 bei TCON).

Wo muss ich ansetzen? Geht das überhaupt?

Zur Info:

  • S7-1500
  • PC mit dem Serverprogramm im gleichen Netzwerk, Port 8081
  • Wie ich den String für die GET/POST-Abfrage zusammenbauen muss, weiß ich

Vielen Dank im Voraus für Eure Hilfe.
 
Wird die URL im Browser vielleicht über https aufgerufen? 8081 ist ja nicht der Standardport für http oder https, da musst du im Browser schon eine URL wie http://10.10.10.10:8081 eingeben.
https wird in der SPS nur mit sehr sehr großem Aufwand möglich sein, nur http sollte aber kein Problem sein.
Vielleicht kannst du auf dem PC auf dem der Server läuft einmal Wireshark installieren, dann kannst du direkt die Unterschiede sehen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin Thomas,

danke für die Antworrt. Ich entnehme daraus, dass es grundsätzlich geht.

Es ist definitiv kein https. Mit POSTMAN kann ich eine funktionierende GET-Abfrage erstellen, die mit „http://10.10....:8081/verzeichnis/...?bedingung1=bla&bedingung2=blabla..“ beginnt.

Ich frage mich vielmehr, mit welchem Partner ich vorab eine Verbindung aufbauen muss, denn dass Serverprogramm auf dem PC „weiß“ doch nicht, von „wem“ der Request kommt. Sind doch „nur“ TCP-Pakete, die auf dem Port 8081 „abgehört“ werden.

Welchen Baustein verwende ich, TSEND_C? Dann muss ich ja eine Verbindung aufbauen (ist mir klar, dass ich irgendeine Verbindung brauche). Oder TUSEND_C, aber das ist UDP...? Broadcast (geht auch nicht mit TCP)? Mir fehlt halt der richtige Ansatz.

Der PC, auf dem die Software läuft, ist ein Siemens-IPC mit 15“-Touch-Panel mit WIN7-Ultimate, extremst hoch-performant (haha, echt das langsamste Blech, das ich je gesehen habe, abgesehen von meinem alten AT286 im Keller...).
 
Zwischen Server und Client wird bei TCP eine eindeutige Verbindung aufgebaut, bestehend aus IP Adresse und Portnummer.
D.h. deine SPS baut eine TCP Verbindung zu z.B. 10.10.10.10 und Port 8081 auf. Den Quell-Port den deine SPS verwendet kannst du selber einstellen, z.B. 2000. Der Server sieht also eine Verbindungsanfrage von deiner SPS, z.B. 10.10.10.20 und Port 2000, und weiß daran an wen er die Daten schicken muss wenn er auf deine Anfrage antworten will. Bei einem PC-Programm wird der Quell-Port aus einem freien Bereich vom Betriebssystem selber vergeben.

Ich würde anstelle der kombinierten Bausteinen TSEND_C selber die einzelnen Funktionen TCON, TSEND, TRCV und TDISCON verwenden, dann siehst du besser was vor sich geht. Im Prinzip gleicht der Ablauf einer Schrittkette:
1. TCP Verbindung mit TCON zum Server auf Port 8081 aufbauen
2. Wenn Verbindung erfolgreich aufgebaut, http get Anfrage mittels TSEND abschicken
3. Mit TRCV auf dieser Verbindung lesen
4. Wenn Daten gelesen werden konnten (oder bei Fehler), TCP-Verbindung mit TDISCON abbauen
 
Hallo Thomas,

danke für die Antwort.

Was Du vorschlägst, ist exakt das, was ich erwartet habe, nur bin ich eben schon beim Verbindungsaufbau gescheitert (Fehler 80A3 von TCON als Bestandteil von TSEND_C gemeldet).

Ich muss nochmals nachhaken:


  • Wer oder was ist der Partner:
    • Der PC (Betriebssystem) selbst oder
    • das Programm?
  • Wenn es das Programm ist:
    • Muss im Programm etwas implementiert sein (Code), das mit einer SPS „reden“ kann (das wäre nicht gut, weil nicht vorhanden/änderbar) oder
    • “lauscht“ das Programm einfach nur auf dem angegebenen Port (es ist dem Programm ja auch egal, ob die Anfrage nun von POSTMAN, SAFARI, GOOGLE oder IE z.B. kommt)?

Ich verwende TSEND_C schon lange, das passt. Beobachten kann man sehr gut im Instanz-DB, es gibt Unterstrukturen der einzelnen Handlingsbausteine TCON, TSEND, TRCV und TDISCON. Trotzdem danke für den Hinweis.

Am Montag kann ich wieder an die Anlage. Erstmal muss die Verbindung klappen. Dabei graut es mir eigenlich vor dem Aufdröseln der Response-Daten (Listings mit unbestimmbarer Länge).........
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Die Serverdienste, also in deinem Fall der Webserver, stellt die Anwendung zur Verfügung. Diese Anwendung muss mindestens eine Anfrage von der IP-Adresse deiner SPS zulassen. Manche Webserver lassen wenn nichts weiter konfiguriert wird nur Zugriffe von localhost zu.
Aber wenn du deinen Test mit einem Webbrowser von einem anderen Rechner aus erfolgreich durchgeführt hast, dann wird der Server auch auf den Netzwerkschnittstellen nach außen lauschen.

Hast du mal versucht vom IPC aus die SPS anzupingen? Nicht dass das diese überhaupt nicht erreichbar ist, oder der IPC mehrere Netzwerkschnittstellen besitzt und du mit der SPS auf der falschen hängst.
 
Hallo Thomas,

die SPS hat auch andere Verbindungen im Netzwerk, unter anderem MODBUS-TCP und TCP-Verbindungen zu RFID-Readern und Smart-Kameras z.B., auch läuft WINCC Runtime auf dem IPC. Adressen sind klar, ohne Zweifel.

Ich schaue mir das am Montag nochmal an.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin,

ja, haben wir. Aber eines steht fest: Wenn die API-Schnittstelle nicht ordentlich dokumentiert ist, kann man‘s vergessen. Ansonsten kann man sich den nötigen String „zusammen basteln“ und einen request senden.

Zurzeit habe ein Projekt angefangen, SHELLY-Devices an eine SPS zu binden.

Was hast du denn vor?
 
Ich habe mir die Bibliothek von LHTTP runtergeladen von der Siemens Seite.
Damit werde ich auf dem richtigen weg sein oder wie habt ihr das realisiert?
 
LHTTP ist die richtige Bibliothek. Der Firmwarestand der SPS muss beachtet werden.

Hier ist alles beschrieben, was du brauchst. GET, um Daten abzuholen, POST, um Daten zu senden/ändern und noch ein paar Funktionen, um einen empfangenen RESPONSE „aufzudröseln“.

Und nochmal: Die API muss gut dokumentiert sein. Mit z.B. POSTMAN kannst du vorab testen, ob deine Anwendung, mit der du kommunizieren möchtest, sich so verhält, wie erwartet. So kannst du sicher sein, dass „url“ und optional „data“ am GET-Baustein richtig beschrieben sind und eventuelle Fehler nicht am übermittelten String liegen. Denn angezeigte Fehler und deren Erläuterung in der TIA-Hilfe, naja...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich werde mein Glück am Wochenende mal versuchen. Eingebunden habe ich die Bibliothek schon und der Firmwarestand passt auch.

Allerdings hab ich gesehen, das der POST der gesendet wird sehr mehrwürdig aussieht und auch noch
"Simatic S7-1500" etc drin stehen hat. Ist das normal?

Meine Api ist in sofern gut beschrieben, dass ich die Befehle die ich brauche erstmal senden kann.

 
Zuviel Werbung?
-> Hier kostenlos registrieren
Allerdings hab ich gesehen, das der POST der gesendet wird sehr mehrwürdig aussieht und auch noch
"Simatic S7-1500" etc drin stehen hat. Ist das normal?

Das dürfte die Browser-Kennung sein. Da kannst du oft auch rein schreiben was du willst, ist nur dann interessant, wenn auf der Server-Seite abhängig vom Browser unterschiedlicher Inhalt ausgeliefert wird ("Browser-Weiche"). Je nach verwendeten Features bzw. Html-Syntax wird nicht alles von jedem Browser unterstützt und der Server kann dann passend zum Browser verschiedene Versionen ausliefern.
 
Sorry,
komm da leider grad nicht zu.
Bin noch im Hausbau und hab mich die letzten Tage noch im das restliche Pflaster etc. kümmern müssen.
Muss vor der Zeitumstellung noch was schaffen.

Feedback gibt es aber auf jeden fall noch.
 
Zurück
Oben