Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Seite 2 von 2 ErsteErste 12
Ergebnis 11 bis 17 von 17

Thema: S7 Kommunikation von S7-1500 auf S7-300

  1. #11
    Registriert seit
    22.11.2006
    Ort
    CH
    Beiträge
    3.635
    Danke
    786
    Erhielt 654 Danke für 497 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von Thomas_v2.1 Beitrag anzeigen
    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é

  2. #12
    Registriert seit
    27.05.2004
    Ort
    Thüringen/Berlin
    Beiträge
    12.255
    Danke
    537
    Erhielt 2.705 Danke für 1.954 Beiträge

    Standard

    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?
    Gruß
    Ralle

    ... there\'re 10 kinds of people ... those who understand binaries and those who don\'t …
    and the third kinds of people … those who love TIA-Portal

  3. Folgende 2 Benutzer sagen Danke zu Ralle für den nützlichen Beitrag:

    corrado (21.12.2015),rostiger Nagel (17.12.2015)

  4. #13
    Registriert seit
    23.07.2009
    Ort
    Österreich
    Beiträge
    2.367
    Danke
    457
    Erhielt 696 Danke für 521 Beiträge

    Standard

    Zitat Zitat von Thomas_v2.1 Beitrag anzeigen
    Ich steige da noch nicht so ganz durch.
    Da schließe ich mich gleich an.

    Zitat Zitat von vollmi Beitrag anzeigen
    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.
    Geändert von RONIN (12.02.2016 um 20:39 Uhr)
    If at first you don't succeed, you're not Van Damme!
    ... or maybe using TIA!

  5. #14
    Registriert seit
    23.07.2009
    Ort
    Österreich
    Beiträge
    2.367
    Danke
    457
    Erhielt 696 Danke für 521 Beiträge

    Standard

    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....?
    If at first you don't succeed, you're not Van Damme!
    ... or maybe using TIA!

  6. #15
    Registriert seit
    29.03.2004
    Beiträge
    5.792
    Danke
    144
    Erhielt 1.706 Danke für 1.238 Beiträge

    Standard

    Zitat Zitat von RONIN Beitrag anzeigen
    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).

  7. #16
    Registriert seit
    23.07.2009
    Ort
    Österreich
    Beiträge
    2.367
    Danke
    457
    Erhielt 696 Danke für 521 Beiträge

    Standard

    Zitat Zitat von Thomas_v2.1 Beitrag anzeigen
    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.
    TIA_Grafik_OptimierteDatenablage.jpg
    Zitat Zitat von Thomas_v2.1 Beitrag anzeigen
    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.

    Zitat Zitat von Thomas_v2.1 Beitrag anzeigen
    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?
    Zitat Zitat von Thomas_v2.1 Beitrag anzeigen
    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.
    Geändert von RONIN (17.12.2015 um 22:46 Uhr)
    If at first you don't succeed, you're not Van Damme!
    ... or maybe using TIA!

  8. #17
    TSI09 ist offline Benutzer
    Themenstarter
    Registriert seit
    13.01.2009
    Beiträge
    54
    Danke
    4
    Erhielt 0 Danke für 0 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    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

Ähnliche Themen

  1. Kommunikation Profi-Net , Ethernet 1500 -> 300
    Von Bananenbier im Forum Feldbusse
    Antworten: 2
    Letzter Beitrag: 26.06.2015, 18:37
  2. TIA Migrieren von SFC24 von S7-300 zu 1500
    Von Goeky im Forum Simatic
    Antworten: 2
    Letzter Beitrag: 10.06.2015, 16:58
  3. Antworten: 6
    Letzter Beitrag: 24.02.2015, 14:21
  4. TIA Verbindung S7 1500 zu S7 300
    Von GS-Harri im Forum Simatic
    Antworten: 22
    Letzter Beitrag: 08.08.2014, 11:04
  5. Antworten: 19
    Letzter Beitrag: 14.07.2014, 14:02

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •