Step 7 Unstimmigkeit bei der Bausteinkonsistenzprüfung

I

itw-frank

Level-1
Beiträge
3
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

ich habe mich bezüglich meines Themas schon der Suche bedient aber leider nichts brauchbares gefunden. Falls es doch schon ein Thema dazu gibt, bitte ich dort hin zu verweisen, danke.

Nach der Bausteinkonsistenzprüfung wird folgender Fehler angezeigt:

FC52
Aktualdatentyp WORD paßt nicht zu fromalem Typ INT des Formalparameters

Soweit ist die Thematik klar, die Variable im DB (DB90.DBW356) ist als WORD deklariert und im FC52 wird ein Vergleicher mit INT ausgeführt.

Nun zum eigentlichen Problem:

In einem anderen FC (FC51) wird ebenfalls ein WORD aus dem selben DB (DB90.DBW352) an einem Vergleicher mit INT verwendet. Hier gibt mir die Bausteinkonsistenzprüfung keinen Fehler raus.
Wenn ich nun im FC51 die entsprechende Variable (DB90.DBW352) einfach erneut an den Vergleicher schreibe, wird diese Variable dort rot angezeigt, da ja auch ein Datentypkonflikt besteht.

Wie kann es nun sein, dass diese Konstellation im FC51 in Ordnung ist und im FC52 nicht? Demzufolge hätte es doch beim urpsünglichen Programmieren diesen Konflikt geben müssen.

PS: Das Programm wurde nicht von mir geschrieben.

Vielen Dank im Voraus!

FC51_niO.PNGFC51_iO.PNGFC52.PNG
 
Moin,
eine mögliche Erklärung könnte sein, dass der Code ursprünglich in AWL geschrieben wurde und die Ansicht dann auf FUP umgestellt wurde?:confused:
Vergleicher.JPG
in AWL geht der Vergleich, in FUP nicht.
 
Das finde ich prinzipiell auch so korrekt. Bei einem Vergleich auf größer oder kleiner sollte man schon mit einer Zahl (Int) arbeiten und nicht mit einem Bitmuster (Word). Das wird nur manchmal in der eile von einigen als ein und dasselbe behandelt :neutral:
 
itw-frank schrieb:
Wie kann es nun sein, dass diese Konstellation im FC51 in Ordnung ist und im FC52 nicht?
Zum Vergrößern anklicken....
Vielleicht war DB90.DBW352 zum Zeitpunkt des Speicherns von FC51 noch als INT deklariert? Wenn Du den FC51 erneut speicherst (oder in der Konsistenzprüfung übersetzt) dann sollte die Verwendung auch rot als Fehler bemängelt werden.

Liegen alle Bausteine (FC51, FC52, DB90) im selben Bausteine-Ordner?

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ja die Bausteine liegen im selben Bausteine-Ordner.

Es gibt meines Wissens nur einen pro Station (CPU)!? Wenn ich nun im S7-Programm "Neues Objekt einfügen" ausführe und einen neuen Bausteine-Ordner anlegen möchte, wird gefragt, ob der aktuelle Bausteine-Ordner überschrieben/ersetzt werden soll.
 
Howard schrieb:
Das finde ich prinzipiell auch so korrekt. Bei einem Vergleich auf größer oder kleiner sollte man schon mit einer Zahl (Int) arbeiten und nicht mit einem Bitmuster (Word).
Zum Vergrößern anklicken....

Das ist für die CPU ein und das selbe.
Es ist ein "Problem" der Betrachtungsweise.
Wieso kann man wohl bei TIA VAT eine Variable als Int oder Uint anzeigen lassen?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Es ist IMHO für den Vergleich schon wichtig zu wissen, ob man einen vorzeichenbehafteten Wert oder nicht hat.
Wie soll ich sonst der Vergleich funzen?
WORDvergleich
1111111111111100 mit 0000000000000100 (INT -4 mit 4) was ist jetzt größer?
 
wie in #2 schon steht: die CPU rechnet immer in INT (DINT ertc.)
völlig egal ob man in tempX ein INT oder HEX etc. hinein kippt.
L #temp1
L #temp2
>I
+I was auch immer
 
Senator, welchem Dezimalwert entspricht denn das Bitmuster "1111111111111100", wenn man es als INT betrachtet? Und welchem Dezimalwert entspricht es, wenn man es als UINT oder WORD betrachtet?

​
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Onkel Dagobert schrieb:
Senator, welchem Dezimalwert entspricht denn das Bitmuster "1111111111111100", wenn man es als INT betrachtet? Und welchem Dezimalwert entspricht es, wenn man es als UINT oder WORD betrachtet?
Zum Vergrößern anklicken....
Ich warte nun schon 2 Tage vergeblich, dass sich jemand hier traut, die Frage zu beantworten.
Ist sie zu dumm, um überhaupt gestellt zu werden? Ich finde nicht.
Also, mal angenommen, wir laden in
Akku2: FFFC (=1111 1111 1111 1100) und in
Akku1: 0004 (=0000 0000 0000 0100)
dann liefert
<I TRUE und
<D FALSE.
Oder läuft das heutzutage bei TIA anders und wäre ein Fall für die TIA-Fundgrube?
Sorry, diese Frage war überflüssig, denn in TIA gibt es bei INT das BitMuster 1111 1111 1111 1100 gar nicht, zumindest laut Siemens.
 
Zuletzt bearbeitet:
Das muß auch so sein, denn: 0xFFFC ist als INT eine negative Zahl (Höchstwertiges Bit ist 1) und als DINT eine positive (Höchstwertiges Bit ist 0, da 0x0000FFFC). Negative Zahlen werden immer als 2er-Komplement dargestellt, sind also als UINT/UDINT interpretiert größer als positive. Damit ist es möglich pos. und neg. Zahlen einfach ohne extra Berücksichtigung des Vorzeichens zu verrechnen.
Für INT gilt 0x0 (0) - 0x7FFF (32767) sind positive Zahlen und 0x8000 (-32768) - 0xFFFF (-1) negative. Für DWord / DINT gilt entsprechend das Gleiche mit mehr Bits.

Warum es das BitMuster 1111 1111 1111 1100, also -4 als INT bzw. 65532 als UINT/Word bei TIA nicht geben soll, ist mir aber nicht klar.
 
Ingmar64 schrieb:
Warum es das BitMuster 1111 1111 1111 1100, also -4 als INT bzw. 65532 als UINT/Word bei TIA nicht geben soll, ist mir aber nicht klar.
Zum Vergrößern anklicken....
Mir auch nicht, aber Siemens interessiert unsere unmassgebliche Meinung nicht und definiert dies nach eigenem Schlechtdünken.
Siehe Spalte WerteBereich und den "KlammerAusdruck" in Spalte Format:
INT.jpg
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich kann das von Dir besprochene Bitmuster dort nicht finden. Es steht doch eigentlich in der ersten Zeile alles genauso da, wie ich es geschrieben habe.
Ansonsten gilt: 2#1111 1111 1111 1100 = 16#FFFC = INT#-4 Das sind alles nur verschiedene Darstellungen ein und desselben Inhaltes einer Speicherzelle.
Probier es mal mit einer Variablentabelle aus. Trage dort z.B. MW100 mehrfach ein, mal als BIN, mal als INT, mal als Hex. Und dann teste mit verschiedenen Werten.
 
Das der Hex-Bereich größer 16#7FFF quasi ausgespart ist, hat nur damit etwas zu tun, weil es ansonsten dort eine Erklärung bedürfte warum eine positive Hex-Zahl wie 16#FFFC als Integer interpretiert plötzlich negativ ist. Das ist wie in der 4. Klasse: Die Rechnung 1-2 ist nicht lösbar, wer -1 hinschreibt kriegt Punktabzug.
 
Ingmar64 schrieb:
Ich kann das von Dir besprochene Bitmuster dort nicht finden.
Zum Vergrößern anklicken....
. . . weil es das in der Beschreibung nicht gibt! Laut Siemens gibt es nur dual 0000 0000 0000 0000 bis 0111 1111 1111 1111, bzw. oktal 000000 bis 077777, bzw. hexadezimal 0000 bis 7FFF.

Probier es mal mit einer Variablentabelle aus. Trage dort z.B. MW100 mehrfach ein, mal als BIN, mal als INT, mal als Hex. Und dann teste mit verschiedenen Werten.
Zum Vergrößern anklicken....
Meinst Du die SiemensVariante der VariablenTabelle oder die richtige, die WahrheitsTabelle?
NEIN, ich weigere mich standhaft. Hinterher glaube ich noch, dass Siemens Recht hat.

Ingmar64 schrieb:
Das der Hex-Bereich größer 16#7FFF quasi ausgespart ist, hat nur damit etwas zu tun, weil es ansonsten dort eine Erklärung bedürfte warum eine positive Hex-Zahl wie 16#FFFC als Integer interpretiert plötzlich negativ ist. Das ist wie in der 4. Klasse: Die Rechnung 1-2 ist nicht lösbar, wer -1 hinschreibt kriegt Punktabzug.
Zum Vergrößern anklicken....
Den PunkteAbzug nehme ich gerne hin und verzichte der Vollständigkeit halber freiwillig auf den SparEffekt.
 

Similar threads

S
Step 7 Fehler beseitigen: S5 in S7 Konvertiert
Antworten
2
Aufrufe
5K
sps-concept
S
Andi2
Vorgehensweise bei Schnittstellenänderung Multiinstanz
Antworten
9
Aufrufe
4K
Andi2
Andi2
M
Zähler = Word -> Vergleicher = int ???
Antworten
4
Aufrufe
14K
mboDigital
M
Zurück
Oben