TIA Zugriff auf eine 1500er von andere 1500er ohne PUT/GET möglich?

L

LowLevelMahn

Level-1
Beiträge
766
Reaktionspunkte
90
Zuviel Werbung?
-> Hier kostenlos registrieren
Wie kann ich zwei 1500er SPS Daten aus symbolischen DBs austauschen lassen
ohne PUT/GET zu aktivieren und meine DBs unoptimiert laufen zu lassen - geht das irgendwie?

die HMIs brauchen ja auch nicht unbedingt die PUT/GET Freischaltung um Variablen lesen/schreiben zu können

Ich habe dieses PDF gefunden: http://cache.automation.siemens.com/dnl/zM/zM1NjM2MwAA_82212115_FAQ/S7_communication_S7-1500_de.pdf
aber da wird ja auch PUT/GET freigeschaltet und der DB nichtsymbolisch betrieben
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
USEND/URCV verschickt ja auch nur Datenpakete - der Symbolbezug wird dabei mit meinem eigenen Code herstellt

bei den HMIs kann man aber problemlos direkt mit den DBs arbeiten - mich würde es auch nicht stören
die 1500er wie das HMI dafür zu projektieren - was mich stört ist nur das die HMIs es buildin können und
alle andere Abnehmer (wie z.B. meine andere SPS) von Hand "programmiert" werden müssen das zu können - und dann
noch eingeschränkt (nur mit Freischaltung und nicht-symbolisch)

Ich verstehe nicht warum ein HMI mehr Feature bei der Kommunikation mit einer SPS bieten soll - als eine normale SPS
wurde da einfach was vergessen?
 
Zuletzt bearbeitet:
Klar gehen die ganzen offenen Kommunikationen - aber ich muss mich doch bei allen um die Quelle und Ziel in meinem Code kümmern
soweit ich das sehen gibt es nicht vergleichbares zu der Fähigkeit eines projektierten HMIs das man sich um das Mapping gar nicht kümmern muss - was mich verwundert

Beispiel um aufzuzeigen wo mir Funktionalität fehlt die ein HMI scheinbar schon kann - eine SPS aber nicht

du machst deinen symbolischen DB - mit 3 Variablen (a,b,c) und projektierst ein HMI das c = a+b macht

jetzt willst du das HMI und die c = a+b Operation durch eine SPS Ersetzen (weil kommunikativ gesehen ist
das HMI auch nur eine SPS mit anderer Programmierung/Fähigkeiten)

da die SPS nach meinen bisherigen Kenntnissen kein SPS-Variablen-Mapping kann muss man jetzt mit
PUT/GET, USEND/URECV oder andere offene (aber händisch) programmierte Varianten arbeiten - d.h. ich muss mein Programm anspassen
damit die neu eingeführte SPS mit mir reden kann - für das HMI war das nicht nötig

Warum ist das so? (und bitte nicht "Wegen Siemens", "Weil es so ist" oder "wegen dem TIA" als Antwort)
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Musst doch bei der HMI eigentlich das selbe machen. nur wo anders.

Bei HMI legst du die Variablen an und irgendwo musst du die Kommunikation parametrieren (von welcher SPS, . .)
Bei der SPS legst du deinen DB an und parametrierst die Kommunikation (über Get, Recive, . . .)

Ist doch eigentlich kein Unterschied. (muss eben nur an anderer Stelle gemacht werden)

Hast du Variable mal in HMI / SPS kannst du damit machen was du willst (bzw das System kann)
 
Warum ist das so? (und bitte nicht "Wegen Siemens", "Weil es so ist" oder "wegen dem TIA" als Antwort)
Zum Vergrößern anklicken....

Ich fürchte die sind alle drei richtig. Ist wohl eher eine historische Angelegenheit, weil man den Mausschubsern von WinCC das immer schon so angeboten hat, muss es jetzt auch mit neuer Hardware gehen - und das einfach. Technisch gesehen spricht nichts dagegen, außer dass man sehr genau aufpassen sollte wer da wann auf welchen Daten rumpfuscht. (Bei Panels wohl weniger kritisch)

Insbesondere weil sich die 1500er hier wie die 400 verhält und nicht an den Zykluskontrollpunkt gebunden ist:
● Bei der S7-400 uns S7-1500 werden im Gegensatz dazu die Kommunikationsdaten in
Blöcken zu 462 Bytes nicht im Zykluskontrollpunkt, sondern in festen Zeitscheiben während
des Programmzyklusses bearbeitet. Systemseitig wird die Konsistenz einer Variable
garantiert. Auf diese Kommunikationsbereiche kann dann, z. B. von einem OP oder von
einer OS, mit den "PUT (Seite 4407)" / "GET (Seite 4405)"-Anweisungen bzw. Lesen/
Schreiben von Variablen konsistent zugegriffen werden.
Zum Vergrößern anklicken....

Auf gut Deutsch hast du keine Ahnung wo und wann ein Partner mit Put/Get reingreift und ob er dann auch einen gewollten Wert bekommt. Mag oft gut gehen, verursacht aber sehr interessante Probleme wenn nicht.

PS: Am PUT/GET Aufruf lokal kann auch ein optimierter DB anliegen, nur der DB auf der Gegenseite muss Standard sein.
 
@winnman
Bei der SPS legst du deinen DB an und parametrierst die Kommunikation (über Get, Recive, . . .)
Zum Vergrößern anklicken....

genau das machst du eben nicht beim HMI - dem HMI werden nur die gewünschte Variablen zugeordnet und ohne händische oder automatische Änderung
in deinem Programm kann das HMI mit dir reden - was nicht der Fall ist wenn es eine SPS ist - dann musst du das alles selber programmieren

@Pipboy

Ich fürchte die sind alle drei richtig. Ist wohl eher eine historische Angelegenheit, weil man den Mausschubsern von WinCC das immer schon so angeboten hat, muss es jetzt auch mit neuer Hardware gehen - und das einfach. Technisch gesehen spricht nichts dagegen, außer dass man sehr genau aufpassen sollte wer da wann auf welchen Daten rumpfuscht. (Bei Panels wohl weniger kritisch)
Zum Vergrößern anklicken....

sowas dachte ich mir auch schon - sehr gute Erklärung: Aber trotzdem schade das die "Interprozess"-Kommunikation schon so früh - also immer sofort - in Kundenprogrammierhand gelegt wird
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Pipboy schrieb:
Insbesondere weil sich die 1500er hier wie die 400 verhält und nicht an den Zykluskontrollpunkt gebunden ist:
● Bei der S7-400 uns S7-1500 werden im Gegensatz dazu die Kommunikationsdaten in
Blöcken zu 462 Bytes nicht im Zykluskontrollpunkt, sondern in festen Zeitscheiben während
des Programmzyklusses bearbeitet. Systemseitig wird die Konsistenz einer Variable
garantiert. Auf diese Kommunikationsbereiche kann dann, z. B. von einem OP oder von
einer OS, mit den "PUT (Seite 4407)" / "GET (Seite 4405)"-Anweisungen bzw. Lesen/
Schreiben von Variablen konsistent zugegriffen werden.
Zum Vergrößern anklicken....
Zum Vergrößern anklicken....

Wo kommt das her? Bin schon langer auf der Suche nach Details zu den "Zeitscheiben" also wann genau wird bei der Kommunikation von WinCC(7.0) mit einer 300 (400) auf die DBs zugegriffen....

Gruß.
 
LowLevelMahn schrieb:
Klar gehen die ganzen offenen Kommunikationen - aber ich muss mich doch bei allen um die Quelle und Ziel in meinem Code kümmern
soweit ich das sehen gibt es nicht vergleichbares zu der Fähigkeit eines projektierten HMIs das man sich um das Mapping gar nicht kümmern muss - was mich verwundert

Beispiel um aufzuzeigen wo mir Funktionalität fehlt die ein HMI scheinbar schon kann - eine SPS aber nicht

du machst deinen symbolischen DB - mit 3 Variablen (a,b,c) und projektierst ein HMI das c = a+b macht

jetzt willst du das HMI und die c = a+b Operation durch eine SPS Ersetzen (weil kommunikativ gesehen ist
das HMI auch nur eine SPS mit anderer Programmierung/Fähigkeiten)

da die SPS nach meinen bisherigen Kenntnissen kein SPS-Variablen-Mapping kann muss man jetzt mit
PUT/GET, USEND/URECV oder andere offene (aber händisch) programmierte Varianten arbeiten - d.h. ich muss mein Programm anspassen
damit die neu eingeführte SPS mit mir reden kann - für das HMI war das nicht nötig

Warum ist das so? (und bitte nicht "Wegen Siemens", "Weil es so ist" oder "wegen dem TIA" als Antwort)
Zum Vergrößern anklicken....

Bei CFC kannst Du AS-übergreifende Verschaltungen realisieren. Also einfach Bausteinanschlüssen aus verschiedenen CPUs per Mausklick miteinander verbinden. Nur leider gibt es da auch viele Einschränkungen. Wird denke ich auch eher selten benutzt.

Ich persönlich hab bei der AS-AS-Kopplung lieber einen definierten DB zum Datenaustausch. Habs nicht so gern, das da jeder in meine Variablen beliebig schreiben lesen kann...

Gruß.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
OT: S7-300 "priorisierte BuB-Kommunikation"

ducati schrieb:
Bin schon langer auf der Suche nach Details zu den "Zeitscheiben" also wann genau wird bei der Kommunikation von WinCC(7.0) mit einer 300 (400) auf die DBs zugegriffen....
Zum Vergrößern anklicken....
Bei der S7-300 nennt Siemens das "priorisierte BuB-Kommunikation".
Als die ca. 2010 ab Firmware V3.2 der S7-300 von Siemens eingeführt wurde, da gab es auch einen Flyer mit bunten Bildern, den finde ich aber grad nicht wieder.

Wie aktivieren Sie die Funktion "priorisierte BuB-Kommunikation", um die Performance der OP-Kommunikation zu erhöhen?
Wie erhöhe ich die Performance der HMI-Geräte?

Achtung! Die von S7-300 vorher gewohnte Synchronität und Konsistenz der Kommunikation zum Zykluskontrollpunkt ist dann nicht mehr gegeben.
Bei der S7-400 ist die Kommunikation schon immer asynchron zum Zykluskontrollpunkt.

siehe auch die Gerätehandbücher S7-300-CPU-Daten und S7-400-CPU-Daten
Stichwort: OP-Kommunikation, Konsistenz, Kommunikationslast, Zykluskontrollpunkt

Harald
 

Similar threads

N
Step 7 Datenaustausch S7-300 mit redundantem S7-400H-System
Antworten
2
Aufrufe
3K
vollmi
vollmi
Zurück
Oben