TIA TIA V15.1.0.2 ist verfügbar

[Onkel Dagobert]

Zuviel Werbung?
-> Hier kostenlos registrieren

Nun funktioniert etwas, und es ist auch wieder nicht richtig . Möglicherweise habe ich Dummchen es auch nur falsch verstanden und es ist doch erst mit der V15.1 Upd.3 richtig falsch?

 

[Blockmove]

Die Geschichte mit Move hab ich auch nicht begriffen.
Hab bislang keine Fehlermeldung bekommen.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

ReadMe_TIAPUPDATE3_deDE.pdf (167,1 KB)

Verbesserungen in STEP 7
2.1 Verbesserungen in Update 3

Anweisung MOVE

Mit der Anweisung MOVE können Sie nur dann Werte zwischen Datenbausteinen kopieren, wenn beide Datenbausteine dieselbe Remanenzeinstellung ("remanent" oder "nichtremanent") haben. Ist diese Voraussetzung nicht erfüllt oder hat einer der beiden Datenbausteine individuelle Remanenzeinstellungen für einzelne Variablen, ist das Kopieren nicht möglich.​

Ich kann nicht glauben, daß Siemens wirklich das meint was da steht. Ich glaube, daß da ein Sachverhalt total sinnentstellend verkürzt erklärt wird (die englische Version des ReadMe-Dokuments schreibt allerdings das Gleiche). Vielleicht bezieht sich das nur auf die spezielle Möglichkeit, mit MOVE Strukturen/zusammengesetzte Datentypen/UDT zu kopieren, wo der Compiler (oder die Compiler-Bauer) möglicherweise nicht mit klarkommen, wenn für Teile der Quell- und Ziel-Strukturen unterschiedliche Remanenz-Einstellungen vorkommen und die Teile in verschiedenen Speichern liegen könnten? Und um nicht hinschreiben zu müssen, daß der Compiler aktuell zu doof ist und manchmal falschen Code erzeugt, wird einfach solches Kopieren (in FUP/KOP) generell verboten...?

Oder sollte das genau so eine ungenügend durchdachte Schnapsidee sein, wie das nicht Aufrufen eines Bausteins, wenn bei der Parameterversorgung eine Peripherieadresse nicht erreichbar ist? (was bekanntlich später wieder verworfen wurde)

Die MOVE-Anweisung gibt es nur in FUP und KOP und sie ist da DIE Kopieranweisung schlechthin. Warum sollte es nur in FUP/KOP nicht möglich sein, zwischen DB mit unterschiedlichen Remanenz-Einstellungen zu kopieren? Welche Anweisung soll man anstatt MOVE verwenden, wenn man das tun will/muß? Warum überhaupt soll das Kopieren nicht möglich sein? Sind nur die FUP/KOP-Compiler zu doof und die SCL- und AWL-Compiler können korrekten Code zum Kopieren erzeugen?

Ich weiß nicht was an der Aussage der wahre Kern ist, doch ich überlege mir die Konsequenzen, falls das wirklich so stimmen sollte... Mir fallen viele Beispiele ein, wo es absurd wäre, falls der MOVE tatsächlich nicht möglich wäre. Und von daher kann ich nicht glauben, daß die Aussage wahr/korrekt ist.

Harald

 

[DeltaMikeAir]

Ich kann nicht glauben, daß Siemens wirklich das meint was da steht.

Ja, glauben und verlassen fällt da schwer, vor allem weil man nie weiß, ob das mit dem nächsten Update wieder entfernt wird...

Und wie die Erfahrung gezeigt hat, bringen ja die die meisten Updates "Verbesserungen", dafür gehen bestehende Funktionen nicht mehr.
Da fragt man sich natürlich schon, warum soll man ein Update eigentlich installieren??

 

[hucki]

Ich kann nicht glauben, daß Siemens wirklich das meint was da steht. Ich glaube, daß da ein Sachverhalt total sinnentstellend verkürzt erklärt wird

Das ist IMHO der Hinweis, dass da das Kopieren schon in früheren Versionen u.U. nicht möglich bzw. nicht korrekt war.

Das Neue mit Update 3 sollte der Satz unter der von Harald zitierten Passage sein:

Im Update 3 wurde eine strengere Syntaxprüfung dazu eingeführt. Sie werden nun beim Übersetzen durch eine Meldung darauf hingewiesen, wenn ein Kopiervorgang nicht möglich ist.

 

[rostiger Nagel]

Zuviel Werbung?
-> Hier kostenlos registrieren

Schön wäre es, wenn Siemens einfach dabei schreiben würde, wo die MOVE Funktion
Fehler verursachen könnte, so könnte man selber entscheiden ob es für einen Relevant
ist.

 

[ducati]

Ja, glauben und verlassen fällt da schwer, vor allem weil man nie weiß, ob das mit dem nächsten Update wieder entfernt wird...

Und wie die Erfahrung gezeigt hat, bringen ja die die meisten Updates "Verbesserungen", dafür gehen bestehende Funktionen nicht mehr.
Da fragt man sich natürlich schon, warum soll man ein Update eigentlich installieren??

Kommt halt immer drauf an, was man macht und welche Ansprüche man hat. Es kommt doch auch in unserer Branche die Smartphonementalität auf, dass die Steuerung nur so nen bissl funktionieren muss und dann ist gut.

Blöd nur, wenn man dann doch mal wichtige Anlagen bauen muss, wo mit größerem finanziellen oder personellen Schaden zu rechnen ist...

Unsere Strategie: wir installieren KEINE Updates. Aktuell arbeiten wir mit V13.0.1.9 und diese Version ist in allen Anlagen seit mehreren Jahren. Da kennen wir die für uns relevanten die Macken, z.B. den PEW Bug und umgehen die. Ansonsten haben wir noch ein par ältere Panels mit V12.0.1.0

Wenn wir mal irgendwann auf ne neuere Version umsteigen (müssen) wird die Version mit der ersten Anlage eingefroren und bis auf weiteres für alles neue verwendet. Bestandsanlagen werden nicht hochgerüstet. Ansonsten verwenden wir von den ganzen tollen neuen Funktionen (Programmalarm, OPC, Webserver, optimierte DBs usw. ) eher NICHTS. Ja wir verwenden sogar AWL, S5-Timer oder manchmal Merker . Und komischerweise fahren wir ganz gut mit dieser Strategie.

Gruß.

 

[DeltaMikeAir]

Ansonsten verwenden wir von den ganzen tollen neuen Funktionen (...Webserver...)

Ja,das stimmt allerdings. Siemens empfiehlt ja aktuell selber, den Webserver sicht zu verwenden, da ein FW-Bug drin ist
und die CPU unter bestimmten Bedingungen auf Stop geht :-(

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Zu der MOVE-Verbesserung habe ich mal einen Service Request erstellt. Mal sehen was da für eine Erklärung kommt.

Harald

 

[s7Opa]

Moin,

ich versuche ja Daten aus dem Ladespeicher mit READ_DBL zu laden. Das Programm lief, bzw. läuft vor dem Update stabil.
Ich habe auf 15.1.3 hochgerüstet und auch das letzte Update für PLCSim durchgeführt.
Das Programm läuft nicht an, selbst wenn die READ_DBL Aufrufe aus dem Ablauf "ausgenoppt" sind und geht sofort auf Fehler.


An den REQ Variablen liegt es nicht. Wenn ich die ARRAY Indexvariable duch eine Absolutzahl ersetze ist es ok und er hängt
an dem nächsten Aufruf von READ_DBL.
Die Remanenzeinstellung ändert nichts, habe mehrere Möglichkeiten ausprobiert. (Warum SD Daten als Remanent setzen?)

 

[Thomas_v2.1]

Vielleicht bezieht sich das nur auf die spezielle Möglichkeit, mit MOVE Strukturen/zusammengesetzte Datentypen/UDT zu kopieren, wo der Compiler (oder die Compiler-Bauer) möglicherweise nicht mit klarkommen, wenn für Teile der Quell- und Ziel-Strukturen unterschiedliche Remanenz-Einstellungen vorkommen und die Teile in verschiedenen Speichern liegen könnten?

Das war auch meine erste Vermutung da die Variablen dann nicht mehr hintereinander im Speicher liegen würden. Allerdings lassen sich zumindest bis V14 keine einzelnen Elemente einer Struktur bezügl. Remanenz unterschiedlich einstellen. Es ist immer die gesamte Struktur mit allen Variablen entweder nicht remanent oder remanent.

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin,

ich versuche ja Daten aus dem Ladespeicher mit READ_DBL zu laden. Das Programm lief, bzw. läuft vor dem Update stabil.
Ich habe auf 15.1.3 hochgerüstet und auch das letzte Update für PLCSim durchgeführt.
Das Programm läuft nicht an, selbst wenn die READ_DBL Aufrufe aus dem Ablauf "ausgenoppt" sind und geht sofort auf Fehler.
Anhang anzeigen 46835

An den REQ Variablen liegt es nicht. Wenn ich die ARRAY Indexvariable duch eine Absolutzahl ersetze ist es ok und er hängt
an dem nächsten Aufruf von READ_DBL.
Die Remanenzeinstellung ändert nichts, habe mehrere Möglichkeiten ausprobiert. (Warum SD Daten als Remanent setzen?)

Naja, um das mal einzugrenzen, solltest Du das mal auf ner realen Steuerung testen. PLCSIM macht schon immer mal was anderes...
im übrigen hast Du sicherlich V15.1.0.3 (Version.Unterversion.Servicepack.Update)

Gruß.

 

[Jochen Kühner]

Das war auch meine erste Vermutung da die Variablen dann nicht mehr hintereinander im Speicher liegen würden. Allerdings lassen sich zumindest bis V14 keine einzelnen Elemente einer Struktur bezügl. Remanenz unterschiedlich einstellen. Es ist immer die gesamte Struktur mit allen Variablen entweder nicht remanent oder remanent.

In 15.1 ist das immer noch so

 

[s7Opa]

Naja, um das mal einzugrenzen, solltest Du das mal auf ner realen Steuerung testen. PLCSIM macht schon immer mal was anderes...
im übrigen hast Du sicherlich V15.1.0.3 (Version.Unterversion.Servicepack.Update)

V15.1.0.3 richtig!
Ich habe das Projekt vor dem Update auf die neue Steuerung (Maschine in der Halle) geladen. Läuft rund!
Da ich keine Hardware zur Hand habe werde ich ein Teufel tun und die Maschine mit UP3 >>fehlerei<<, übersetzten Projekt zu überschreiben.
Ich habe nun mal wieder Stunden damit verbracht einen Fehler zu finden, den Servicesupport zu unterrichten usw. usw. Wer zahlt das?

Irgendwo muss Schluss sein. Ich warte mal auf den Support und kann nur hoffen, auch das ist möglich, nicht mir selbst ins Knie geschossen zu haben.

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

V15.1.0.3 richtig!
Ich habe das Projekt vor dem Update auf die neue Steuerung (Maschine in der Halle) geladen. Läuft rund!
Da ich keine Hardware zur Hand habe werde ich ein Teufel tun und die Maschine mit UP3 >>fehlerei<<, übersetzten Projekt zu überschreiben.
Ich habe nun mal wieder Stunden damit verbracht einen Fehler zu finden, den Servicesupport zu unterrichten usw. usw. Wer zahlt das?

Irgendwo muss Schluss sein. Ich warte mal auf den Support und kann nur hoffen, auch das ist möglich, nicht mir selbst ins Knie geschossen zu haben.

Ja natürlich NICHT an der Produktivanlage testen

aber ne 1200er kostet ja nicht die Welt, wenn man da abundzu was macht, legt man sich halt ne gängige Teststeuerung ins Büro. Hab hier auch immer ne 315, ne 1515 und ne 1510 rumliegen...

Gruß.

 

[PN/DP]

Zu der MOVE-Verbesserung habe ich mal einen Service Request erstellt.

Vorläufige Entwarnung! Da ist tatsächlich was falsch formuliert. MOVE funktioniert doch auch bei unterschiedlichen Remanenzeinstellungen.

Antwort auf den Support Request vom Siemens Technical Support für Industry Automation und Drives Technology:

Tatsächlich kann ich die Aussage der Readme ebenfalls nicht bestätigen.
Die MOVE Anweisung funktioniert auch bei unterschiedlichen Remanenzeinstellungen.

Für die Klärung der Thematik und gegebenenfalls Anpassung der Dokumentation werde ich die Entwicklung hinzuziehen.

Über den Fortgang der Untersuchung werden wir Sie auf dem Laufenden halten.

Harald

 

[Thomas_v2.1]

Na wollen wir mal hoffen, dass jetzt nicht die Software der Beschreibung angepasst wird und der MOVE dann nicht mehr funktioniert.

 

[Onkel Dagobert]

Zuviel Werbung?
-> Hier kostenlos registrieren

Dann kann ich mir schon denken, wie es gelaufen ist. Die Praktikantin, welche für die Dokumentation verantwortlich war, hatte ganz einfach die Begriffe "optimiert" und "remanent" verwechselt. Wahrscheinlich hatte die Gute mal wieder andere Dinge im Kopf.​

 

[Nano.v1]

Naja anstelle eines Move könnten wir dann ja eine Addition mit 0 durchführen, kommt aufs selbe aber ist kein MOVE ROFLMAO

 

[hucki]

Naja anstelle eines Move könnten wir dann ja eine Addition mit 0 durchführen, kommt aufs selbe aber ist kein MOVE

Glaub' nicht, dass nur Zahlen verschoben werden.