TIA TIA V17 "Peripheriezugriff stimmt nicht mit der Kanalstruktur der F-Peripherie überein"

Zuviel Werbung?
-> Hier kostenlos registrieren
Ach ja und wenn schon im Übrigen. muss das Vorzeichen ja auch da sein Max. Hex High-Byte = 0x0001 und Low-Byte 0x7FFF = 98,303t bei der ausgabe von 98.304t passiert Folgendes:

1702298944617.png


Hig-Byte = 0x0002
Low-Byte = 0x8000 Oder -32678 Dez

Ergebniss 98.304t

Ich denke das von Siemens funktioniert immer noch.
 
Sorry der Messwert wird in 2 INT16 aufgeteilt (Messwert :76,864t) Diser wird in die 2 Int Aufgeteilt nach der definition vom INT16

1 Frage:

Warum sollten also Negative Zahlen auf dem Low Byte kommen?
Wenn ein DINT einfach mitten drin zwischen dem Bit 15 und Bit 16 durchgeschnitten wird, dann erhält man 2 WORD (2 "Bitstrings"). Wenn man nun behauptet, dass das L-Word ein vorzeichenbehafteter INT16 wäre und versucht, von dem INT16 nach DINT32 zu konvertieren oder mit dem INT16 zu rechnen, dann wird das Bit 15 als Vorzeichenbit interpretiert, was es aber gar nicht ist (sondern einfach nur ein Bit mit der Wertigkeit 32768, welches beliebig 0 oder 1 sein kann).
Beim Konvertieren von INT zu DINT erhalten alle neu hinzukommenden Bits 16 bis 31 den Wert des Bits 15. Was hier aber falsch ist --> alle Bits müssen 0 werden, egal welchen Wert das Bit 15 hat.

(Übrigens meinst du nicht ein Low Byte, sondern das Low-Word, was aus 2 Byte besteht.)

2. Frage:

wird sich der Sensorhersteller nicht an die Definition eines INT halten?
Nein, offensichtlich nicht. Der hat genauso ungenügend durchdacht oder zumindest falsch formuliert einfach hingeschrieben, daß die untersten 16 Bit eines DINT ein INT16 sind. Tatsächlich ist das aber lediglich eine Ansammlung von 16 Bits (ein "Bitstring") -->ein WORD16, was man zum rechnen bestenfalls als UINT16 interpretieren darf.
Mit diesem Fehler ist der Sensorhersteller aber nicht allein. Selbst der Siemens-"Fachman", der den Vorschlag #4 gemacht hat, hat das nicht genügend durchdacht und ganz offensichtlich auch nicht ausreichend getestet. :rolleyes:

Die oberen 16 Bit darf man als INT16 bezeichen, weil sie tatsächlich den Aufbau eines INT haben, der bei der Division DINT/65536 entsteht. Man darf auch den INT16 nach DINT konvertieren und erhält dabei einen DINT mit dem selben Wert, den der INT16 hat, und darf den dann mit 65536 multiplizieren, um die ursprünglichen oberen 16 Bit des DINT zu erhalten.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ja danke für die erklärung ich würde das auf alle fälle mal weiter testen und auch weiter verfolgen. Aber grundsätlich funktioniert das ja irgendwie. Natürlich wäre es mir auch lieber mit einem SHL aber das geht halt im F-Teil nicht. mit 16 Bit werten und sorry wegen der verwirrung mit Byte ich meine natürlich das Word. Ich denke schon das es vom Sensor herstller als DINT aus gegeben wird. aber das ist ein Anderes Thema. Gruß
 
Ich denke schon das es vom Sensor herstller als DINT aus gegeben wird.
Ziemlich sicher wird es das. Es ist nur falsch dokumentiert und deklariert. Und lässt sich im Safety Programm nicht einfach wieder zusammensetzen. Nur im normalen Programm sind die nötigen Anweisungen erlaubt. Warum zerlegt der Hersteller überhaupt den DINT? Die beste Lösung wäre wohl:
Ich sehe als Möglichkeit nur, das der Hersteller seine GSDML anpasst und die Daten direkt als DInt deklariert...

Alternative: Wenn im Safety Programm Sprünge oder bedingte Addition oder bedingte Zuweisungen an INT/DINT-Variablen erlaubt sind, dann könnte man das Problem lösen, indem man abfragt, ob der "Int" mit den Low-Bytes < 0 ist, und wenn ja, dann bei dem INT 32768 (oder -32768 geht auch) addieren (oder subtrahieren kommt aufs gleiche raus), dann die Konvertierung/Zusammensetzung von #4 machen, und dann nochmal L#32768 addieren. (Das bedeutet: wenn das Bit 15 = 1 ist, dann das Bit auf 0 setzen, dann das Zusammensetzen durchführen und danach das Bit 15 wieder hinzufügen)
Mit einer bedingten Zuweisung könnte man zu einer Variable 0 oder 32768 (oder -32768) zuweisen, und dann diesen Wert immer zweimal addieren.
 
Zurück
Oben