TIA Problem mit HTA und Hex to String umwandeln und in HMI anzeigen

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

also in s7-300 (siehe seite 1 screenshot) funktioniert das an vielen Anlagen einwandfrei.

Dann frage mal den Programmierer der sich das für die S7-300 ausgedacht hat, wieso und wie das funktioniert, und wo da getrickst wird. Mit dem gezeigten Code dürfte die Anzeige auch bei S7-300 nicht funktionieren. Oder bei der S7-300 ist die HMI-Variable in WinCC flexible oder in TIA als "StringChar" (geht das überhaupt?) oder "Array[0..9] of Char" deklariert?
Schau Dir auf der S7-300 an, welche Werte in DB651.DBB4 und DB651.DBB5 stehen.
Hast Du Dir in der Dokumentation des Lesegerätes angesehen, wie das Format der E-Nummer in den Bytes 4 bis 15 ist?

hab den code von dir in ein awl netzwerk einfügen wollen, aber er Tia meckert?

Anhang anzeigen 49514

Geht das irgendwie auch ohne AWL und nur mit fertigen Anweisungen?

Sollte man eigentlich sehen, daß das kein AWL ist. Ich hatte geschrieben "Pseudocode", und auch daß das für die S7-1500 KEINE Lösung ist, weil damit die Anzeige flackern kann und wird. Damit die Anzeige bei S7-1500 sauber funktioniert, mußt Du die Zeichen in einen separaten String für die HMI kopieren. Weil das sooo kompliziert ist gibt es dafür eine fertige Anweisung "Chars_TO_Strg"

Wenn Du das Flackern unbedingt selbst sehen willst:
"MOVE B#16#0A ---> DB650.DBB4" soll bedeuten: eine MOVE-Box mit B#16#0A an IN und DB650.DBB4 an OUT
Ich male Dir mal die MOVE-Box in FUP:

           +--------+
           |  MOVE  |
          -|EN   OUT|-%DB650.DBW4
           |        |
W#16#0A06--|IN   ENO|-
           +--------+

Das ist aber furchtbar grauenhafte Programmierung - bitte nicht in professioneller SPS-Software nachmachen!

Ick will Dir ja nicht zu nahe treten...

Harald

 

[Olli_BS]

Unterschiedliche GSD-Version/Parametrierung oder EKS-Firmware ?
Beides PN oder ist an der S7 DP ?
Die EKS für PN und DP sind unterschiedlich in der Belegung.

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

Kann es sein, dass der Programmierer von Euchner etwas falsch verstanden hat?
Hat ihm jemand gesagt, in Byte 4 und 5 muss A und 5 stehen, gemeint war 0A 05 und er hat stattdessen 00 A5 umgesetzt?
Das erklärt natürlich nicht, warum S7 es deuten kann und TIA nicht.
Ist S7 "fehlertolerant" und TIA ganz pingelig? Oder gibt's die EuchnerGeräte mit verschiedenen FirmWareStänden? Mit Macke und mit ohne?
Wurde mit ein und demselben EuchnerGerät an der S7 und an der TIA getestet? Oder mit zwei verschiedenen, vermeintlich gleichen Exemplaren?
Ist es überhaupt ein Euchner Problem? Wer hat denn die Daten geliefert, die in die Keys geschrieben wurden?
Haben wir die HexDumps der Strings nur in der TIA-Variante gesehen, oder war auch ein Beispiel dabei, wie's an der S7 aussieht?

 

[DennisBerger]

Guten Morgen alle,

@pn/dp danke, ja ich schaue nachher mal an der laufenden Anlage in die s7-300 rein, was da in dem DB usw drin steht.
Sind an allen Anlagen die PN Version.

@Olli:
verstehe nicht ganz den Zusammenhang, denn die Werte werden ja geladen..das funktioniert ja.. wenn ich den DB online anschaue sind die korrekten Buchstaben und Zahlen zu sehen.. (als Hex)...
siehe screenshot:


somit dürfte doch das Gerät funktionieren und ich hab leider nur das Problem, die Daten richtig zu konvertieren?

 

[Olli_BS]

Korrekt sind die Daten eben eigentlich nicht. So dürfte das auch nicht in S7 funktionieren.
Die EINGELESENE Daten wirken schon falsch oder anders. Konventieren wäre der nächste Schritt. (Oder in der S7 wird doch noch konventiert).
Also noch mal:
Genau ein und derselbe (!!!) Key/Chip, der bei S7 tut, funktioniert bei TIA nicht::::: Ja oder Nein ?????
Oder sind das neue Keys oder auch mit der TIA-Anlage beschrieben?

 

[NBerger]

Zuviel Werbung?
-> Hier kostenlos registrieren

Also die 300 und 1500 er Versionen sind NICHT gleich, auch nicht annähernd!
Das wurde niemals migriert bzw. von TIA automatisch konvertiert!

Auf die Variable : "E-Nummer" wir NICHT geschrieben
Die Variable "E-NummerinString" ist in der 1500'er Version ein Array mit 10 Feldern a String 254...
Und mittenrein wird aus der Peripherie ABSOLUT etwas drübergenagelt...

Mein Tipp: Halte dich ans Original!

Solltest du es dir zutrauen, dann ändere dann den bereits laufenden Code.

 

[Heinileini]

Schau Dir auf der S7-300 an, welche Werte in DB651.DBB4 und DB651.DBB5 stehen.

Wir bekommen hier immer nur zu sehen, was in DB650.DBB4 und DB650.DBB5 steht, nämlich 00 A5 und das ist und bleibt Unsinn und darum funktioniert die TIA-Version nicht.
Wir möchten aber zur Abwechslung mal sehen, was in der funktionierenden S7-Version an der entsprechenden Stelle, nämlich DB651.DBB4 und DB651.DBB5 steht!

 

[PN/DP]

Also die 300 und 1500 er Versionen sind NICHT gleich, auch nicht annähernd!
Das wurde niemals migriert bzw. von TIA automatisch konvertiert!
[...]
Die Variable "E-NummerinString" ist in der 1500'er Version ein Array mit 10 Feldern a String 254...

Kennst Du die Anlage von DennisBerger? (Seid Ihr verwandt?)
Also für mich sieht der Code durchaus wie migriert/konvertiert aus, erst ab DBB128 unterscheiden sich die Instanzdaten, was bei der neuen nicht funktionierenden TIA-Version wohl Testcode ist.
Wozu da das Array für 10 String[254] ist weiß ich nicht, doch das spielt auch (noch) keine Rolle. (Ich kann mir aber gut vorstellen, daß diese Deklaration so gar nicht gewollt ist)

Auf die Variable : "E-Nummer" wir NICHT geschrieben
[...]
Und mittenrein wird aus der Peripherie ABSOLUT etwas drübergenagelt...

Eben durch DPRD_DAT wird in den gezeigten IDB von DBX0.0 bis DBB127 geschrieben und damit auch in die Variable EKS_1_E_Nummer (DBB4 bis DBB15).
Bei der S7-300 kann man bei DPRD_DAT.RECORD keinen IDB-internen-Bereich angeben, da muß immer die DB-Nummer mit angegeben werden. Deshalb sieht das Einlesen in die Instanzdaten so furchtbar aus, und der FB kann nicht mehrfach instanziiert werden. Man hätte es aber durchaus schöner (mit STRUCT) programmieren können.
Bei der S7-1500 muß man bei DPRD_DAT.RECORD keine DB-Nummer mehr angeben, daher würde ich aus dem Bereich DBX0.0 bis DBX127.7 einen STRUCT oder PLC-Datentyp machen und den bei DPRD_DAT.RECORD symbolisch angeben.



@DennisBerger

Projektierung HMI hab ich bei beiden gleich:
Anhang anzeigen 49505

hier de deklaration der Variable in HMI
Anhang anzeigen 49510

Interessant wäre es, wenn Du uns genau diese beiden Bilder auch von der S7-300-Version zeigen würdest.
Und zusätzlich die Online-Werte von DB651.DBD4.

Harald

 

[DennisBerger]

Zuviel Werbung?
-> Hier kostenlos registrieren

es läuft!

Ich hab unabhängig von NBerger (nicht mit mir verwandt) die Anleitung bei Euchner zum Tia Portal mit Bibliothek runtergeladen und diese verwendet.
hat auf Anhieb geklappt.
Hatte bisher nur die eine (alte) Anleitung von früher für Step7 und 300er gehabt, dachte heute morgen dann da muss es doch inzwischen was neues für TIA geben ..und dann hab ich es gefunden


Es ist in der Tat so, dass 300er und 1500er Version sich wie NBerger schrieb unterscheiden in der Euchner Datenverarbeitung

Was lern ich draus:
man muss nicht jeden Code 1:1 übernehmen und diesem vertrauen (und an sich selber zweifeln) nur weil er auf allen anderen Anlagen (mit anderer Steuerung) läuft und das migrieren von TIA geht auch nicht fehlerfrei.
Den Programmierer von damals kann ich nicht mehr fragen, der ist in Rente.

wieder was gelernt....doch ab und zu mal neues beginnen, reinlesen ist besser als nur übernehmen.


Die fertige funktionierende Euchner Bibliothek für TIA ab V14 findet ihr hier
https://assets.euchner.de/uploads/Library_EKS-TIAV14SP1_20200116.zip
die Beschreibung dazu hier
https://assets.euchner.de/sirius/428241.pdf



P.s. am Ende dann char to string und alles wird angezeigt.


p.p.s die S7-300 werte zeig ich Euch natürlich noch

 

[Heinileini]

es läuft!
Ich hab ... die Anleitung bei Euchner zum Tia Portal mit Bibliothek runtergeladen und diese verwendet.
hat auf Anhieb geklappt.
...
P.s. am Ende dann char to string und alles wird angezeigt.

Hat es wirklich an der Euchner Anleitung und Bibliothek gelegen oder eher an "am Ende dann char to string"?

...doch ab und zu mal neues beginnen, reinlesen ist besser als nur übernehmen.

... und reindenken(!), aber das habe ich bei ganz anderen Anlässen dazugelernt.
Dieser Thread hat leider nicht dazu beigetragen - alle Rätsel sind für mich noch ungelöst und mit dem Beitrag #29 ist mindestens ein weiteres hinzu gekommen.

 

[DennisBerger]

also..
die Lösung mit den fertigen FCs und DBs von Euchner funktioniert.
ich musste dann nur am Ende noch char to string machen, damit ich den Text auf der HMI im Ausgabefeld sehe.


den ursprünglichen Code von Seite 1 und 2 hab ich nicht zur Anzeige des Schlüssels auf der HMI hinbekommen...
scheint wirklich nur in Step7 mit 300er Steuerung zu gehen...


Und wie gesagt, ich werde morgen an die laufende Anlage mit der 300er SPS gehen und da vom DB 650 und DB651 online einen Screenshot machen.

 

[DennisBerger]

Zuviel Werbung?
-> Hier kostenlos registrieren

Guten Morgen,
ich wollte euch ja noch den S7-300 online Status nachreichen:

Hinweis die Nummer des DBs ist in der 300er #650 und in 1500er #651 (nur als Info)


Variable EKS_1_E_Nummer ist hier String


VAT


HMI


bei E-Nummer wird mit dieser Programmierung Step7 und einer 300er die korrekte Nummer im Ausgabefeld des TP1200 angezeigt (E17380), Variable DB650.DBX4.0 String [10]

_______________


Habe aufgrund Eurer Hilfe und eurem Hinweis auf die ersten beiden Bytes DBB4 und DBB5 und nach Anschauen der online VAT nochmal den ursprünglichen migrierten 300er Code in TIA um ein Netzwerk mit dem Char to string befehl erweitert und die Variable EKS_1_E_Nummer von Datentyp String auf Array of Char (siehe auch Posting 26 von NBerger, danke dir) geändert.
und nun geht auch dieser.

Wichtig ist den Pointer auf 2 zu setzen, denn nur dann zeigt die HMI die Nummer im Ausgabefeld an bei der 1500er und TIA.

danke euch..


Bei der 300er und dem TP1200 reichte es aus einfach DB650.DBX4.0 abzufragen ohne Pointer und ohne zusätzlichen char to string befehl..
die Variable wird als String geliefert.
die Nummer wird im Ausgabefeld trotzdem richtig angezeigt trotz DBB4 und 5 -> :?:



Hier die Bilder zum nun auch funktionierenden Code ohne Euchner Bibliothek / Beispiel

Daten holen von Euchner:

Variable EKS_1_E_Nummer ist hier Array of Char



Char to String fürs HMI Ausgabefeld:


danke nochmal an alle für die tolle Unterstützung.

Vielleicht hilft ja der Thread anderen Usern auch irgendwann mal.

 

[Olli_BS]

Ich verstehe ehrlicherweise immer noch nicht das eigentliche Problem...
Die eingelesenden Daten waren ja unterschiedlich. Das man die zu einem String wandeln kann ist klar.
Aber warum steht in DBB5 in TIA "A5" und in S7 "6"??? Bei Rohdaten von identischen Geräten???
Entweder kommen da andere Daten rein oder in S7 wurde noch irgendwo hart einfach die 6 in DBB5 eingetragen.
Ist aber auch egal...

 

[Heinileini]

Ich verstehe ehrlicherweise immer noch nicht das eigentliche Problem...

Der Trick liegt in der Interpretation der 12 Bytes 4 bis 15 bzw. eigentlich der LängenAngaben in Byte 5 (und Byte 4).
Die 12 Byte als String[10] zu deklarieren ist "tötlich", wenn Byte 4 nicht die GesamtLänge ('0A') des String enthält (sondern z.B. 0) und Byte 5 nicht die aktuell belegte Länge des Strings ('00' .. '0A', sondern z.B. 'A5' = 165).
In der ursprünglichen Version sind die Bytes 4 bis 14 (statt 15 - eigentlich auch falsch) als Array[0..10] of Char deklariert und nicht als String. Damit kann man weiterarbeiten, indem man ab dem 3 Byte bis zum letzten = 11. das Array in String konvertiert - allerdings bis maximal 9 statt der von Euchner vorgesehenen 10 Zeichen.
So ganz korrekt sind beide Versionen nicht. Aber die TIA-Version stolpert darüber, dass selbst das "Reingucken" in die Bytes durch die Interpretation als String misslingen muss.

Das von Euchner freigehaltene Byte 4 enthält 0 und Byte 5 die Anzahl Zeichen ab Byte 6. Was "Euchner" dort in den DB schreibt, dürfte das sein, was man zuvor richtig oder falsch in den Chip geschrieben hat.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wie hier schon von mehreren Kollegen geschrieben, ist auch in der S7-300-Variante die Nummern-Anzeige (als String) nicht korrekt programmiert, funktioniert aber erstaunlicherweise.

Ich habe nun mal die S7-300-Variante mit TIA V13 SP1 simuliert und siehe da: Das liegt am TIA-WinCC-HMI-Kommunikationstreiber "SIMATIC S7 300/400"!
Die max Länge des Strings (im ersten Byte, DBB4) wird komplett ignoriert. Die aktuelle Länge (im zweiten Byte, DBB5) wird nur beachtet wenn sie kleiner als die deklarierte max-Stringlänge ist - eine max. Länge > 10 wird bei String[10] ignoriert. Und "freundlicherweise" interpretiert der Treiber zusätzlich auch noch ein 0-Byte (16#00) als String-Ende-Zeichen wie bei 0-terminierten Strings von C u.Ä., unabhängig von der angegebenen akt. Länge. Das haben die TIA-Programmierer bestimmt "gut gemeint" :roll: Ich denke, das Verhalten wird auch in den nachfolgenden TIA-Versionen so bleiben - es wäre ja furchtbar, wenn zukünftige TIA-Versionen solch schlampige Programmierung anmeckern würden, wo es doch vorher toleriert wurde.

Schlimm ist nur, daß S7-Programmierer ohne genaue Ahnung von dem was sie tun, denken daß sie es richtig gemacht haben, weil das Panel ohne Meckern etwas anzeigt, das so aussieht wie erwartet. Und wenn dann nach der Migration ein Treiber werkelt, der sich genau an das Format der Datentypen hält, dann kommt das große Rätselraten. Der TIA-HMI-Kommunikationstreiber "SIMATIC S7 1500" beschwert sich zu Recht über das unzulässige Format des String[10], wenn max Länge = 0 und akt. Länge = 165 eingetragen ist.

Harald

 

[Olli_BS]

OK, dann klärt es sich. Ich dachte immer in S7 hätte in DBB5 eine 6 gestanden. Habe jetzt mal das ASCII-Zeichen aus dem Varieblentabellen-Screenshot ausprobiert und ist auch 16#A5.
Dann macht das alles Sinn.