TIA Abfrage mehrerer 1200er von einem Master

[tomlei]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wie sollte man mehrere 1200er mit einander kommunizieren lassen...?

An ca 10 Stellen (örtlich weit voneinander getrennt aber mit einem Netzwerk TCPIP miteinander verbunden) werden Energiemessdaten erfasst, Schaltzustände überwacht und jeweils auf einem gemeinsamen SQL Server gespeichert. Jede SPS hat ein eigenes Programm und soll an einen "Master" Schaltzustände melden bzw. der Master soll die Schaltzustände abfragen. Der Master wiederum ist an eine Telenot angerschlossen und über diese werden Fehlermeldungen / Ausfallmeldungen an den Bereitschaftsdienst gemeldet. Das ganze läuft momentan über eine Wagosteuerung und soll auf S7 umgerüstet werden.

Ich dachte jetzt an PUT/GET und habe mit den dazugehörigen Bausteinen getestet. Leider habe ich bisher keine funktionierende S7-Verbindung hinbekommen.

1. Wenn man das mit PUT/GET realisieren wollte, müssen die PLCs in einem Programm projektiert werden oder geht das auch mit einer unbestimmten Verbindung. Wenn ja wie...?
2. Welche Alternativen zu PUT/GET gibt es? Sicherheitskritische Zugriffe von Außen sind nicht zu erwarten.
3. Da zusätzlich auf dem SQL Server Rechner noch MQTT und Node-Red laufen, wären das eventuell akzeptable Alternativen? Wenn nein, was spricht dagegen?
4. Man könnte die Schaltzustände ja auch auf dem SQL Server in einem FehlerLog ablegen und dann durch den Master abfragen lassen. Ist das eine sinnvolle Variante oder Unsinn?
5. Eigentlich sollen die PLCs jeweils mit ihrem Projekt autark laufen. Spricht da etwas dagegen?

 

[Mrtain]

1/2

IDevice

3

Zu IDevice? Theoretisch, aber aufwendiger

4

Dann müssen alle SPS mit der DB kommunizieren. Kein Vorteil gegenüber IDevice

5

Nein.

 

[tomlei]

Zuviel Werbung?
-> Hier kostenlos registrieren

IDevice


Zu IDevice? Theoretisch, aber aufwendiger


Dann müssen alle SPS mit der DB kommunizieren. Kein Vorteil gegenüber IDevice


Nein.

IDevice?

 

[Mrtain]

Sorry falscher link....

 

[Mrtain]

Siehe hier:

https://support.industry.siemens.co...78798_config_idevice_standard_DOCU_V20_de.pdf

 

[Mrtain]

Zuviel Werbung?
-> Hier kostenlos registrieren

IDevice?

Put/Get sollte man wenn möglich vermeiden.

 

[tomlei]

Danke für den Link. Das lese ich mir in Ruhe durch.

Vorab eine Verständnisfrage -
Auf jeder 1200er läuft ein separates Projekt und im Projekt der Master PLC sind alle als IDevice hinzugefügt? Sind die PLCs dann passiv und werden durch die 1200 master PLC abgefragt? Oder müssen die Projekte auf den slaves auch angepasst werden?

 

[ducati]

Danke für den Link. Das lese ich mir in Ruhe durch.

Vorab eine Verständnisfrage -
Auf jeder 1200er läuft ein separates Projekt und im Projekt der Master PLC sind alle als IDevice hinzugefügt? Sind die PLCs dann passiv und werden durch die 1200 master PLC abgefragt? Oder müssen die Projekte auf den slaves auch angepasst werden?

Die Projekte den unterlagerten SPSn müssen bei egal welcher Lösung mit hoher Wahrscheinlichkeit angepasst werden...

SIOS

support.industry.siemens.com

Seite 116

 

[JesperMP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wie holt die SQL Server Rechner die Daten von die Master S7-1200 SPS ?
Was ist den Grund für den Aufbau mit Master-SPS und untergeordneter SPS'en ?
Konnte die SQL Server Rechner nicht die Daten direkt von jeden SPS holen, ohne über die Master-SPS zu gehen ?

 

[Mrtain]

Wie holt die SQL Server Rechner die Daten von die Master S7-1200 SPS ?
Was ist den Grund für den Aufbau mit Master-SPS und untergeordneter SPS'en ?
Konnte die SQL Server Rechner nicht die Daten direkt von jeden SPS holen, ohne über die Master-SPS zu gehen ?

Ich denke eher, das die Master SPS die Schaltzustände an den SQL Server schickt.

Die Schaltzustände müssen ja eh zur Master sps, wegen dem telnot.
Auf dem SQL Server werden die Zustände laut Beschreibung nur geloggt.

Sendet die untergeordnete SPS zuerst an den SQL Server, dann müssen die Zustände ja nochmal vom Server zum Master.
Sendet die untergeordnete SPS zuerst zum Master, und der Master dann zum SQL Server, spart man sich halt eine oder mehrere Abfragen, je nachdem wie die Tabellen angelegt sind.

Über ein lebensbit, dass man per idevice mit senden könnte, könnte man auch zum Beispiel die Kommunikation an sich überwachen.

 

[tomlei]

Der Gedanke war ursprünglich, dass jede PLC autark arbeitet und auf dem SQL Server die Daten ablegt. Eine PLC läuft bisher genau so. Mehrere Sensor Werte werden in unterschiedlichen Zyklen in einem fifo gespeichert und ein FB leert diesen fifo und speichert die Daten mit LSql im Server.
Der master war jetzt eigentlich nur dafür gedacht die Verbindung zur Telnot herzustellen und die Schaltzustande zu melden. Der SQL Server hat mit den ca. 10 bis 15 Daten sende PLCs kein Problem.
Der Gedanke mit dem master, der die Daten einsammelt und dann die Speicherung übernimmt, ist natürlich auch nicht schlecht. Ich wusste nur nicht wie ich das umsetzen könnte.

 

[van]

Zuviel Werbung?
-> Hier kostenlos registrieren

Es gibt auch MQTT Bausteine von Siemens.
Dann kann jede Station gleich direkt mit Node red kommunizieren

Oder du nimmt OPC-UA zwischen den Sps

IDevuce (profinet) hat den Nachteil das es nicht Routing fähig ist

 

[Mrtain]

IDevuce (profinet) hat den Nachteil das es nicht Routing fähig ist

Stimmt, daran habe ich garnicht gedacht

 

[tomlei]

Es gibt auch MQTT Bausteine von Siemens.
Dann kann jede Station gleich direkt mit Node red kommunizieren

Oder du nimmt OPC-UA zwischen den Sps

IDevuce (profinet) hat den Nachteil das es nicht Routing fähig ist

Mit mqtt habe ich in einem anderen Projekt auch etwas umgesetzt. Das funktioniert auch ganz gut als quasi informations Relais Station. Und ja, an node-red hatte ich auch schon gedacht, wenn es an eine simple Visualisierung im Browser geht.
Diese Vielzahl an Systemen kommen zustande, wenn man kostenbewusste Lösungen sucht und die Investition in Siemens Lösungen vermeiden will/muss. Ob das dann immer die langfristig beste Lösung ist, steht auf einem anderen Blatt.... Aber, zu jedem Stift gehört eine Hand, die den Auftrag und damit die Kosten absegnen muss.

 

[DCDCDC]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wahrscheinlich wäre Mqtt die hier die "zentralere" Lösung als Idevice, wobei Idevice die nähere Lösung an Siemens wäre. Müssen aber E/A Bereiche freigehalten werden.

Wobei ich mich für die Mqtt Variante entscheiden würde, da diese auch autark funktioniert und sämtliche Systeme in der Zukunft als auch im aktuellen Aufbau, diese Daten verwerten können.

So oder so, musst du an die Projekte auf den 1200ern ran.

 

[ducati]

Wobei ich mich für die Mqtt Variante entscheiden würde, da diese auch autark funktioniert und sämtliche Systeme in der Zukunft als auch im aktuellen Aufbau, diese Daten verwerten können.

Mit Prognosen, vor allem, wenn sie die Zukunft betreffen, wäre ich vorsichtig...

Aktuell kriegt der TE nichtmal Put/Get zum laufen. Jetzt stell ich mit MQTT nicht unbedingt einfacher vor...

 

[DCDCDC]

Mit Prognosen, vor allem, wenn sie die Zukunft betreffen, wäre ich vorsichtig...

Aktuell kriegt der TE nichtmal Put/Get zum laufen. Jetzt stell ich mit MQTT nicht unbedingt einfacher vor...

Mit mqtt habe ich in einem anderen Projekt auch etwas umgesetzt. Das funktioniert auch ganz gut als quasi informations Relais Station.

 

[winnman]

Zuviel Werbung?
-> Hier kostenlos registrieren

In dem Fall geht es ja eigentlich nur um GET vom Master an die Unterstationen.

Da wäre ein GET ev. doch eine saubere Lösung.

Muss man nur den 1200ern beibringen das sie auf GET antworten, mit sehr viel Glück geht das sogar ohne die 1200er anzufassen.

 

[ducati]

In dem Fall geht es ja eigentlich nur um GET vom Master an die Unterstationen.

Da wäre ein GET ev. doch eine saubere Lösung.

Muss man nur den 1200ern beibringen das sie auf GET antworten, mit sehr viel Glück geht das sogar ohne die 1200er anzufassen.

Ich warne mittlerweile davor, den Haken für "Put/Get erlauben" in den SPSn zu setzen... Mittlerweile hängen doch alle SPSn irgendwie im Netzwerk und irgendwann schreibt irgendeine SPS irgendwo in irgendeinen DB.
Hatte ich persönlich in den letzten 3 Jahren 2 mal. Da suchst Dich dumm... grad erst vor zwei Wochen nen ähnlichen Fall... und Feierabend ist erst, wenn die Anlage wieder läuft...

Bei unerklärlichen Problemen hab ich mir schon angewöhnt, erstmal kurz zum Testen den Netzwerkstecker zu ziehn...

 

[centipede]

Ich habe so etwas schon mal mit Hilfe dieses Anwendungsbeispiels gelöst. Bei mir frägt eine S7-300 mehrere S7-1200 im ganzen Land verteilt über TCP-Strecken zyklisch ab.
Funktioniert nach anfänglichen Problemen mittlerweile sehr zuverlässig.

SIOS

support.industry.siemens.com