TIA Seltsames Phänomen S7-1516T / PLCSIM

[neibeck]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo!

Ich suche schon den halben Tag nach einem Phänomen, welches ich mir einfach nicht erklären kann. Es gibt da eine String Variable in einem Funktionsbaustein bzw. dessen Instanz-DB.
Auf der PLC kann ich weder im Funktionsbaustein oder auch außerhalb davon, diese eine Variable nicht beschreiben.
Lass ich das exakt gleiche Programm im Simulator laufen, funktionierts einwandfrei.
Ich hab schon das ganze restliche Programm aus dem OB1 entfernt und lasse nur den einen Befehl laufen. Siehe anbei.

Vielleicht hat jemand eine Idee

SG

 

[PN/DP]

Klingt so als ob im String im IDB das erste String-Headerbyte 'Maxlänge' nicht initialisiert ist (also 0 ist). Oder ist der IDB in der Steuerung nicht vorhanden (geht das überhaupt in TIA?) Lösche mal den IDB und lasse ihn neu erzeugen und lade ihn in die Steuerung.
Wie ist der String deklariert?
Welche CPU mit welcher Firmware Version hast Du? Vielleicht ein Bug in der Firmware?

 

[neibeck]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich hatte mir zwar eingebildet, i hab das im FB gemacht, aber i werds nochmal versuchen

 

[neibeck]

Das dürfte es tatsächlich gewesen sein. Ich verstehe zwar dann nicht, warums im FB nicht funktioniert hat, aber mal schaun obs jetzt hinhaut. Danke!

 

[neibeck]

So, ich versteh die Welt nicht mehr.... ich überschreibe den String bzw. initialisiere diesen mittels BLKMOV, Retval = 0.
Anschließend wird dieser mit dem zu ladenden WSTRING mittels WSTRING_TO_STRING auf den initialisierten String überschrieben.
Trotzdem ist der Zielstring völlig leer, sogar bereits direkt nach dem initialisieren. Was übersehe ich?

 

[NBerger]

Zuviel Werbung?
-> Hier kostenlos registrieren

ich überschreibe den String bzw. initialisiere diesen mittels BLKMOV

Genau da liegt das Problem da in deinem DB121.DBB 131 die Maximallänge des Strings zu stehen hat! (In deinem Fall 30)

Wenn du einen String ablöschen willst dann schreib besser:

Mein.String := '';

 

[neibeck]

Nein, die maximale Länge steht im Byte 230 und nicht 231. Wenn du im "ProductID Basic" reinschaust, siehst du dass in diesem Byte auch hex 1E bzw dez 30 steht.
Im Screenshot "Initialisierung..." kann man dann sehen, dass mittels BLKMOV die ProductID Basic auf den String im Send.Header geschrieben wird, und anschließend dann die ProductID mittels WSTRING_TO_STRING darüber. Soweit ich weiß, werden damit nur die verwendeten Bytes, also aktuelle Länge (Byte 231) und die verwendeten Buchstaben, überschrieben.
Warum dann trotzdem wieder nur hex 0 in allen Bytes steht, kann ich mir eben nicht erklären. Ein Überschreiben außerhalb des Bausteins schließe ich auch aus, da das Programm in der nächsten Zeile mittels Breakpoint pausiert wird

 

[Oberchefe]

Den Fall, dass die Quelle beim BLKMOV kein String ist, das Ziel aber doch, hat Siemens nicht wirklich definiert:

Mit der Anweisung "Bereich kopieren" können Sie auch Quell- und Zielbereiche vom Datentyp STRING kopieren. Wenn nur der Quellbereich vom Datentyp STRING ist, werden die Zeichen kopiert, die tatsächlich in der Zeichenkette enthalten sind. Informationen über tatsächliche und maximale Länge werden ebenfalls in den Zielbereich geschrieben. Wenn der Quell- und der Zielbereich jeweils vom Datentyp STRING sind, wird die aktuelle Länge der Zeichenkette im Zielbereich auf die Anzahl der tatsächlich kopierten Zeichen gesetzt.

Aber es gibt dennoch einen Weg:

Falls Sie die Informationen über die maximale und tatsächliche Länge einer Zeichenkette kopieren wollen, geben Sie die Bereiche an den Parametern SRCBLK und DSTBLK in Bytes an.

Aber wie der Vorredner bereits schrieb, kannst du dir den BLKMOV hier komplett sparen, die Maximale Länge wurde ja beim Anlegen des Strings definert, die tatsächliche wird aktualisert bei der Ausführung von WSTRING_TO_STRING

 

[JesperMP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Was passiert vor die WSTRING_TO_STRING ist eigentlich irrelevant.

Anschließend wird dieser mit dem zu ladenden WSTRING mittels WSTRING_TO_STRING auf den initialisierten String überschrieben.

Warum beschreibst du #Send.Header.ProductID 2mal ?
Egal, nach den zweiten schreiben mittels WSTRING_TO_STRING musste #Send.Header.ProductID = 'Prod' sein

Kannst du die Zeile vor WSTRING_TO_STRING auskommentieren ?
Diese 'Initialisierung' ist unnötig.
Ist die WSTRING notwendig ? Kann #Send.Header.ProductID ein STRING sein damit dass die Konvertierung entfällt ?
Kannst du PN/DP's Fragen beantworten ?

 

[neibeck]

Aber wie der Vorredner bereits schrieb, kannst du dir den BLKMOV hier komplett sparen, die Maximale Länge wurde ja beim Anlegen des Strings definert, die tatsächliche wird aktualisert bei der Ausführung von WSTRING_TO_STRING

Jein, das "Problem" hier ist, dass vor bzw nach dem Senden der Daten, der komplette Sendebereich mittels 16#0 abgelöscht wird.

EDIT: Ich habs jetzt mal mit einem fix adressierten Pointer im BLKMOV probiert, da funktionierts. BLKMOV symbolisch oder direktes setzen des Strings funktioniert nicht (also "Send.Header.ProductID := ProductID_Basic").
PLC ist eine S7-1516T 3PN/DP mit Firmware 2.8.2

EDIT2: Habs jetzt mit MOVE_BLK_VARIANT probiert, das haut hin. Warum auch immer....

 

[NBerger]

Stimmt DBB 131...

direktes setzen des Strings funktioniert nicht (also "Send.Header.ProductID := ProductID_Basic")

Das geht nicht da ProductID_Basic einStruct ist und kein String.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn bei einer String-Operation im Zielstring die MaxLen=0 ist, dann schreibt die Stringoperation (logischerweise) nichts in den Zielstring. Wenn in MaxLen einmal eine 0 drin steht, dann muß man dafür sorgen, daß da die korrekte MaxLen eingetragen wird, z.B. durch Zuweisen einer String-Konstante: MyString := '';
Bei SCL sollte es nicht nötig sein, BLKMOV aufzurufen. BLKMOV sollte auch nicht verwendet werden um die SCL-Compiler-Typprüfung zu umgehen.
Versuche mal Chars_TO_Strg
Wie schon Jesper angemerkt hat: Warum beschreibst Du #Send.Header.ProductID zweimal ?

Harald

 

[DeltaMikeAir]

PLC ist eine S7-1516T 3PN/DP mit Firmware 2.8.2

Unabhängig von deinem Problem würde ich dir noch das FW-Update auf V2.8.3 empfehlen:
https://support.industry.siemens.co...-200-cpus-(et-200sp-et-200pro)?dti=0&lc=de-DE

Verbesserung der Nutzererfahrung:



Folgendes Verhalten wurde verbessert:

• Es kommt nicht mehr zu dem sporadischen Verhalten, dass die CPU bei einer TCP Verbindung, die von der remoten Station abgebrochen wird, die von der remoten Station gesendeten Daten verliert. (Das unterschiedliche RST/FIN-Verhalten bei TCP-Verbindungen wurde hier angepasst.)

• Wie im Handbuch dokumentiert kann der Leitwert für die CPU-übergreifende Motion Control Achssteuerung nun von allen SIMATIC S7-1500 CPUs bereitgestellt werden.

Folgendes Verhalten wurde behoben:

• Es kommt nicht mehr dazu, dass nach einem Netz Aus / Netz Ein die CPU mit der Meldung „Warnung zu Remanenzdaten: Remanenzdaten verloren – Aktueller CPU-Betriebszustand: STOP (Initialisierung)“ in STOP geht und Daten, die als remanent gekennzeichnet wurden, verloren gehen, wenn in mehr als 1020 Datenbausteinen Daten als remanent deklariert wurden.
• Es kommt nicht mehr sporadisch zu der Meldung „Schwerwiegender Firmware-Ausnahmefehler (interner Systemcode: 16#00000000 16#10020000 16#00000000) CPU wechselt in DEFEKT-Zustand (Systemreaktion)“, wenn bei Anpassung der Initialwerte eines DBs ohne strukturelle Änderung des Inhalts oder bei Änderungen in der CPU-Meldeliste beim anschließenden Download ein Verbindungsabbruch in Kombination mit Motion- und F-Applikationen erfolgt ist.
• Es kommt nicht mehr sporadisch zu der Meldung „Schwerwiegender Firmware-Ausnahmefehler (interner Systemcode: 16#00400001 16#10020082 16#77A2A4D4) CPU wechselt in DEFEKT-Zustand (Systemreaktion)“, wenn sich der OPC UA Client beim Beenden von Subscriptions nicht konform der OPC UA Spezifikation verhält.
• Es kommt nicht mehr sporadisch zu der Meldung „Schwerwiegender Firmware-Ausnahmefehler (interner Systemcode: 16#00400001 16#1002003A 16#00010246) CPU wechselt in DEFEKT-Zustand (Systemreaktion)“, wenn der OPC UA Client auf der S7-1500 CPU versucht eine Variable zu lesen, die nicht konform der OPC UA Spezifikation als Instanz eines abstrakten Datentypen auf dem OPC UA Server angelegt worden ist.

Nur für S7-1500 T CPUs:

• Bei einer interpolierten Linearbewegung wird der Befehl immer beendet, sobald der Zielpunkt erreicht wurde.

 

[neibeck]

Stimmt DBB 131...


Das geht nicht da ProductID_Basic einStruct ist und kein String.

Sorry, hatte vergessen zu erwähnen, dass ich zwischenzeitlich die ProductID_Basic auf einen String[30] mit Datensicht der Struktur MaxLen + ActLen + Chars geändert hab.

Wenn bei einer String-Operation im Zielstring die MaxLen=0 ist, dann schreibt die Stringoperation (logischerweise) nichts in den Zielstring. Wenn in MaxLen einmal eine 0 drin steht, dann muß man dafür sorgen, daß da die korrekte MaxLen eingetragen wird, z.B. durch Zuweisen einer String-Konstante: MyString := '';

hab ich probiert, auch hier wird MaxLen nicht beschrieben.

Wie schon Jesper angemerkt hat: Warum beschreibst Du #Send.Header.ProductID zweimal ?

Um auch die nicht verwendeten Zeichen auf hex Null bzw. hex 20 (Space) zurückzusetzen.

Unabhängig von deinem Problem würde ich dir noch das FW-Update auf V2.8.3 empfehlen:

Das mit der Firmware werd ich machen, danke!

 

[neibeck]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo! Eine Frage noch zu WSTRING_TO_STRING bzw. WCHAR_TO_CHAR: Was passiert eigentlich wenn das Zeichen im WSTRING den ASCII bzw. Byte Bereich überschreitet?