TIA Probleme mit Slice im SCL

[El Cattivo]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
vielleicht kann mir einer von euch einen Tipp geben.
Ich habe versucht folgenden Code im SCL zu einzugeben:
"RevData".Gewicht1 ist ein INT
"RevData".Data.Byte7 ist ein Byte.

Beim Übersetzen bekomme ich folgenden Fehler:


Wenn ich das ganze im KOP programmiere bekomme ich keinen Fehler.




Kann mir das einer erklären?

 

[blackpeat]

Muss man da nicht %X1 machen?

*edit*
Sorry x muss man bei Bit machen.

 

[TP-Inc]

Zuviel Werbung?
-> Hier kostenlos registrieren

Kann die CPU vlt kein Slice? Welche ist es denn?

 

[JSEngineering]

Kann die CPU vlt kein Slice? Welche ist es denn?

Ansonsten über Merker gehen:

%MX(IDX := 101, BIT := 0)

 

[PN/DP]

Hast Du Konstanten oder Variablen deklariert mit den Namen B0 und B1?

Welche TIA-Version hast Du?

Harald

 

[El Cattivo]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hast Du Konstanten oder Variablen deklariert mit den Namen B0 und B1?

Welche TIA-Version hast Du?

Harald

Habe keine Konstanten im Programm. Ich verwende TIA V16.

Gesendet von meinem SM-G970F mit Tapatalk

 

[JesperMP]

Musste gehen.
Vielleicht hilft es alles neu generieren.

 

[PN/DP]

Ich verwende TIA V16.

Hast Du TIA V16 Update 3 ?
In TIA V15.1 funktioniert das so in SCL

Harald

 

[qwsayxqay]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das sollte aber so funktionieren. Hast du evtl. die Variablen falsch deklariert? Kein Int, oder vlt als Konstante... ?

 

[escride1]

INT - signed, arithmetischer Ausdruck
Byte - Byte eben

So darf es in SCL nicht funktionieren. Wurde irgendwo mit V16 Upd 2 eingeführt glaub ich.
In FUP/KOP funktioniert es, weil die Überprüfung nur für SCL gilt. Vielleicht auch mit irgendeinem Update später für FUP/KOP.

Grob: Arithmetische Ausdrücke dürfen nicht mehr direkt mit nicht arithmetischen Ausdrücken verlinkt werden.

 

[PN/DP]

So darf es in SCL nicht funktionieren. Wurde irgendwo mit V16 Upd 2 eingeführt glaub ich.

Daß Slice-Zugriffe nur auf Bitstring-Datentypen zulässig sind, konnte man auch schon viel früher einstellen: in den Bausteineigenschaften das Attribut "IEC-Prüfung" aktivieren.
Ist diese strengere Typprüfung nun in TIA V16 nur standardmäßig aktiviert aber abschaltbar, oder ist Slice auf Ganzzahl-Datentypen generell nicht mehr zulässig?

Harald

 

[escride1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Daß Slice-Zugriffe nur auf Bitstring-Datentypen zulässig sind, konnte man auch schon viel früher einstellen: in den Bausteineigenschaften das Attribut "IEC-Prüfung" aktivieren.
Ist diese strengere Typprüfung nun in TIA V16 nur standardmäßig aktiviert aber abschaltbar, oder ist Slice auf Ganzzahl-Datentypen generell nicht mehr zulässig?

Harald

Siemens möchte das SLICE-Zugriffe generell nur noch auf BYTE, WORD, DWORD, LWORD möglich sind, wie es in der Anleitung ja auch steht. Die Typüberprüfung umging das bisher tadellos. Mittlerweile geht es einfach nicht mehr und der Support teilte mir auch nicht mehr mit (Hochrüstung auf 16-2 war nötig wegen neuen Baugruppen in bestehender Anlage, da gabs dann ein paar hundert fehlerhafter Zugriffe trotz deaktivierter Typüberprüfung).
Die angeführten Gründe das ein Integer kein einfacher Speicherbereich ist, ein Word aber schon habe ich nicht verstanden, zumal am Ende beides nur Daten in einem Speicherbereich sind und bei korrekter Überschreibung das tun was ich will.

Also: In WORD umwandeln, Slice ausführen, nach INT umwandeln.

Ich würde mich auch nicht mehr daran gewöhnen es einfach in KOP oder FUP zu machen. Wenn die es irgendwann auch dort sperren wird es ärgerlich.

 

[Thomas_v2.1]

Ich würde mich auch nicht mehr daran gewöhnen es einfach in KOP oder FUP zu machen. Wenn die es irgendwann auch dort sperren wird es ärgerlich.

Siemens spielt auch gerne rum, anstatt ein Produkt technisch sinnvoll und konsistent zu entwickeln.

Bei Step7 V5 kam beispielsweise mit einer Version die Typüberprüfung am Operanden hinein, in der sich z.B. in FUP keine Integer-Variable auf einen Word Parameter verschalten ließ. Ich fand das sehr sinnvoll weil man viele mögliche Fehler schon bei der Programmierung erkennt. Dieses Verhalten ist dann mit einer neueren Version wieder entfernt worden. Ich vermute mal da gab es von Siemens selber schlampig programmierte Funktionen die dann Fehler geworfen haben, oder einer dieser ominösen "Großkunden" hat gesagt wir wollen das wegen unserer Schmierprogramme nicht.

Bei TIA sind etliche Dinge mehr zwischen FUP/KOP und SCL nicht konsistent.
Beispielsweise bekommst du in FUP wenn du auf einen Out Parameter (z.B. auf den Q eines TON) lesend zugreifst eine Warnung, dass diese Variable möglicherweise nicht initialisiert ist. Was einerseits Unsinn ist, denn eine FB Variable im statischen Bereich hat immer einen definierten Zustand. Andererseits wird dieses in SCL nicht als Warnung angezeigt.

Andererseits werden in SCL Literale vom Typ Gleitkomma immer als double interpretiert, was zu Warnmeldungen wegen Genauigkeitsverlust bei bestimmten Berechnungen führt, sodass wenn man keine Warnungen haben möchte, immer typisierte Literale wie REAL#1.0 verwenden muss. Das wiederum interessiert in FUP überhaupt nicht.

 

[PN/DP]

In SCL kann man den Programmierer zwingen, daß er bei für den Datentyp eigentlich unsinnigen Anweisungen mittels "typecast" ala INT_TO_WORD/WORD_TO_INT/WORD_TO_UINT/... hinschreibt, wie er die Anweisung meint.
In FUP/KOP geht sowas nur über zusätzliche MOVE, was uneffizient und für viele Programmierer oder Großkunden "unerträgliche" Mehrarbeit wäre. Deshalb hat man da die strenge Typprüfung "still und heimlich" abgeschafft. Z.B. konnte man den Zählerstand eines S7-Counters nicht mit einem Vergleicher verschalten, ohne vorher von einer WORD-Variable auf eine INT-Variable umzukopieren. Ohne strenge Typprüfung geht das nun.

Harald

 

[JSEngineering]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich denke mal, es geht einfach darum, FUP/KOP, die für simple Programmierungen geschaffen wurden, auch einfach zu halten.

SCL erfreut sich immer größerer Beliebtheit, war aber zu Anfang eher ein Exot, der nur von Hochsprachenprogrammierern verwendet wurde, mittlerweile aber - auch durch CoDeSys - beliebter wird.

Ich sehe FUP/KOP eher in der Liga "Basic-Programmierung", wo auch vieles dem Programmierer im Hintergrund abgenommen wird (Typecasting), aber den Experten dadurch manchmal in den Wahnsinn treibt.

Es sind einfach zwei unterschiedliche Programmierkonzepte. Ob man da nun gleiche Maßstäbe anlegen muß, ist fraglich. Der Funktionsumfang ist ja auch nicht gleich.

 

[Thomas_v2.1]

Ich denke mal, es geht einfach darum, FUP/KOP, die für simple Programmierungen geschaffen wurden, auch einfach zu halten.

SCL erfreut sich immer größerer Beliebtheit, war aber zu Anfang eher ein Exot, der nur von Hochsprachenprogrammierern verwendet wurde, mittlerweile aber - auch durch CoDeSys - beliebter wird.

Ich sehe FUP/KOP eher in der Liga "Basic-Programmierung", wo auch vieles dem Programmierer im Hintergrund abgenommen wird (Typecasting), aber den Experten dadurch manchmal in den Wahnsinn treibt.

Es sind einfach zwei unterschiedliche Programmierkonzepte. Ob man da nun gleiche Maßstäbe anlegen muß, ist fraglich. Der Funktionsumfang ist ja auch nicht gleich.

Darum hatte ich doch ein Beispiel mitgeliefert, wo FUP eine Warnung erzeugt, SCL aber nicht. Und das zeigt ganz einfach, dass überhaupt kein Konzept dahinter steckt, ob etwas eine Warnung oder gar einen Übersetzungsfehler erzeugt. FUP ist eine Programmiersprache wie SCL, ich sehe keinen Grund da nicht die gleichen Maßstäbe anzulegen.

FUP ist für bestimmte Programme meiner Meinung nach besser geeignet, und ein guter Programmierer zeichnet sich dadurch aus, dass er das zur Aufgabenstellung passende Werkzeug auswählt.

 

[JSEngineering]

Darum hatte ich doch ein Beispiel mitgeliefert, wo FUP eine Warnung erzeugt, SCL aber nicht.

Ja richtig, aber hier möchte ich kontern: FUP/KOP nimmt den Programmierer mehr an die Hand und gibt ihm damit auch hier einen Hinweis, den der erfahrene Programmierer für überflüssig oder unsinnig hält. Der aber den nicht so Erfahrenen gelegentlich vor datentechnischen Fehlgriffen bewahrt. SCL hingegen wird - Spekulation - eher von den erfahreneren Programmierern benutzt, bei denen man davon ausgeht, daß diese wissen, was sie tun. Z.B. auch mit Pointern in der Welt herumschießen, um ein Extrembeispiel zu nehmen, mit dem man viel kaputt machen kann.

FUP ist eine Programmiersprache wie SCL, ich sehe keinen Grund da nicht die gleichen Maßstäbe anzulegen.

Du kannst aber nicht uneingeschränkt Basic, C und Phyton miteinander vergleichen - sind auch alles Programmiersprachen.
Jede hat ihre Stärken und Schwächen.

und ein guter Programmierer zeichnet sich dadurch aus, dass er das zur Aufgabenstellung passende Werkzeug auswählt.

Da gebe ich Dir uneingeschränkt recht. Das passende Werkzeug zum passenden Problem.
Ich kann deshalb aber nicht alle Werkzeuge mit den gleichen Kriterien vergleichen. Gewisse Schnittmengen: ja.

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die Typüberprüfung umging das bisher tadellos. Mittlerweile geht es einfach nicht mehr und der Support teilte mir auch nicht mehr mit (Hochrüstung auf 16-2 war nötig wegen neuen Baugruppen in bestehender Anlage, da gabs dann ein paar hundert fehlerhafter Zugriffe trotz deaktivierter Typüberprüfung).

Also: In WORD umwandeln, Slice ausführen, nach INT umwandeln.

Ohh Gott, mir wird schlecht :sb5:

Da gibts mitlerweile so viele Änderungen zwischen den Versionen, dass ich hoffentlich nicht so bald in die Verlegenheit komme, häufiger was hochzuziehen... Bisher konnte man zumindest innerhalb einer Version ja noch einigermaßen beruhigt nen Update fahren... Naja, hab zumindest keine Anlagen mit V16

 

[PN/DP]

Siemens möchte das SLICE-Zugriffe generell nur noch auf BYTE, WORD, DWORD, LWORD möglich sind, wie es in der Anleitung ja auch steht. (...)
da gabs dann ein paar hundert fehlerhafter Zugriffe trotz deaktivierter Typüberprüfung). (...)

Also: In WORD umwandeln, Slice ausführen, nach INT umwandeln.

Besser: gar nicht erst auf die Idee kommen, INT/UINT/DINT/... direkt mit Slice-Zugriffen zu bearbeiten, sondern nur wie dokumentiert bei BYTE/WORD/DWORD... anwenden (ggf. mit INT_TO_WORD und WORD_TO_INT kapseln), dann braucht man auch nicht hunderte schon immer unsaubere Zugriffe korrigieren.

Harald

 

[escride1]

Ohh Gott, mir wird schlecht :sb5:

Da gibts mitlerweile so viele Änderungen zwischen den Versionen, dass ich hoffentlich nicht so bald in die Verlegenheit komme, häufiger was hochzuziehen... Bisher konnte man zumindest innerhalb einer Version ja noch einigermaßen beruhigt nen Update fahren... Naja, hab zumindest keine Anlagen mit V16

Ich hatte letztens noch n Bauteil inner Hand das mit V16 nicht, mit V16-2 aber schon ging. Glaub war eine der ET200M-Stationen, bin mir aber nicht ganz sicher. Sie tauchte im Hardwarekatalog nicht auf.

Eigentlich mag ich V16 relativ gern, es hat wirklich einige Verbesserungen. Aber ich persönlich komme auch sehr gut mit TIA klar, besser als mit vorherigen Programmierumgebungen.
Und mit V16 arbeiten muss ich, als Sondermaschinenhersteller kann man schlecht auf ältere Hard- und Software bauen und gleichzeitig Aktualität anpreisen.

Besser: gar nicht erst auf die Idee kommen, INT/UINT/DINT/... direkt mit Slice-Zugriffen zu bearbeiten, sondern nur wie dokumentiert bei BYTE/WORD/DWORD... anwenden (ggf. mit INT_TO_WORD und WORD_TO_INT kapseln), dann braucht man auch nicht hunderte schon immer unsaubere Zugriffe korrigieren.

Harald

Ja, es ist immer besser sich an ausnahmslos alle Regeln zu halten, aber wer hat das schon immer konsequent durchgezogen, besonders wenn es dadurch unübersichtlicher wird oder deutlich mehr Tipparbeit erfordert und man davon ausgeht das es nie abgeschafft wird?

Beispiel:
Ich sehe im Forum äußerst oft Programmvorschläge in AWL, u.a. auch für 1500er.
Die Frage ist, warum. Immerhin wird AWL vermutlich in 17, 18, 19 - irgendwann, abgeschafft. Es ist ja nur noch aus Kompatibilitätsgründen vorhanden.

Ähnlich die Systemmerker, Taktmerker, eigentlich der gesamte Merkerbereich. Irgendwann verschwindet er vielleicht, weil Siemens Datenbausteine lieber mag und Merkerbereiche eh nicht optimiert sind und eine Mischung zwischen optimiert und nicht optimiert bekanntlich langsamer ist.

Egal wie bzw. aus welchem Grund, beim Hochrüsten/Migrieren wird es immer wieder zu Problemen kommen. Kompatibel ist längst nicht alles so wie es gerne angegeben wird.