Mit B&R lieber REST abrufen oder MQTT subscriben? (...oder doch RAW-TCP)

[sbtcp]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen!

Leider habe ich keinen starken Background im Thema SPS und hoffe, dass mir hier gut weitergeholfen werden kann.
Ein Kunde von mir möchte gerne Daten von meinem Server abrufen. Dieser ist in derselben Maschine verbaut wie die B&R SPS und beide verfügen über einen Ethernetanschluss und statische IPs. Der SPS Programmierer auf der anderen Seite ist noch nicht so erfahren wenn es darum geht Daten von einem Linux-Server abzurufen.

Auf meiner Seite stehen zunächst einmal viele Möglichkeiten offen meine Daten an die SPS weiterzuleiten.

1. Am liebsten würde ich REST-API Endpunkte unter meiner IP bereitstellen, die mit einem JSON beantwortet werden. Jedoch weiß ich nicht, welcher Aufwand damit auf SPS Seite verbunden ist das JSON zu parsen und das entsprechende Feld auszulesen.
2. Ich kann auf meinem Gerät einen MQTT Broker laufen lassen und die SPS könnte bei mir eine eigene Topic-Subscriben.
3. Im allerschlimmsten Fall könnte ich auch eine Modbus-TCP Schnittstelle auf meinem Server einrichten.

CAN und andere physikalische Busse sind keine Option. Es ist also notwendig physikalisches 100BASE-T mit RJ45 zu verwenden. Hier meine Fragen:

1. Was ist davon am einfachsten auf Seite der SPS zu implementieren?
2. Gibt es bei bestimmten Protokollen Draw-Backs die ich gerade übersehe?
3. Kennt ihr Tutorials oder Ressourcen, wo ich mir die Implementierung auf SPS-Seite anschauen kann?

Lieben Dank für eure Hilfe im Voraus
sb

 

[Klingone22]

Hallo!

Ich komme von der (Beckhoff) SPS Seite, und würde sagen, Modbus TCP ist das Einfachste. Da ich immer wieder mit anderen GLTs kommunizieren muß, würde ich sagen, der Aufwand hängt davon ab wie motiviert der andere Programmierer ist eine gemeinsame Lösung zu finden.

LG

Klingone22

 

[sbtcp]

Zuviel Werbung?
-> Hier kostenlos registrieren

Danke schonmal für dein Feedback, mit den anderen hast du noch keine Erfahrungen selbst?

 

[shevek]

Hallo,

komme ebenfalls von der SPS-Seite, allerdings ebenfalls nicht von B&R. In meinem Fall, mit diversen, aus AEG hervorgegangenen Steuerungen, wäre ebenfalls ModbusTCP das einfachste. Ich wüsste ehrlich gesagt nicht mal, wie ich die anderen Ideen überhaupt in der SPS realisiert bekomme...

 

[da_kine]

Punkt 1 & 2 kannst du bei B&R mit On Board Mitteln komplett vergessen. Das müsste alles von hand implementiert werden. Ich sehe ebenfalls als einzige Möglichkeit den Modbus.

Was noch gehen würde wäre ein Datenaustausch via TCP, aber da müsstet ihr euch ein Protokoll ausdenken.

Grüße

Markus

 

[sbtcp]

Zuviel Werbung?
-> Hier kostenlos registrieren

Uff... nagut.
Danke für eure Rückmeldungen!
Gibt es denn einen SPS Typen den ihr gerade im Kopf hat, der bereits einen Block hat um REST-APIs auszulesen?

Ich meine, einen Modbus-TCP Endpunkt bereitzustellen habe ich bisher noch nie gemacht, kann ich mir aber gerade nicht so schwierig vorstellen. Wir werden sehen wie die Reise weitergeht.

VG sb

P.S.
Ich denke, ich werde mal die folgende Library nutzen um einen Modbus-TCP Data-Server für die SPS bereitzustellen:

Server: virtual data — pyModbusTCP 0.2.1.dev documentation

 

[Mrtain]

OPC ist keine Option?

 

[trobo]

Naja, Beckhoff bietet Bausteine für REST Client an

TwinCAT 3 IoT HTTPS/REST

Sogenannte REST (Representational State Transfer)-APIs werden in der IoT-Kommunikation häufig von Webservern angeboten, um bestimmte Kommunikationsabläufe...

www.beckhoff.com

Die Function TF6760 TwinCAT 3 IoT HTTPS/REST stellt Basisfunktionen für die HTTP/HTTPS-Kommunikation in Form einer SPS-Bibliothek zur Verfügung, um REST-APIs als Client ansprechen zu können. HTTP-Kommandos wie zum Beispiel GET, PUT und POST werden zur Verfügung gestellt. Die Absicherung des Kommunikationskanals (HTTPS) erfolgt über SSL/TLS-Mechanismen. Nachrichteninhalte können über XML- und JSON-Parser direkt aus dem SPS-Kontext heraus definiert, interpretiert und für die Kommunikation genutzt werden.

Wollte ich immer mal probieren, gerade da ich aktuell auch eine IFM IO-Link master Baugruppe mit REST / MQTT Schnittstelle hab. ABer die Zeit fehlt.
Vielleicht ist das sowas, was du suchst und kannst dir dort abschauen (Handbuch) wie Beckoff es macht?

Ansonsten ist MQTT recht dankbar, gibts ja für B&R ->

Um diese Inhalte anzuzeigen, benötigen wir die Zustimmung zum Setzen von Drittanbieter-Cookies.
Für weitere Informationen siehe die Seite Verwendung von Cookies.

Drittanbieter-Cookies akzeptieren

GitHub - br-automation-com/paho.mqtt.c-ar: MQTT Client for Automation Runtime based on eclipse/paho.mqtt.c

MQTT Client for Automation Runtime based on eclipse/paho.mqtt.c - GitHub - br-automation-com/paho.mqtt.c-ar: MQTT Client for Automation Runtime based on eclipse/paho.mqtt.c

github.com

 

[da_kine]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ansonsten ist MQTT recht dankbar, gibts ja für B&R

Kannte ich bisher auch noch nicht. Ich wusste dass es eine halbherzige MQTT Library gibt die von irgendwem mal erstellt, aber wohl seit 2019 nicht mehr gepflegt wurde.
Ist das was offizielles von B&R, also mit Support usw.?

 

[trobo]

Puh, ich bin ganz ehrlich, keine Ahnung.
Es ist zumindest die offizielle B&R Automation Github Seite, also sollte ja eigentlich eine gewisse Qualität erwartbar sein.