# IEC60870 Typen vs. Datentypen



## der.saboteur (24 Februar 2022)

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 (24 Februar 2022)

der.saboteur schrieb:


> 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 (24 Februar 2022)

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 (24 Februar 2022)

der.saboteur schrieb:


> 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.



der.saboteur schrieb:


> 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 (24 Februar 2022)

der.saboteur schrieb:


> 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 (25 Februar 2022)

Schau mal hier

Übersicht Datentypen TIA-Portal


----------



## hucki (25 Februar 2022)

ducati schrieb:


> 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 (25 Februar 2022)

hucki schrieb:


> 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 (25 Februar 2022)

ducati schrieb:


> 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 (28 Februar 2022)

Heinileini schrieb:


> 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 (28 Februar 2022)

der.saboteur schrieb:


> 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 (28 Februar 2022)

der.saboteur schrieb:


> daher meine Frage ob man damit überhaupt irgendeinen _unsigned _Datentypen übertragen kann.


Was meinst Du mit "übertragen"?


der.saboteur schrieb:


> 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.


hucki schrieb:


> 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 (28 Februar 2022)

Heinileini schrieb:


> der.saboteur schrieb:
> 
> 
> > daher meine Frage ob man damit überhaupt irgendeinen _unsigned _Datentypen übertragen kann. Scheinbar nicht... das man die Zahlen trotzdem rüber bekommt ist
> ...


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 (28 Februar 2022)

hucki schrieb:


> 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 (28 Februar 2022)

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 (28 Februar 2022)

hucki schrieb:


> 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 (28 Februar 2022)

> ​



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ß (28 Februar 2022)

der.saboteur schrieb:


> 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
> ...



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


----------



## Lars Weiß (28 Februar 2022)

der.saboteur schrieb:


> 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:
> ...



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 (28 Februar 2022)

Lars Weiß schrieb:


> 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?


----------



## ducati (28 Februar 2022)

Heinileini schrieb:


> Aber den Sinn der Diskussion in diesem Thread verstehe ich irgendwie trotzdem nicht.


Naja, das IEC60870 ist halt nicht so ganz selbsterklärend, als ich das einmal gemacht habe, hab ich auch ziemlich gekotzt...

Für mich wären Betriebsstunden auch eher ein Zählwert... und wenn man den dann mit Zeitstempel übertragen will/muss sind das eh 14Byte und da kommts auf 2 Byte mehr oder weniger auch nicht an


----------



## Lars Weiß (28 Februar 2022)

der.saboteur schrieb:


> 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:
> ...



Zum Wertebereich: In der Norm ist der Wertebereich (I16) mit -2^15 bis +2^15-1 angegeben.


----------



## Lars Weiß (28 Februar 2022)

Heinileini schrieb:


> 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.
> ...



Natürlich ist die Diskussion müßig - Für eine Bitmeldung wird ja auch ein Telegramm von 16 Byte (mit 7 Byte Zeitstempel) übertragen.

Das ist halt was vollkommen anderes wie mehrere KB an Nutzdaten von einer S7 in eine andere zu schaufeln...

Diese 2 Normen stecken dahinter:



			https://www.beuth.de/de/norm/din-en-60870-5-104/288874840
		




			https://www.beuth.de/de/norm/din-en-60870-5-101/256983088
		


Die 104 ist die Erweiterung zur 101.


----------



## der.saboteur (2 März 2022)

Heinileini schrieb:


> Aber den Sinn der Diskussion in diesem Thread verstehe ich irgendwie trotzdem nicht.
> ...
> Die Diskussion, ob man die Hälfte der Daten wegwirft, ist irgendwie auch müssig.





der.saboteur schrieb:


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


Ich wollte von Anfang an wissen, ob sich die IEC60870 zum Datentypen positioniert oder nicht. Eigentlich eher aus Interesse um es nächstes mal besser zu machen. Für Solche Fragen halte ich das hier für das richtige Forum. Alles andere ist irgendwie offtopic (Feldbus ja/nein, was ist überhaupt ein INT SINT usw.)
Nur für diese Info bin ich dann doch zu geizig 150€ auszugeben.



Lars Weiß schrieb:


> Zum Wertebereich: In der Norm ist der Wertebereich (I16) mit -2^15 bis +2^15-1 angegeben.


sieht also aus als wenn es eine (reinen) _unsigned _INT nicht gibt. Damit kann ich Leben ;-) und die Norm scheint da ja auch über Jahre gut genug zu sein und wurde diesbezüglich nicht angepasst

Wie ist dann ein Zählwert definiert (BCR Binary counter reading)?

Außerdem gibt es noch diese Stufenschaltermeldung. Dort funktioniert im Übrigen ein _unsigned short_ INT (0-255). Aber nur in einer Richtung (hoch zur Leittechnik).

aber ich muss trotzdem auch in die offtopic-philosophieren Kerbe springen: ich komme halt aus der Elektrotechnik, da hat man schon immer nur so viel wie nötig verwendet, was dann auch funktionieren soll (verkabelte Logiken). aber hey, vielleicht liege ich damit auf Dauer auch falsch


----------



## ducati (2 März 2022)

der.saboteur schrieb:


> aber ich muss trotzdem auch in die offtopic-philosophieren Kerbe springen: ich komme halt aus der Elektrotechnik, da hat man schon immer nur so viel wie nötig verwendet, was dann auch funktionieren soll (verkabelte Logiken). aber hey, vielleicht liege ich damit auf Dauer auch falsch


Mehr Kabel kosten halt immer mehr Geld. DINT statt INT kostet erstmal nix, erst irgendwann, wenn wegen 100000 DINT ne größere Steuerung notwendig wird.
Aber auch bei Kabeln sind Reserven sind nie verkehrt, weil immer noch billiger, als später das Kabel neu zu ziehen...


----------



## Heinileini (2 März 2022)

der.saboteur schrieb:


> sieht also aus als wenn es eine (reinen) _unsigned _INT nicht gibt. Damit kann ich Leben ;-) und die Norm scheint da ja auch über Jahre gut genug zu sein und wurde diesbezüglich nicht angepasst


Einen reinen unsigned INT gibt es nicht? Wenn nicht und man benötigt *) ihn, macht man ihn sich. Und schon gibt es ihn.
Inwieweit die eine oder andere SPS einen solchen Typ kennt und verarbeiten kann, ist nicht das Thema.
Man glaubt gar nicht, wie viele Arten und Varianten von Kodierungen schon erdacht wurden. Allein schon, weil wir das DezimalSystem bevorzugen, aber Computer "lieber" im DualSystem arbeiten. 
Zum Glück beschränken sich die "gängigen" DatenTypen aber auf eine ganz kleine Anzahl sehr logischer und äusserst praktischer GrundPrinzipien.
Die sollte man kennen. Dann kann man sich damit "austoben".
Schwieriger wird es bei DatenTypen für GleitkommaZahlen. Wie viele der Bits spendiere ich für die Mantisse, wieviele für den Exponenten, oder halte ich mich ganz einfach an eine Norm?  
Noch schwieriger wird es bei Texten. Lange Jahre haben wir uns mit 7 bzw. 8 Bit pro Zeichen begnügt. Aber die Globalisierung hat dafür gesorgt, dass nun entweder grundsätzlich 2 Byte pro Zeichen reserviert werden müssen oder aber variable 1 bis 4(?) Byte pro Zeichen. 
Eher unangenehm wird es bei DatenTypen zur Darstellung von "Datümern" (ich vermeide hier bewusst den Begriff "Daten") und (Uhr-)Zeiten.
Da gibt es (noch) keine wirkliche Übereinstimmung zwischen verschiedenen Systemen. Und es kommt das Problem hinzu, dass die Bestandteile zwar aussehen wie DezimalZahlen, aber im Zusammenhang doch keine sind. Zu allem Überfluss kommen noch so schreckliche Dinge wie Jahre und Monate mit unterschiedlichen Längen, Wochen, WochenTage und KalenderWochen hinzu ... 



der.saboteur schrieb:


> Wie ist dann ein Zählwert definiert (BCR Binary counter reading)?


Kommt drauf an. Darauf, wer es wofür und in welchem "Umfeld" definiert.
Würde man heute noch einen Zähler so auslegen, dass er im BCD-Code geladen werden muss und wahlweise im BCD-Code oder als DualZahl ausgelesen werden kann, so wie es bei den S5-Zählern war (womit ich aber nicht behaupten will, dass das mit BCR gemeint ist)?



der.saboteur schrieb:


> Außerdem gibt es noch diese Stufenschaltermeldung. Dort funktioniert im Übrigen ein _unsigned short_ INT (0-255). Aber nur in einer Richtung (hoch zur Leittechnik).


Das liegt aber nicht am DatenTyp (unsigned short INT). Die Wirksamkeit in der umgekehrten Richtung scheitert daran, dass der StufenSchalter ein Sensor ist und kein Aktor.

*) :
Ja, Verschwendung bzw. NichtVerschwendung alias Sparsamkeit ist ein Thema. Immernoch, obwohl die Bytes nicht annähernd mehr so teuer sind, wie sie es mal waren und obwohl die ÜbertragungsGeschwindigkeiten nicht annähernd mehr so lähmend langsam sind, wie sie mal es waren und obwohl die Kapazitäten der einzelnen SpeicherMedien nicht annähernd mehr so begrenzt sind, wie sie es mal waren.


----------



## Lars Weiß (3 März 2022)

der.saboteur schrieb:


> Wie ist dann ein Zählwert definiert (BCR Binary counter reading)?



Zählwert ist I32  <–2^31..+2^31–1>


----------



## Lars Weiß (3 März 2022)

der.saboteur schrieb:


> Außerdem gibt es noch diese Stufenschaltermeldung. Dort funktioniert im Übrigen ein _unsigned short_ INT (0-255). Aber nur in einer Richtung (hoch zur Leittechnik).



Die Stufenstellung ist I7 <–64..+63>, in Bit 8 steht die Info, ob das Betriebsmittel in Zwischenstellung steht oder nicht.  Den Datentyp brauchen eigentlich nur die Stromer für ihre Trafos.


----------

