TIA S7 Kommunikation von S7-1500 auf S7-300

[TSI09]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

bin gerade am Entwickeln unserer Maschinen mit S7-1500. Gerade beschäftige ich mich damit, ob ich bei den Datenbausteinen auf Optimierte oder nicht Optimierte Bausteine gehen soll.
Dabei ist die Frage aufgetreten, wie die S7 Kommunikation zu S7-300 CPU`s fuktioniert, wenn ich optimierte Bausteine verwende.
Ich kann ja jetzt z.b. beim BSEND keine Sendebereich mehr angeben. Wie kann für optimierte datenbausteine bei BSEND einen Sendebereich festlegen?

Hat jemand von euch jemand schon Erfahrungen damit?

Herzlichen Dank

Mit freundlichen Grüßen

Markus Arbeithuber

 

[vollmi]

Dabei ist die Frage aufgetreten, wie die S7 Kommunikation zu S7-300 CPU`s fuktioniert, wenn ich optimierte Bausteine verwende.
Ich kann ja jetzt z.b. beim BSEND keine Sendebereich mehr angeben. Wie kann für optimierte datenbausteine bei BSEND einen Sendebereich festlegen?

Optimierte Bereiche lassen sich einfach nicht versenden. DBs die kommuniziert werden dürfen nicht optimiert sein.
Wenn sie an 300/400 gehen sowieso, Da BSEND ja die Sendung sowieso segmentiert, müssten sie ja sowieso wieder deoptimiert werden damit die 300er weis wie das Zeug zusammengehört.

mfG René

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich kann ja jetzt z.b. beim BSEND keine Sendebereich mehr angeben. Wie kann für optimierte datenbausteine bei BSEND einen Sendebereich festlegen?

Wieso sollte man keinen Sendebereich angeben können? Es muß einer angegeben werden. Man kann sich nur nicht mehr selber einen ANY zusammenbasteln, sondern muß den Sendebereich symbolisch angeben, z.B. eine Struct oder ein Array of BYTE.
Sendebereich ist der eigene Datenbereich.

Falls Du die Zieladresse in der S7-300 meinst: die konnte man bei BSEND noch nie angeben, der Empfänger muß einen zu dem BSEND passenden BRCV aufrufen (siehe Parameter R_ID).

Optimierte Bereiche lassen sich einfach nicht versenden. DBs die kommuniziert werden dürfen nicht optimiert sein.

Ist das wirklich so? (ich habe kein aktuelles TIA)
Darf bei S7-1500 der bei BSEND.SD_1 anzugebende eigene Sendebereich wirklich nicht in optimierten DB liegen?


Alternativ: Muß es denn unbedingt S7-Kommunikation sein? Können die Stationen nicht auch z.B. per ISO-on-TCP (mit TSEND) kommunizieren?

Harald

 

[vollmi]

Ist das wirklich so? (ich habe kein aktuelles TIA)
Darf bei S7-1500 der bei BSEND.SD_1 anzugebende eigene Sendebereich wirklich nicht in optimierten DB liegen?

Ich habs auf jedenfall nie hingekriegt. Wäre für mich eben ein Nice to have gewesen um die Länge kürzer zu halten. Aber schon das Anschliessen am BSEND funktioniert nicht wenn der Baustein optimiert ist, also dürfte das von 1500 zu 1500 auch nicht möglich sein. Die Fehlermeldung ist aber interessant, die motzt nämlich nicht die Optimierung an sondern lautet wie folgt.

4,Nur Datenbausteine, die auf einem PLC-Datentyp oder einem Systemdatentyp basieren, können mit dem Datentyp VARIANT adressiert werden.,,,17:20:15

Wenn man von Optimiert auf Nicht optimiert schaltet. Wird nach meinem Verständnis ein DB doch nicht zum PLC-Datentyp oder Systemdatentyp. Trotzdem funktionieren dann alle Kommunikationsarten.

Eigentlich unverschämt. Vor 3 Jahren haben sie die Optimierung ja angepriesen und gesagt die ganze CPU wird langsamer sobald ein Baustein nicht optimiert ist. Schonmal jemand ein Programm gesehen das so auf Zykluszeit angewiesen ist dass das ne Rolle spielt aber doch so trivial eingebunden dass es nichts zu komunizieren gibt?

mfG René

 

[de vliegende hollander]

Auf die schnelle mit verschiedene varianten probiert.

Symbolisch geht das nicht.

Bram

 

[de vliegende hollander]

Zuviel Werbung?
-> Hier kostenlos registrieren

Spätestens wenn eine Leittechnik auf die DB zugreift muss mann sowieso auf absolute Adressierung (Nicht optimiert.)

 

[PN/DP]

4,Nur Datenbausteine, die auf einem PLC-Datentyp oder einem Systemdatentyp basieren, können mit dem Datentyp VARIANT adressiert werden.,,,17:20:15

1) Kann man nicht den Sendepuffer als PLC-Datentyp deklarieren, damit TIA den für den VARIANT-Parameter verwenden kann?
2) Ein Array of Byte gehört nicht zu den "Systemdatentypen"?

Harald

 

[PN/DP]

Spätestens wenn eine Leittechnik auf die DB zugreift muss mann sowieso auf absolute Adressierung (Nicht optimiert.)

Vermutlich soll keine Leittechnik mehr wahlfrei auf DB zugreifen. Können die (noch) nicht symbolisch auf Variablen zugreifen?

Harald

 

[vollmi]

Zuviel Werbung?
-> Hier kostenlos registrieren

1) Kann man nicht den Sendepuffer als PLC-Datentyp deklarieren, damit TIA den für den VARIANT-Parameter verwenden kann?
2) Ein Array of Byte gehört nicht zu den "Systemdatentypen"?

Harald

Das geht. Wenn man z.B. einen ganzen DB tranferieren will. Dann kann man einen UDT erstellen der genau dem gewünschten DB entspricht. Einen neuen DB erstellen vom Typ des UDTs. Der darf dann optimiert sein. Oder man sendet nur einen Teil eines optimierten DBs der durch einen UDT definiert ist. Offenbar werden UDTs nicht optimiert. Ich hab aber die Grösse nicht gemessen.

Diese Vorgehensweise hat übrigens einen ganz netten Vorteil. Wenn man den UDT in die Projektbibliothek legt, kann man ihn jederzeit verändern und sowohl Ziel wie auch QuellSPS werden aktualisiert. Also kein DB auf einer CPU verändern laden, dann copy and paste zur anderen CPU und dort ebenfalls laden. Das geht dann automatisch.

mfG René

 

[Thomas_v2.1]

Das geht. Wenn man z.B. einen ganzen DB tranferieren will. Dann kann man einen UDT erstellen der genau dem gewünschten DB entspricht. Einen neuen DB erstellen vom Typ des UDTs. Der darf dann optimiert sein. Oder man sendet nur einen Teil eines optimierten DBs der durch einen UDT definiert ist. Offenbar werden UDTs nicht optimiert. Ich hab aber die Grösse nicht gemessen.

Ich steige da noch nicht so ganz durch.

In dem "Programming guideline" für das TIA-Portal steht, dass Anwenderdatentypen separat abgelegt werden.
In einem Bildchen in dem Dokument sieht es so aus, als ob die Daten in den Anwenderdatentypen überhaupt nicht optimiert abgelegt werden, also dass dort dann z.B. auch (Padding-)Bytes frei bleiben würden. Außerdem fangen Anwenderdatentypen angeblich immer an einer "Word Grenze" an. Wenn es jetzt doch feste Adress(offsets) gibt, dann könnte das TIA-Portal diese doch netterweise auch anzeigen. Und kann ich aus diesen Offsets schließen, dass eine Variable von einem Anwenderdatentyp in einem "optimierten" DB "nicht optimiert" abgelegt wird? Was ist mit Bools in einem UDT, die doch wegen der Optimiertung an anderer Stelle ein ganzes Byte einnehmen, weil der Zugriff schneller ist? Bedeutet das also, dass ein Bool im UDT langsamer ist als ein Bool direkt in einem "optimierten" DB?

Dann steht in einem Kapitel zur Kommunikation, dass ich z.B. mit TSEND/TRCV optimierte und nicht-optimierte DBs bei Send- und Empfangsdaten mischen könne, das TIA-Portal macht das (wie auch immer) richtig. Wie erkennt das TIA-Portal das, bzw. der Partner?

So wie ich das sehe, gibt es damit drei verschiedene Datenablagemöglichkeiten die komplett verschieden sind:
- "nicht optimierter" DB
- "optimierter" DB
- Anwenderdatentyp in einem "optmierten" DB

 

[vollmi]

Ich steige da noch nicht so ganz durch.

Das beruhigt mich etwas. Denn ich auch nicht.

In einem Bildchen in dem Dokument sieht es so aus, als ob die Daten in den Anwenderdatentypen überhaupt nicht optimiert abgelegt werden, also dass dort dann z.B. auch (Padding-)Bytes frei bleiben würden.

Zumindest zueinander bleiben die Inhalte eines UDT unoptimiert. Also wenn in der Struktur 1 bit, dann 1 Word, dann wieder 1 Bit kommen.
Dann kann man, wenn man die Adresse vom 1 Bit hat davon die Stelle vom anderen Bit ausrechnen.

Wenn man einen UDT in einem Optimierten DB einbringt (irgendwo da drin) diesen dann an einen FC anlegt der als eingang ebenfalls diesen UDT hat. Kann man im FC(nicht optimiert) eine AT Sicht drauflegen aus z.B. 3 worten und hat dann die Bits genau an der Stelle in den Worten wo man sie auch in der 300 gehabt hat.

Dann steht in einem Kapitel zur Kommunikation, dass ich z.B. mit TSEND/TRCV optimierte und nicht-optimierte DBs bei Send- und Empfangsdaten mischen könne, das TIA-Portal macht das (wie auch immer) richtig. Wie erkennt das TIA-Portal das, bzw. der Partner?

Die können offenbar keine optimierten Datenbereiche senden, man kann auch keine optimierten Datenbereiche anlegen.
Ein UDT in einem Optimierten DB ist ja offenbar nicht optimiert.
Ein Optimierte DB der als UDT deklariert wurde, ist offenbar auch nicht optimiert.
Eine im optimierten DB deklarierte Sturkur ist scheinbar auch nicht optimiert. ein Bit nimmt also auch da ganz bestimmt ein Byte ein
Ein nicht optimierter DB sowieso nicht.

Und das sind die Typen die man an den Variant eines TSEND etc. anlegen kann.

Einen von Hand zusammengebastelten optimierten DB kann man nicht an einen TSEND etc. anhängen.

So wie ich das sehe, gibt es damit drei verschiedene Datenablagemöglichkeiten die komplett verschieden sind:
- "nicht optimierter" DB
- "optimierter" DB
- Anwenderdatentyp in einem "optmierten" DB

und Structuren in einem optimierten DB

mfG René

 

[Ralle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich glaube seit einiger Zeit, optimierte DB sind eine echte Totgeburt. Keiner blickt richtig durch, hier geht das nicht, dort jenes nicht, gebraucht wird es ohnehin nicht wirklich. Warum muß/soll sich der (in meinem Fall dumme) SPS-Programmierer überhaupt um Fragen von optimiert oder nicht optimiert kümmern? Weil Siemens zu dämlich war, das richtig zu lösen und meinte, in Sachen Perfomance dann mit anderen Steuerungen mitzuhalten? Das schaffen die selbst mit optimierten DB nicht, traurig, aber auch nur in speziellen Fällen wirklich nötig. Jedenfalls gehört diese Rumfrickelei mit optimiert, nicht optimiert usw. m.E. nicht in unsere Hände, ich will es jedenfalls nicht. Meine Maschine soll ein paar Autoteile oder Handys zusammenbauen, prüfen oder sonstwas, ich hab im Prinzip genug mit halbwegs optimalen technologischen Abläufen zu tun, jetzt soll ich mich auch noch darum kümmern? Wie wäre es, wenn wir wieder schick Assembler schreiben, das hatte meine erste Steuerung. Da mußte ich mich auch um alles selbst kümmern, Speicherverwaltung Eingaben, Ausgaben etc. Ich frage mich, was an diesem tollen Speicherfeature Fortschritt sein soll?

 

[RONIN]

Ich steige da noch nicht so ganz durch.

Da schließe ich mich gleich an.

Ein UDT in einem Optimierten DB ist ja offenbar nicht optimiert.

Es gibt da ja noch ein Problem.
Ich bin der Meinung das UDTs in optimierten DBs Zwitter sind.

Das "optimiert" betrifft ja im Unterschied zur 300er nicht nur die Anordnung der Variablen und die Padding-Bytes.
Der größte (und vermutlich wichtigste) Teil der "Optimierung" ist ja dass die Daten im Little-Endian Format abgelegt werden.
Der größte Performance-Nachteil (zwischen optimiert und nicht) wird auf der 1500 ja dadurch entstehen dass diese beim Zugriff auf nicht optimierte Bereiche vor jedem Lesen und Schreiben einen Byte-Swap machen muss. Auch beim Bool-Zugriff hat die 1500 beim nicht optimierten DB mehr Arbeit (ausmaskieren).

Die "optimiert" hat nicht viel mit Speicherplatz zu tun. Das sieht man ja wie die UDts und vor allem die Bools (auf der 1500er als ganzes Byte) abgelegt werden.

Wenn ich die Seiten 11-13 der Programming-Guideline richtig deute, würde der UDT im optimierten DB zwar als Block abgelegt werden, aber als Little-Endian.
Ich würde die UDTs in den opitmierten DBs also nicht unbedingt mit der 300er-Variante in Verbindung bringen, es ist einfach eine Ablage als Block weil den
Siemens-Mannen (als Sie sich überlegt haben wie Sie ganze Blöcke verschieben sollen) klar geworden ist, dass ihnen dieses verstreute Ablagekonzept selber zu kompliziert geworden ist.

Wenn der UDT dann wirklich noch so ein Zwitter ist dann bin ich endgültig verwirrt. :-?


EDIT:
@RALLE: Wie gesagt, ich glaube das "optimiert" wurde nur eingefügt weil die neue Prozessorgeneration mit Little-Endian arbeitet. Dann mussten sich die Siemensianer halt was einfallen lassen. Man musste einerseits die alte Big-Endian-Ablage wegen der Kompatibilität behalten, andererseits konnte man den Little-Endian-Prozessor nicht ewig mit Big-Endian-Daten füttern. Neben dem Little-Endian sind auch noch weitere Änderungen wie zum Beispiel die Bit-Ablage als ganzes Byte dazugekommen. Also Datenablage so wie der Prozessor es am liebsten hätte.

Rausgekommen ist das was wir jetzt haben.
Optimierte DBs (weil Little-Endian für Little-Endian) und nicht optimierte Dbs bei dem die CPU vor jedem Zugriff Bytes jongliert. :-|
"Optimiert" ist meiner Meinung nur das Schlagwort mit dem die Siemens-PR uns diesen Salat verkauft.

 

[RONIN]

Ach und hatten wir schon erwähnt dass die "optimierte" Datenablage auch noch zwischen 1200 und 1500 unterschiedlich ist.

Die 1500 speichert jedes Bit als ganzes Byte ab.
Die 1200 speichert 8 Bit in ein einzelnes Byte.

Also wie viele Varianten hatten wir nochmal....? :-?

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die 1500 speichert jedes Bit als ganzes Byte ab.

Auch wenn die Variable in einem Anwenderdatentyp in einem optimierten DB liegt?

Prinzipiell ist das "Problem" auch bei C bekannt. In der Sprache an sich ist nicht festgelegt, wie die Daten einer Struktur im Speicher abgelegt werden. Gleiches auch z.B. für den Datentyp "int", dafür ist nur die Minimalgröße von 16 Bits festgelegt. Was bedeutet, dass ein "int" auf einem 8-Bit Prozessor 16 Bit groß sein kann, auf einer anderen Maschine aber auch 32 oder gar 64 Bit.
Will man die Reihenfolge der Daten festlegen, gibt es sowas wie #pragma pack.

Das blöde ist die Siemens Nomenklatur mit "optimiert" und "nicht optimiert", und die Dokumentation dazu in der viel rumgelabert wird, aber nichts konkretes gesagt wird. Und da es keine solche Option wie "packed" gibt mit der ich selber angeben kann wann und wie gepackt wird und wann nicht, muss man sich das aus der Dokumentation zusammenreimen. Dabei kommt dann sowas wie "wenn ein UDT in einem optimierten DB angelegt ist, sind die Daten im UDT nicht optmiert, aber Big-Endian, bei einer Struct in einem optimierten DB sind die Daten optimiert. In einem nicht optimierten DB sind die Daten aber als Little-Endian abgelegt" heraus (ich weiß immer noch nicht ob das richtig ist).

 

[RONIN]

Auch wenn die Variable in einem Anwenderdatentyp in einem optimierten DB liegt?

Das kann ich nicht sagen. Die einzigen brauchbaren Informationen die ich bis jetzt gefunden habe stammen aus dem Programming-Guide.
Hab hier mal die wichtigen Bilder rauskopiert.

Dabei kommt dann sowas wie "wenn ein UDT in einem optimierten DB angelegt ist, sind die Daten im UDT nicht optmiert, aber Big-Endian,

1. Hab jetzt schon in ein paar Beiträgen gelesen dass die Speicherbelegung bei UDT und Struct unterschiedlich sein soll. Hat da jemand eine Quelle für mich?
2. Bist du dir sicher dass die UDT-Daten beim opt. DB als BIG-Endian liegen? Dann währe ja jeder UDT ein Performance-Problem. Kann ich eigentlich nicht glauben.

bei einer Struct in einem optimierten DB sind die Daten optimiert.

Sind die dann optimiert im Sinne von Speicherplatz-Optimiert oder im Sinne von Little-Endian?

In einem nicht optimierten DB sind die Daten aber als Little-Endian abgelegt" heraus (ich weiß immer noch nicht ob das richtig ist).

Nein, im optimierten DB als Little-Endian (Siehe Grafik) und im nicht optimierten als Big-Endian.
(Ich nehm mal an das wahr ein Tippfehler )

Ich kann mir aber nicht wirklich vorstellen das in einem opt. DB (ob UDT oder STRUCT) irgendwelche Daten in Big-Endian abgelegt werden.
Das wäre ja im Sinne der "optimierter DB - Performance - Lobhudelei" ja völlig schwachsinnig.

Da fällt mir noch was ein.
Wenn man es genau betrachtet waren auch schon die Dbs der 300/400 optimiert. Nur eben auf die 300/400-CPU mit Big-Endian.

@Thomas. Wie würdest du das einschätzen?
Ich denke nicht dass die Speicherplatz-optimierte Anordnung (jetzt nicht bezogen auf UDT/STRUCT etc.), so wie es der opt. DB macht, wirklich viel mit dem Performance-Gewinn zu tun hat.
Wenn dann nur marginal. Der meiste Gewinn kommt davon dass der Prozessor nicht Bytes drehen muss (90%).

Insofern könnte man (böswillig) sagen dass es eigentlich kein Performance-Gewinn ist, sondern einfach kein Performance-Verlust weil mann ein nicht-für-Big-Endian-optimiertes System verwendet.

 

[TSI09]

Hallo,

Danke für eure rege Anteilnahme an meiner Frage.
Verwendet von euch schon jemand den optimierten Bausteinzugriff für die S7-1500.
Wenn ja habt ihr irgendwelche Probleme festgestellt?

Lg

Markus