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

Seite 3 von 4 ErsteErste 1234 LetzteLetzte
Ergebnis 21 bis 30 von 32

Thema: merkwürdiges(?) Verhalten Schnittstelle OUT

  1. #21
    Registriert seit
    03.02.2015
    Ort
    Hatten
    Beiträge
    183
    Danke
    16
    Erhielt 32 Danke für 29 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Kann ich so nachvollziehen, allerdings nur für eine 300er CPU. Habe testweise das Gleiche auf einer simulierten 1500er laufen lassen: Hier gibt es diese Option nicht.

    @Lockenfrosch: Nochmal kurz die Frage: Wie kommst Du an den AWL-Code?

  2. #22
    Registriert seit
    03.02.2015
    Ort
    Hatten
    Beiträge
    183
    Danke
    16
    Erhielt 32 Danke für 29 Beiträge

    Standard

    --- versehentlicher Doppelpost ---
    Geändert von JSEngineering (03.02.2015 um 12:50 Uhr)

  3. #23
    Registriert seit
    23.01.2006
    Beiträge
    75
    Danke
    17
    Erhielt 7 Danke für 4 Beiträge

    Standard

    Zitat Zitat von JSEngineering Beitrag anzeigen
    Kann ich so nachvollziehen, allerdings nur für eine 300er CPU. Habe testweise das Gleiche auf einer simulierten 1500er laufen lassen: Hier gibt es diese Option nicht.

    @Lockenfrosch: Nochmal kurz die Frage: Wie kommst Du an den AWL-Code?
    Mit dem old school Step7 vom AG runtergeladen.

  4. Folgender Benutzer sagt Danke zu Lockenfrosch für den nützlichen Beitrag:

    JSEngineering (03.02.2015)

  5. #24
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.166
    Danke
    921
    Erhielt 3.286 Danke für 2.655 Beiträge

    Standard

    Ich vermute mal, er hat den unter TIA compilierten FC in eine 300er CPU geladen und mit Step7 V5.x aus der CPU geladen und daraus eine AWL-Quelle erstellt. (so würde ich es jedenfalls machen, weil ich mit TIA fast keine Erfahrung habe)
    EDIT: zu langsam...

    Um das Problem zu sehen, muß man eine S7-300/400 nutzen, bei der S7-1500 sollen FC-Ausgänge anders übergeben werden. Wie Hellebarde in seinem Beitrag andeutete. Ich meine, dazu steht was in diesem Programmierleitfaden für S7-1200/1500. Doch Vorsicht: je nach Ausgabe des Dokuments sind da viele verschiedene falsche Ausführungen enthalten Trotzdem sollte man da ab und zu 'reinsehen, um zu wissen, welche überraschenden "Innovationen" Siemens sich einfallen läßt oder welche Bugs als Feature erklärt werden (z.B. daß man in SCL in FOR-Schleifen den Schleifenzähler nicht mehr verändern kann)

    Harald
    Es ist immer wieder überraschend, wie etwas plötzlich funktioniert, sobald man alles richtig macht.

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  6. #25
    Registriert seit
    29.03.2004
    Beiträge
    5.731
    Danke
    143
    Erhielt 1.685 Danke für 1.225 Beiträge

    Standard

    Um an den AWL-Code zu kommen kann man auch den Weg über Plcsim gehen. D.h. mit TIA in Plcsim reinladen, und mit Step7 wieder rausladen. Zum Glück hat man bei den 300/400ern noch die Möglichkeit sich anzusehen was Siemens da verbockt und denen das unter die Nase zu reiben. Bei den 1200/1500 sieht das ganz duster aus, und dort werden wohl eher mehr als weniger Fehler drinstecken. Dann werden solche elementaren Bugs klammheimlich mit einem kleinen Update ohne konkrete Beschreibung gefixt.

  7. #26
    Registriert seit
    13.10.2007
    Beiträge
    12.027
    Danke
    2.784
    Erhielt 3.268 Danke für 2.156 Beiträge

    Standard

    Zitat Zitat von Thomas_v2.1 Beitrag anzeigen
    Um an den AWL-Code zu kommen kann man auch den Weg über Plcsim gehen. D.h. mit TIA in Plcsim reinladen, und mit Step7 wieder rausladen. Zum Glück hat man bei den 300/400ern noch die Möglichkeit sich anzusehen was Siemens da verbockt und denen das unter die Nase zu reiben. Bei den 1200/1500 sieht das ganz duster aus, und dort werden wohl eher mehr als weniger Fehler drinstecken. Dann werden solche elementaren Bugs klammheimlich mit einem kleinen Update ohne konkrete Beschreibung gefixt.
    Warte mal auf den nächsten SP

    Zitat Zitat von rostiger Nagel Beitrag anzeigen
    lass das bloß nicht Siemens hören, sonst sieht der nächste Servicepack so aus:

    Anhang 27281
    - - -
    Wer als Werkzeug nur einen Hammer hat, sieht in jedem Problem einen Nagel.

  8. #27
    Registriert seit
    24.04.2013
    Beiträge
    309
    Danke
    23
    Erhielt 160 Danke für 88 Beiträge

    Standard

    Hi all

    das ist ja wieder mal ein Hammer. Ich betrachte die Stellen die PN/DP identifiziert hat als fehlerhaft. Aus Sicht eines übereifrigen Optimierers sind sie allerdings in Ordnung. Mein studierter Sohn nennt sowas Valuepropagation. Das meint, dass die Werte, die ermittelt wurden weitergeben werden, und nicht abermals bestimmt werden müssen. Also z.B.
    Code:
    a := 3*sin(b)+2*cos(c);
    d := 3*sin(b)+2*cos(c)+e;
    Wird dann von einem Optimierer in
    Code:
    a := 3*sin(b)+2*cos(c);
    d := a+e;
    gewandelt. Jeder GCC macht sowas. Dauernd. Drum ist der Code dort ja auch viel schneller wie der von Siemens Ok, das ist unfair. Wenn der GCC Code für ein System machen müsste in dem man während es läuft Funktionen austauschen will, dann ist dort auch ziemlich schnell Essig mit vielen Optimierungen die den Code schnell machen.

    Der Zugriff auf #out0 ist kürzer als der auf #temp4.temp5. Für #out0 wird der von mir oben beschriebene kurze Zeiger dereferenziert. Das können 300 und 400 recht schnell. Für #temp4.temp5 muss der L-Stack addressiert werden. Also zuerstmal #temp4 und dann darin temp5. Das ist länger. ABER - schließlich landet man aber trotzdem bei einer einzigen festen Adresse im L. D.h. sowohl #out0 als auch #temp4.temp5 sollten genauso schnell addressiert werden.

    Von der äußeren Beschaltung weiß der Optimierer nichts. Jeder Baustein wird völlig ohne Wissen aller anderen Bausteine übersetzt. So war das bei der 300/400 schon immer, schließlich kann man da ja auch jeden Baustein einzeln ohne irgendwelche Konsistenz sichernde Maßnahmen auf die AS schicken. Und schon steht die Anlage.

    Mit der Versorgung hat Lockenkopf den Optimierer reingelegt.

    Was lernen wir daraus.
    1) Schreib keine Funktionen mir Ausgängen die man nicht braucht.
    2) Wenn man diese Funktion aber zugeliefert bekommt, dann versorge jeden Ausgang mit etwas anderem.

    'n schön' Tach auch
    HB

    Trotzdem hat Siemens hier eindeutig Mist gebaut.

  9. #28
    Registriert seit
    16.10.2012
    Beiträge
    737
    Danke
    51
    Erhielt 34 Danke für 28 Beiträge

    Standard

    Also ganz ehrlich ich verstehs immer noch nicht. Aus meiner Sicht müsste auch der AWL Code der da rauskommt trotz Optimierungen noch laufen. Es ist ja eben so wie HelleBarde schreibt:
    Von der äußeren Beschaltung weiß der Optimierer nichts. Jeder Baustein wird völlig ohne Wissen aller anderen Bausteine übersetzt. So war das bei der 300/400 schon immer, schließlich kann man da ja auch jeden Baustein einzeln ohne irgendwelche Konsistenz sichernde Maßnahmen auf die AS schicken. Und schon steht die Anlage.
    Was is da also faul frage ich mich

  10. #29
    Registriert seit
    24.04.2013
    Beiträge
    309
    Danke
    23
    Erhielt 160 Danke für 88 Beiträge

    Standard

    Hi nochmal

    was ich bisher über die 1200 weiß ist die Parameterübergabe dort ganz anders als bei der 300/400. Der 1200 haben wir ja schon etwas unter den Rock geschaut Dem Verhalten nach ist es bei der 1500 so wie bei der 1200, aber die lässt sich nicht unter den Rock schauen, die hat Hosen an

    Also Parameterübergabe bei einem FC auf der 1200:

    Auch hier muss man wieder zwischen den einfachen (BOOL bis LREAL) und den komplizierten (String, Array, Struct) Datentypen unterscheiden. Einfache Datentypen zeigen ein Call-By-Value Verhalten, komplizierte Datentypen zeigen ein Call-By-Referenz Verhalten.

    Es gibt bei der 1200 drei L-Bereiche, nicht nur einen wie bei der 300/400. L ist ein Stack, d.h. für jede FC und jeden FB wird vor dem Aufruf ein Stackframe angelegt. In diesem Rahmen darf der Baustein addressieren. Den L-Stack der 300/400 gibt es auch bei der 1200. Aber was sind die anderen beiden? Neben dem L gibt es noch einen L'. Bei einem nicht optimierten Baustein, landen die Tempvariablen auf dem L. Bei einem optimierten Baustein landen die Temp auf dem L'. Der Unterschied zwischen L und L' liegt darin, wie die Variablen dort landen. Bei L ist es wie auf der 300/400. Bei L' liegen die Variablen "vernünftiger".
    Code:
                       L            L'
    a : BOOL       0.0         8.0
    b : LREAL      2.0         0.0
    Was soll da jetzt "vernünftig" sein? Naja, ich zitiere meinen Studierten: "Beim 64Bit-Zugriff auf 2.0 bekommt ein 32Bit Prozessor das kotzen". Drastisch aber klar. Noch ein Zitat: "Das habt ihr jetzt davon, dass ihr immer nach Adressen fragt und selber meint besser zu wissen wo das Bit zuliegen kommen soll" ...

    Bei den DB gibt es diese Unterschiede auch. So bin ich überhaupt dahintergekommen. Wenn man mehrere Variablen im DB hat mit auffälligen Werten, kann man die beim Laden im Wireshark gut deren Muster beobachten. Aber zurück zum L und der Parameterübergabe.

    So wir haben Bereich 1 für L und Bereich 2 für den optimierten L'. Der dritte Bereich ist der für die Parameter. Auch diese scheinen nach Größe sortiert und optimiert auf dem Stack zu liegen. Sehen kann man den Bereich des Stacks nicht -- ich zumindest Aber das interessiert ja auch nicht, sondern wie es sich verhält. Und es verhält sich so wie eine Kopie.

    Egal womit man einen einfachen Typen versorgt, ob E A M Temp oder aus einen DB und sogar bei Peripherie, wenn man einen INOUT hat, werden die Werte vor dem eigentlichen Aufruf in diesen Parameterbereich kopiert und nach dem Aufruf wieder zurück. Bei PE klappt das mit einem INOUT natürlich nicht. Man bekommt einen Fehler, nach dem der Baustein ausgeführt würde. Bei PA klappt ja schon das Lesen nicht also bekommt man den Fehler schon vor dem eigentlichen Aufruf, der Baustein wird gar nicht erst ausgeführt.

    Die 1500 verhält sich genauso. Diese Verhalten finde ich insgesammt deutlich logischer als bei der 300/400, besonders wegen P, siehe oben.

    Genug geschwafelt

    'n schön' Tach auch
    HB

  11. Folgende 3 Benutzer sagen Danke zu HelleBarde für den nützlichen Beitrag:

    Joe (05.02.2015),Lockenfrosch (20.02.2017),RONIN (04.02.2015)

  12. #30
    Registriert seit
    24.04.2013
    Beiträge
    309
    Danke
    23
    Erhielt 160 Danke für 88 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von Draco Malfoy Beitrag anzeigen
    Also ganz ehrlich ich verstehs immer noch nicht. Aus meiner Sicht müsste auch der AWL Code der da rauskommt trotz Optimierungen noch laufen. Es ist ja eben so wie HelleBarde schreibt:

    Was is da also faul frage ich mich

    Ich schrieb, dass bei 300/400 alle FC Parameter per Referenz mittels kurzem 32Bit Zeiger übergeben werden.
    Dank Lockenkopfs Wiederverwendung zeigen alle drei #out auf die selbe Adresse.
    D.h. egal welchen #outX du schreibst, es ist immer der selbe Speicher.
    Wegen der übereifrigen Valuepropagation, wird beim zweiten Zugriff eben nicht der eigentlich richtige #tempY.tempZ gelesen sondern der richtige #outX-Zeiger verwendet, der aber dank Lockenkopfs "Geiz" eben doch nur ein Speicherplatz ist.

    Klar wie Kloßbrühe

    HB

Ähnliche Themen

  1. Merkwürdiges beim Referenzdaten Erzeugen
    Von Werner v. Siemens im Forum Simatic
    Antworten: 5
    Letzter Beitrag: 27.10.2008, 09:54
  2. Merkwürdiges Problem
    Von zwerg77 im Forum Simatic
    Antworten: 5
    Letzter Beitrag: 27.11.2007, 13:15
  3. Merkwürdiges Profibus Problem ?!
    Von dietere im Forum Feldbusse
    Antworten: 5
    Letzter Beitrag: 07.11.2007, 11:42
  4. merkwürdiges phänomen ?
    Von volker im Forum Simatic
    Antworten: 10
    Letzter Beitrag: 27.09.2006, 08:40
  5. Antworten: 2
    Letzter Beitrag: 21.12.2005, 14:29

Lesezeichen

Berechtigungen

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