TIA und Step7 erzeugen unterschiedliche Array-Offsets?

[LowLevelMahn]

Zuviel Werbung?
-> Hier kostenlos registrieren

wiso?

das sieht doch OK aus - ein String[3] ist 5 Bytes lang - und bei dir ist das auch so, und genau so auch in Step7

BOOL 0.0 -> kein alignment, size = 1 bit => OK
STRING[3] 2.0 -> strings werden word aligned, size = string[3]=5 bytes => OK
BYTE 7.0 -> byte wird bytealigned, size = 1 byte => OK
INT 8.0 -> wird word aligned size = 2 bytes => OK
BYTE 10.0 -> wird byte aligned, size = 1 byte => OK
INT 12.0 -> wird word aligned, size = 2 byte => OK

 

[IBFS]

das sieht doch OK aus - ein String[3] is 5 Bytes lang - und bei dir ist das auch so, und genau so auch in Step7

.. bei mir belegt in STEP7 Classic ein STRING[3] SECHS Byte

und ein ARRY[0..1] of STRING[3] ZWÖLF Byte!

NUR wenn danach ein reines BYTE kommt füllt das den Rest auf, aber natürlich nicht beim ARRAY, denn dort bleibt das 6te Byte unbelegt

Frank

 

[LowLevelMahn]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wie jetzt ... bei mir belegt in STEP7 Classic ein STRING[3] SECHS Byte

in Arrays - aber nicht wenn freistehend - wie gesagt es ist nicht ganz so trivial und bedenke das du das Alignment nicht siehst

schreib mal

BOOL bit1
STRING[3]
BOOL bit2
ARRAY[1..2] of string[3]
BOOL bit3

dann siehst du die Längen besser - es gibt fuer alle Typen ein wenig anderes Verhalten

 

[MSB]

Ja muss meine Meinung wohl revidieren, ein klein wenig zumindestens, hatte nicht geahnt, das das bei Step7 auch schon so war.
Das ist dann wohl einer von wenigen Fällen wo das übliche Word-Alignment für den Allerwertesten ist.

Also ist das Problem:
Im Array hält sich TIA im Unterschied zu Step7 pro Feld an die 3 Byte Länge. Step7 macht hingegen im Array pro Feld 4 Bytes.

Wenn man das ganze jetzt mit den nicht-Array String vergleicht, ist eigentlich sogar eher Step7 fehlerhaft und TIA korrekt.

Mfg
Manuel

 

[IBFS]

dann siehst du die Längen besser - es gibt fuer alle Typen ein wenig anderes Verhalten

sei es wie es sei, aber ich will mir bei der Migration über solchen Unsinn keine Gedanken machen müssen.

Für echte NEUANFÄNGE ist die 1500er da, alles andere soll so bleiben wie es ist, sonst erleben wir in den nächsten 15 Jahren Parallelbetrieb noch viel mehr Chaos.

Frank

 

[LowLevelMahn]

Zuviel Werbung?
-> Hier kostenlos registrieren

wohl einer von wenigen Fällen wo das übliche Word-Alignment für den Allerwertesten ist

so "üblich" ist das Word-Alignment dann auch wieder nicht

Also ist das Problem:
Im Array hält sich TIA im Unterschied zu Step7 pro Feld an die 3 Byte Länge. Step7 macht hingegen im Array pro Feld 4 Bytes.

Wenn man das ganze jetzt mit den nicht-Array String vergleicht, ist eigentlich sogar eher Step7 fehlerhaft und TIA korrekt.

Zu kurz gedacht - komplexe Typen wie Arrays, Struct und Strings werden Word-Aligned (wegen der Performance)
wenn du jetzt bei String[3] nur die 5 statt die 6 nimmst ist nur der erste Index in dem Array Word-Aligned, der Rest nur noch
Byte-Aligned - also ist TIA falsch

Es macht gar keinen Sinn mit 50% Halbwissen+Vermutung irgendwelche Statements zu machen - die sind im Normalfall dann
einfach zu 100% falsch

 

[winnman]

Und nur 15 Jahre Parallelbetrieb halte ich für ein bisschen Kurzsichtig.

OK Parallelbetrieb :s11:, aber 300 und 400 wirds noch viel länger welche geben.

 

[MSB]

Zu kurz gedacht - komplexe Typen wie Arrays, Struct und Strings werden Word-Aligned (wegen der Performance)
wenn du jetzt bei String[3] nur die 5 statt die 6 nimmst ist nur der erste Index in dem Array Word-Aligned, der Rest nur noch
Byte-Aligned - also ist TIA falsch

Im Prinzip kannst du das jetzt drehen wie du willst, und es ist im Prinzip auch egal, nur sollte es identisch sein.

 

[LowLevelMahn]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich muss mich eben noch an euch SPSler gewöhnen

sei es wie es sei, aber ich will mir bei der Migration über solchen Unsinn keine Gedanken machen müssen.

Im Prinzip kannst du das jetzt drehen wie du willst, und es ist im Prinzip auch egal, nur sollte es identisch sein.

...

Ist das eigentlich normale SPSler Mentalität: Kurz 1-3 Posts voll in ein Fremdthema einsteigen und dann schnell wieder rausrudern - sowas sehe ich hier ständig

 

[IBFS]

...

Ist das eigentlich normale SPSler Mentalität: Kurz 1-3 Posts voll in ein Fremdthema einsteigen und dann schnell wieder rausrudern - sowas sehe ich hier ständig

Also ich habe 6 Beiträge geschrieben, aber egal ....

ich betrachte es nicht als meine Aufgabe haufenweise Fehler in einer REGULÄR für GELD gekauften Software nachzustellen. Mir reicht das, was in diesem Zusammenhang jetzt aufgefallen ist.

Wenn das ein BETA wäre oder ich mit einem externen SW-Test beauftragt wäre, dann von mir aus. Aber ich muss mit meiner Programmierarbeit Geld verdienen und ich bin es, der nachher dem Kunden

nur mit größer Mühe erklären könnte ---- Ich bin daran nicht schuld ----

Der Programmierer ist bei Maschinenfehlern immer Schuld. Wer damit nicht leben kann, soll Bäcker werden. Falls aber der Backautomat dann auch mit der V11 programmiert worden wäre, dann wäre selbst das nicht empfehlenswert.

Frank

 

[MSB]

Was heißt rausrudern?
Du kannst jetzt rabatz bei Siemens machen, evtl. hat man damit sogar Erfolg ... wer weiß das schon.
Evtl. kann man das, und das war ja wohl deine Intention, gemeinsam machen.

Ändern kann man das selbst ohnehin nicht, höchstens umgehen oder auf ein Hotfix warten.
Wobei sich dann im Gegenzug die Frage stellen würde, was diejenigen machen die neue Bausteine auf Basis TIA entwickelt haben.
Ganz allgemein sind Strings ja ein eher seltener Datentyp im SPS-Alltag.

Das jetzt nur ganz am Rande:
Bei Codesys hängts auch noch von der konkreten Zielplattform ab, wie das jeweilige Alignment ist ...

Mfg
Manuel

 

[rostiger Nagel]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ganz allgemein sind Strings ja ein eher seltener Datentyp im SPS-Alltag.

Hallo Manuel,
da möchte ich mal widersprechen, es wird mehr und mehr zum Alltag.
Datein jeglicher Art von übergeordneten Rechner Auslesen, zerlegen,
bearbeiten und zurückschreiben. Es kommt bei mir in letzter Zeit sehr häufig
vor, zur Zeit weiche ich da immer noch auf flex aus, ich hätte mir aber
gewünscht das TIA in Verbindung mit den neuen Steuerungen mehr bittet.

Aber wenn es mit den bestehenden Kram Classic <-> TIA nich klappt, was
will man dann noch erwarten.

 

[Perfektionist]

also, dann will auch ich noch hier reinspammen...

heißt das also, dass TIA eine für sich konsistente Lösung gefunden hat, die die für Classic konsistente Lösung ablöst?

also auf Deutsch: ich migriere ein Programm, der Output ist aber nicht 1:1 kompatibel? sprich: ich bin genötigt, dies Programm mit neuen DB-Strukturen neu zu übertragen, mit den üblichen Aktualdatenverlusten, die dabei auftreten können?

In den schönen bunten Prospekten zu 1500er habe ich gelesen, dass Portal-S7 nicht mehr auf Bit-Adressen setzt. Schon vor geraumer Zeit wurden für Bool-Variablen durchaus ganze Wörter genutzt, also alles, was verschieden war von 0 wurde als eins gewertet, mit Vorzug war -1 der Wert, der TRUE darstellte. Ich beziehe mich da, glaube ich zurecht, auf Turbo-Pascal.

Auch diesem Compiler konnte man damals mitteilen, ob er aligned oder not-aligned kompilieren sollte, wobei dabei die Zielplattform ausschlaggebend war, ob nun 8088 oder 8086.

 

[IBFS]

heißt das also, dass TIA eine für sich konsistente Lösung gefunden hat, die die für Classic konsistente Lösung ablöst?

Wie war doch gleich das Versprechen?

Eine mit Flex erstellte Visu (Nicht integriert) soll nach dem das STEP7-Classic-Partnerprojekt nach TIA migriert und in die CPU eingespielt wurde immer noch zusammenarbeiten können.

Ein mit STEP7 Classic erstelltes F-CPU-Projekt soll nach der Migration codekompatibel aus Sicht der CPU lauffähig sein?

Wie soll denn das bitte gehen, wenn da - ggf. unbeabsichtigt - an den Strukuren geschraubt wird.

Denkt mal bitte logisch nach und sucht nicht nach etwaigen Erklärungen, die nur die Fehler übertünchen.

Frank

 

[LowLevelMahn]

Zuviel Werbung?
-> Hier kostenlos registrieren

Nein ganz und gar nicht

heißt das also, dass TIA eine für sich konsistente Lösung gefunden hat, die die für Classic konsistente Lösung ablöst?

Nein - Es wurde ein funktionierendes und auch in der restlichen Softwarewelt richtiges Verhalten von Step7 nur zu 99,5% nach TIA portiert und leider eine Kleinigkeit vergessen
dadurch ändert sich in bestimmten Situation das Layout von 300/400 kompatiblen Datenblöcke - die sonst 100% kompatibel zu Step7 wären

diese Kleinigkeit kann ausser zu schwer nachvollziehbaren Fehlern auch zu Performanceverlust führen, für TIA gibt es 0 Vorteile, nur die Migration wird dadurch einfach gefährlicher, und ein anschauen des Dateblocks in Step7 führt dann zu obskuren Fehlern (als nette Resultat des TIA-Fehlers)
und dazu gibt es dann bei String-Zugriffen eine Mischung aus Word- und Byte-Alignment (was noch nie, auf keiner Hardware-Platform jemals richtig war und sein wird)

also auf Deutsch: ich migriere ein Programm, der Output ist aber nicht 1:1 kompatibel? sprich: ich bin genötigt, dies Programm mit neuen DB-Strukturen neu zu übertragen, mit den üblichen Aktualdatenverlusten, die dabei auftreten können?

Viel schlimmer (wenn du ein wenig lesen würdest) wenn du Anypointer-Zugriffe auf ein String-Arrays mit ungerader Stringlänge hast wird dieser Anypointer und ALLE Anypointer auf darunter liegende Daten falsch - und es gibt keine Warnung oder sonstige Meldung die dich darauf hinweisen - d.h. alle 300/400-Projekte die sowas machen können nach der Migration latente Fehler enthalten - und ja es gibt da draussen tausende Projekte die sowas machen - und ja die muss man auch mal irgendwann migrieren, und ja dieser unnötige Fehler hat nur Nachteile - sogar für Siemens

Die Migration baut auf die Kompatibilität der Datenblöcke - weil es definitiv keine Möglichkeit gibt den Anypointer-Zustand zu 100% zur Migrationszeit zu bestimmen - da sich Anypointer ja auch dynamisch zusammenbauen lassen

Schlamperei hat noch nie zu tollen Ergebnissen geführt - fehlende Systemtests leider auch nicht

 

[georg28]

Durchgängig wird TIA auch nieh werden.
Die Migration von einem OP77 von Flexibel nach WINCC V11 klappt gut und währe auch ok.
Da das OP77 in einem gewissen Zeitraum nicht mehr verfügbar ist bin ich auf den Nachfolger KP400.
Nachdem der Bediengerätetyp geändert war auf KP400, muß man wieder Hand anlegen um ein Brauchbares Projekt zu erhalten, genauso wie vorher bei OP7(Protool) auf OP77 (flexible).
NIcht nur wegen den Farben, auch Textfelder etc haben nicht gepasst, warum soll das mit einem SPS Programm anderst werden.
In TIA wird der absolute Zugríff auf ein Bit von einem Word von einem DB auch mit Warnung angezeigt. Arbeiten tut der Ablsolutzugriff schon.
In TIA ist halt die Denke nicht mehr absolut Adresierung oder Symbolisch wie bei S5 oder Step 7 Classic sondern nur Symbolisch. TIA ist halt eine neue Softwaregeneration und die Symbolische Programmierweise ist halt mehr IEC. Und Siemens will sich halt der IEC annähern. Man wird leider halt nicht herumkommen wenn man ein Projekt mit TiA macht gewisse Sachen abändern zu müssen da diese nach einer Migration nicht mehr funktionieren.

 

[IBFS]

In TIA wird der absolute Zugríff auf ein Bit von einem Word von einem DB auch mit Warnung angezeigt. Arbeiten tut der Ablsolutzugriff schon.
In TIA ist halt die Denke nicht mehr absolut Adresierung oder Symbolisch wie bei S5 oder Step 7 Classic sondern nur Symbolisch.

bei CPU-Serien mit der Möglichkeiten der optimierten DBs (1200/1500) können sie intern optimieren soviel sie vollen, da kann sich SIEMENS austoben, damit habe ich kein Problem.

In TIA wird der absolute Zugríff auf ein Bit von einem Word von einem DB auch mit Warnung angezeigt.

Nenn es Hinweis ... eine Warnung ohne konkrete Warnung ist keine Warnung

Arbeiten tut der Absolutzugriff schon.

Er fasst nur, wie wir sehen ins falsche Nest UND

DBs werden - durch Pseudooptimierung (wie ihr es nennt) ich nenne es Fehler - KÜRZER!!!! in TIA

TIA ist halt eine neue Softwaregeneration und die Symbolische Programmierweise ist halt mehr IEC. Und Siemens will sich halt der IEC annähern.

Solange man nicht erfährt, was ist der SOLLZUSTAND und was ist ein Fehler geht sowass nicht!

Man wird leider halt nicht herumkommen wenn man ein Projekt mit TiA macht gewisse Sachen abändern zu müssen da diese nach einer Migration nicht mehr funktionieren.

Lies mal #34: http://www.sps-forum.de/showthread....schiedliche-Array-Offsets?p=428787#post428787

Es ist außer - bei SCL, würde ich es gerade noch verstehen (Klammertypen) - einfach nicht praktikel Fehler oder etwaige Veränderungen zu suchen, die nicht als solche bei der Migration zu erkennen sind.

AUSSERDEM:

Stell dir mal das Szenario vor, den Programm läuft nach der Migration und die fällt ein, einen Baustein aus STEP7 (schön gefüllt mit Anypointer-Sachen) nachträglich ins TIA zu bringen, zum bsp. als LIB-Projekt.
Da kommen keine Fehler bei der Migration dieser Bausteinsammlung. Im Ergebnis werden dann einzelne Bausteine nicht mehr in TIA funktionen. Wie gesagt, wir reden von TIA mit S7-300/400 NICHT der 1500.

Grüße

Frank

 

[LowLevelMahn]

Zuviel Werbung?
-> Hier kostenlos registrieren

...NIcht nur wegen den Farben, auch Textfelder etc haben nicht gepasst, warum soll das mit einem SPS Programm anderst werden.
In TIA wird der absolute Zugríff auf ein Bit von einem Word von einem DB auch mit Warnung angezeigt. Arbeiten tut der Ablsolutzugriff schon.

Hast du wenigstens versucht zu lesen was hier steht - Es ist ein verdammter Fehler der ohne Grund und Notwendigkeit einfach gemacht wurde und dazu führen
kann das du ohne Warnung, Fehler oder sonstiges ein FALSCH laufendes SPS Programm nach der Migration hast - wie gesagt es läuft und dir fällt nicht auf das
irgendwas falsch ist... das Testszenario wurde von Thomas_v2.1 durchgespielt, ist lächerlich klein und zeigt nur wie wenig die Test bei der TIA Entwicklung wert sind

Ist das eigentlich eine Krankheit hier die Posts nicht zu lesen/verstehen und dann einfach irgendeinen Senf dazugeben der fast nichts mit dem Thread-Thema zu tun hat (ja ok es geht um Siemens, SPS und TIA...)

 

[LowLevelMahn]

Ich glaube der Fehler ist in TIA V12 gefixt

ich hab mal kurz die Hand auf eine V12 legen dürfen - dort scheint dieser Fehler behoben worden zu sein
kann das bitte noch ein anderer V12-Besitzer prüfen?

Falls dem so ist haben wir zu 100% die Bestätigung von Siemens das es ein wirklicher Fehler war

 

[LowLevelMahn]

Ich konnte es noch mal mit einer V12 testen und bin über das Ergebnis zufriedener (ich hatte fälschlicherweise nur einen 1200 Screenshot in den Pfoten)

KORREKTUR ZU GUNSTEN VON SIEMENS ZUR 300/400 und 1500 SPS

Siemens hat den Alignment-Fehler von TIA V11 in der V12 für die 300/400er korrigiert - in der 1500er ist er nicht vorhanden

Step 7


V12 300er


V12 1200er
(nach händischer Korrektur)




Nur für die 1200 existiert diese Unschönheit




Es ist also definitiv ein Fehler im TIA V11 gewesen
Sonst würde Siemens keinen Änderungen deswegen an TIA machen

Verschlimmbessert?
Warum zwingt Siemens aber seine Kunden bei der 1200er den Fehler VON HAND so zu verschieben/korrigieren das der Datenblock danach wieder 300/400-Konform ist
Was an der 1200er so riesig anders sein soll kann mir sicher keiner Erklären weil ungerade Byte-Arrays kann man trotzdem problemlos MOVEN
Die Problematik das dieses händische Alignment die String-Größe wirklich verändert zieht natürlich Änderungen nach sich wo z.B. ein String aus einem Array in
eine Variable kopiert wird oder z.B. eine visualisierung auf die Länge des Strings prüft (z.B. Barcode muss 11 Zeichen lang sein usw.)

UND FÜR DIE NICHTSBLICKER:

Jetzt ist das Aligment der 300/400er wieder und die der 1500er auch 100% Konform zu STEP7

Migration 300/400er

ich denke das mit der Korrektur auf das 300/400er Alignment die in den vorherigen Posts gefundenen Migrationsprobleme behoben sind

TIA-V12 ist in dieser Hinsicht schon viel besser als V11 SP5