IEC60870 Typen vs. Datentypen

[der.saboteur]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

gibt es eine Übersicht die darstellt welche Typen von IEC60870 (1, 11, 13,...) mit welchen Datentypen (Bool, INT, Real, ...) kompatibel sind?

Konkret möchte ich einen UINT übertragen, aber nichts passendes gefunden.

Grüße

 

[Heinileini]

Konkret möchte ich einen UINT übertragen, aber nichts passendes gefunden.

UINT bedeutet 16 Bit, aber keine ZweierkomplementDarstellung, also keine Möglichkeit, negative Zahlen darzustellen.
Für die Zahlen 0 .. 32767 sind die Darstellungen in INT und UINT identisch.
Zahlen > 32767 in UINT gibt es in INT nicht, dort werden diese als negative Zahlen (-32768 .. -1) interpretiert.
Willst/musst Du in UINT die Zahlen 32768 .. 65535 darstellen?
Dann geh von DINT aus und stell sicher, dass keine Zahlen > 65535 und keine Zahlen < 0 drin stehen und wandle DINT in WORD und nimm WORD als "Ersatz" für UINT.
Evtl. DINT in DWORD wandeln und dann von DWORD die beiden höchstwertigen Bytes "in die Tonne treten" und nur die beiden niederwertigsten Bytes weiterverwenden.

 

[der.saboteur]

Zuviel Werbung?
-> Hier kostenlos registrieren

es ist unbefriedigend, dass man dann die Hälft weg wirft bzw. man nicht alles nutzen kann
aber ist es ein IEC60870 Problem oder eher meiner IDE (Solutioncenter)? Daher die Frage einer Übersicht.

Den Unterschied DINT / Word erschließt sich mir nicht. Hier ist beides ein UINT16



es sind Betriebsstunden, daher sind die 32767 "schnell" erreicht (3,7 Jahre)

 

[Heinileini]

Den Unterschied DINT / Word erschließt sich mir nicht. Hier ist beides ein UINT16

DINT ist sozusagen die 32-Bit Version von INT.
DINT = SINT32
INT = SINT16
Die beiden niederwertigen Bytes von DINT (SINT32) sind identisch mit UINT (UINT16), vorausgesetzt der Inhalt der DINT-Variable beschränkt sich auf den ZahlenBereich 0 .. 65535. DINT kann aber grössere Zahlen enthalten oder aber auch negative Zahlen.
Deshalb sollte man vor der Umwandlung in den Typ WORD prüfen, dass keine Zahl > 65535 und keine Zahl < 0 enthalten ist, da ansonsten die Umwandlung und die Beschränkung auf 16 Bit zu falschen Ergebnissen führt.

es ist unbefriedigend, dass man dann die Hälft weg wirft bzw. man nicht alles nutzen kann

Jawoll, Verschwendung pur! Aber man wirft dann nur zwei Bytes voller Nullen weg - wie gesagt, wenn man sich auf den ZahlenBereich 0..65535 beschränkt.

PS:
Das S in SINT16 und in SINT32 bedeutet "signed" (= "vorzeichenbehaftet").
Mit SINT wird aber auch "short integer" bezeichnet, also eine kürzere Version von INT = SINT16, nämlich SINT8.

 

[ducati]

es sind Betriebsstunden, daher sind die 32767 "schnell" erreicht (3,7 Jahre)

ja, und bei UINT also max 65535h also max 7,4 Jahre ists jetzt auch nicht viel besser... Nimm DINT dann hast 2147483647h...

 

[TaHan]

Zuviel Werbung?
-> Hier kostenlos registrieren

Schau mal hier

Übersicht Datentypen TIA-Portal

 

[hucki]

ja, und bei UINT also max 65535h also max 7,4 Jahre ists jetzt auch nicht viel besser... Nimm DINT dann hast 2147483647h...

Wenn schon, dann UDINT für 4.294.967.295 h.
Damit Generationen was von haben...


Bzw. Laufzeit in Sekunden speichern und selbst dann reicht es noch für ca. 136 Jahre.

 

[ducati]

Wenn schon, dann UDINT für 4.294.967.295 h.

naja, mit dem Unsigned haben wieder einige nen Problem (z.B. S7-300)...

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

naja, mit dem Unsigned haben wieder einige nen Problem (z.B. S7-300)...

Wir wissen nicht, warum hier der Typ UINT gefragt ist. Möglicherweise vorgegeben durch irgendeine Schnittstelle zu irgendeinem Gerät.
Da aber nicht mehr und nicht weniger gefordert ist und der Typ DINT (= SINT32) eigentlich ziemlich universell verfügbar sein sollte, finde ich meinen Vorschlag angemessen und ausreichend, "intern" DINT zu verwenden und vor der Umsetzung/Kastration in den Typ UINT sicherzustellen, dass die DINT-Variable einen Wert >= 0 und <= 65.535 enthält.

 

[der.saboteur]

Wir wissen nicht, warum hier der Typ UINT gefragt ist. Möglicherweise vorgegeben durch irgendeine Schnittstelle zu irgendeinem Gerät.

irgendeine Schnittstelle ist, wie im Ausgangspost beschrieben, IEC60870,
daher meine Frage ob man damit überhaupt irgendeinen unsigned Datentypen übertragen kann. Scheinbar nicht... das man die Zahlen trotzdem rüber bekommt ist mir klar. Für bestimmte Werte, wenn nicht sogar viele, ist unsigned halt "richtiger" als signed.

so zum Beispiel in der IEC ein scaled value:
https://infosys.beckhoff.com/conten...5_104/html/TcPlcLibIEC870_5_104_M_ME_NB_1.htm

zum Wertebereich eines "scaled value" konnte ich nicht finden. Lediglich das er zwei Bytes umfasst.

 

[hucki]

Für bestimmte Werte, wenn nicht sogar viele, ist unsigned halt "richtiger" als signed.

Kommt halt auf Deine Hardware an, ob beide Seiten unsigned handeln können oder nicht.
Ist meist eher ein Problem für ältere Hardware.

Wenn ja kannst Du das auch nutzen und ich persönlich mache das bei unserer Hardware auch.
Mit den signed Typen bist Du aber sicher universeller kompatibel, insbesondere wenn Du mit einem unbekannten Partner kommunizieren musst.

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

daher meine Frage ob man damit überhaupt irgendeinen unsigned Datentypen übertragen kann.

Was meinst Du mit "übertragen"?

zum Wertebereich eines "scaled value" konnte ich nicht finden. Lediglich das er zwei Bytes umfasst.

Für meine Begriffe ist ein "scaled value" ein normierter Wert. Dieser Begriff enthält keinerlei Information darüber, wie viele Bytes die Variable lang ist, ob sie eine GleitPunktZahl oder eine Ganzzahl/FestPunktZahl enthält, mit oder mit ohne Vorzeichen.

Kommt halt auf Deine Hardware an, ob beide Seiten unsigned handeln können oder nicht.
Ist meist eher ein Problem für ältere Hardware.

Ich hatte zunächst auch angenommen, dass es hier um ein konkretes, "hardwarebezogenes" Problem geht.
Aber anscheinend geht es nur darum, neue Probleme zu erfinden, rein theoretischer Natur.

 

[hucki]

daher meine Frage ob man damit überhaupt irgendeinen unsigned Datentypen übertragen kann. Scheinbar nicht... das man die Zahlen trotzdem rüber bekommt ist

Was meinst Du mit "übertragen"?


Ich hatte zunächst auch angenommen, dass es hier um ein konkretes, "hardwarebezogenes" Problem geht.
Aber anscheinend geht es nur darum, neue Probleme zu erfinden, rein theoretischer Natur.

Naja, wir sind im Bereich "Feldbusse".
Und da wird ja in der Regel auch was zw. min. 2 Geräten übertragen, die sich dann auch verstehen sollten.

 

[Heinileini]

Naja, wir sind im Bereich "Feldbusse".
Und da wird ja in der Regel auch was zw. min. 2 Geräten übertragen, die sich dann auch verstehen sollten.

Ja, aber die Frage, die Einwände, die pro-und-contra-Überlegungen verstehe ich dann überhaupt nicht mehr.
Ist dem Feldbus denn nicht egal, ob er gerade 2 Byte mit dem Inhalt -1 (INT = SINT16) oder +65535 (UINT = UINT16) überträgt?
Wonach suchen wir denn hier wirklich? Nicht nach einem WorkAround, evtl. fehlende DatenTypen durch andere zu substituieren/zusammenzubasteln?

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Beim IEC60870 gibts doch auch Zählwerte (TK15/16/37)... Dabei wird m.M. nen DWORD übertragen. Ob das DWORD dann DINT oder UDINT beinhaltet müssen sich Sender und Empfänger absprechen... Beim Siemens steht in der Doku, dass es vermutlich eher DINT ist... Ist nicht so ganz eindeutig beschrieben...

sollte das hier sein:

Beckhoff Information System - German

Components for Automation and Control: TwinCAT NT-Realtime-System, Bus terminal, Industrial PC, BECKHOFF-Lightbus

infosys.beckhoff.com

Aber ich kenn mich mit Beckhoff nicht aus...

Vielleicht kann der TE ja auchnochmal erklären, was er eigentlich machen will.

SIOS

support.industry.siemens.com

 

[ducati]

Naja, wir sind im Bereich "Feldbusse".

IEC60870 ist nach meinem Verständnis kein Feldbus:

IEC 60870 – Wikipedia

de.wikipedia.org

Die IEC 60870 -International Electrotechnical Commission- beschreibt einen allgemeinen, offenen Kommunikationsstandard für die industrielle Automation, die in den Bereichen der Infrastrukturautomation (Schaltanlagenleittechnik, Fernwirktechnik, Netzleittechnik) angewendet wird. Das Protokoll stellt zwar einen universellen Standard dar, lässt jedoch einen großen Spielraum für spezifische Applikationen.

In Deutschland ist die IEC 60870 als DIN-Norm DIN EN 60870 veröffentlicht.

 

[ducati]

​

interessante Liste von Beckhoff:

Beckhoff Information System - German

Components for Automation and Control: TwinCAT NT-Realtime-System, Bus terminal, Industrial PC, BECKHOFF-Lightbus

infosys.beckhoff.com

 

[Lars Weiß]

Zuviel Werbung?
-> Hier kostenlos registrieren

es ist unbefriedigend, dass man dann die Hälft weg wirft bzw. man nicht alles nutzen kann
aber ist es ein IEC60870 Problem oder eher meiner IDE (Solutioncenter)? Daher die Frage einer Übersicht.

Den Unterschied DINT / Word erschließt sich mir nicht. Hier ist beides ein UINT16

Anhang anzeigen 59435

es sind Betriebsstunden, daher sind die 32767 "schnell" erreicht (3,7 Jahre)

Betriebsstunden werden in der 104 nicht als Messwert, sondern als Zählwert übertragen!

 

[Lars Weiß]

irgendeine Schnittstelle ist, wie im Ausgangspost beschrieben, IEC60870,
daher meine Frage ob man damit überhaupt irgendeinen unsigned Datentypen übertragen kann. Scheinbar nicht... das man die Zahlen trotzdem rüber bekommt ist mir klar. Für bestimmte Werte, wenn nicht sogar viele, ist unsigned halt "richtiger" als signed.

so zum Beispiel in der IEC ein scaled value:
https://infosys.beckhoff.com/conten...5_104/html/TcPlcLibIEC870_5_104_M_ME_NB_1.htm

zum Wertebereich eines "scaled value" konnte ich nicht finden. Lediglich das er zwei Bytes umfasst.

Die Übertragung von Skalierte Werte in der 104 haben sich mir auch nie wirklich erschlossen. Es hat aber damit zu tun, das die Telegrammtypen auch in der älteren 101 zur Übertragung genutzt werden. Das war noch seriell über 1200 Baud mit begrenzter Telegrammlänge. Jedes Byte war kostbar.
Bei älteren Steuerungen, die keine Gleitkommaverarbeitung konnten (Die älteren Herrschaften, die mit S5 groß geworden sind, kennen das noch). hat mal z.B. für Füllstände den Wert 500 in das Datenwort geschrieben und im Kopf 2 Kommastellen dabei geschrieben, dann waren das 5,00M Wasserstand. Den Wert hast du dann an das Fernwirkprogramm übergeben. Heute mit IEEE braucht man diese Telegrammtypen eigentlich nicht mehr.

 

[Heinileini]

Die Übertragung von Skalierte Werte in der 104 haben sich mir auch nie wirklich erschlossen. ...

Ah ja, das könnte der Hintergrund der "skalierten Werte" sein.
Dass hiermit FestPunktZahlen gemeint sind. Also als Ganzzahlen dargestellte Zahlen mit einer (vordefinierten) Anzahl NachkommaStellen.
Wenn man so will also ein "Missbrauch" der Ganzzahl-DatenTypen, um dennoch (eine "sparsame" Anzahl) NachkommaStellen zu ermöglichen.
Dann halte ich es aber eher für "schwierig", sich mit 16-Bit zu begnügen. Kommt eben auf den Anwendungszweck an.

Aber den Sinn der Diskussion in diesem Thread verstehe ich irgendwie trotzdem nicht.
Man kann doch ganz einfach die Dimension (Einheit) eines GanzZahlWertes passend wählen. Z.B. cm statt m.
Die Diskussion, ob man die Hälfte der Daten wegwirft, ist irgendwie auch müssig.
Um eine UINT16-Zahl zu einer vorzeichenbehafteten Zahl zu erweitern, benötige ich ein 17tes Bit und nehme stattdessen die nächstbeste verfügbare BitAnzahl 32.
Klar ist das irgendwo eine Verschwendung, aber sie dient doch dazu, an anderer Stelle auf Verschwendungen zu verzichten. Nämlich darauf zu verzichten, spezielle arithmetische Befehle (Addition, Subtrakttion, Multiplikation, Division, Modulo) bzw. VergleichsBefehle für viele DatenTypen - u.a. einen DatenTyp mit z.B. 17-Bit - bereitzustellen.
Wir sollten uns glücklich schätzen, dass dies mit den zur Verfügung stehenden Mitteln möglich bzw. umgehbar ist und nicht tausende von denkbaren DatenTypen mit entsprechenden unterschiedlichen OP-Codes herbeisehnen.
"Wir müssen sparen, koste es, was es wolle" mag an Schnittstellen (noch) sehr interessant sein, aber daran alles Weitere zu orientieren?