TIA Wörter werden vom FU nur teilweise richtig übersendet

T

TaHan

Level-2
Beiträge
100
Reaktionspunkte
7
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

ich programmiere zum ersten mal einen FU und sitze seit heute am folgenden Problem und komme da einfach nicht weiter:

Ich möchte vom FU (G120 CU240S PN) Daten mittels Siemens Telegram 352 an die Steuerung (315-2 PN/DP) senden.
Ich erhalte nur die Ist-Werte für Strom, Drehmoment und Drehzahl richtig übermittelt. Das Zustandswort selbst ändert sich nur sporadisch, bzw. bleibt unverändert.
Sobald der Antrieb läuft, erhalte ich über die Ist-Warnung Werte, obwohl direkt am FU dieser Wert (r2132) 0 anzeigt.
Auch das Zustandswort am FU wird richtig dargestellt.
Es kommt noch hinzu, dass der Fehler-Code (r2131) falsch dargestellt wird.


Code: 
// Wörter aus FU lesen (Telegram 352)

#diagID_RD := DPRD_DAT(LADDR := INT_TO_WORD(#LADDR),
                           RECORD => #InData_word);
    
    #ZSW1_word := #InData_word[0];
    
    #TempWORD := #ZSW1_word AND 16#0001;
    FOR #TempINT := 1 TO 16 DO
        IF #TempWORD <> 0 THEN
            #TempArray[#TempINT] := true;
        END_IF;
        #TempWORD := SHR(IN := #InData_word[0],
                     N := #TempINT) AND 16#0001;
    END_FOR;
    #ZSW1_BITS := #TempArray;

// Zustanswort übernemmen

    #RD_WR_DB.RD_FU.Zustandswort1.X0_ESB := #ZSW1_BITS[0];
    #RD_WR_DB.RD_FU.Zustandswort1.X1_BB := #ZSW1_BITS[1];
    #RD_WR_DB.RD_FU.Zustandswort1.X2_BF := #ZSW1_BITS[2];
    #RD_WR_DB.RD_FU.Zustandswort1.X3_Stoerung := #ZSW1_BITS[3];
    #RD_WR_DB.RD_FU.Zustandswort1.X4_AUS2 := #ZSW1_BITS[4];
    #RD_WR_DB.RD_FU.Zustandswort1.X5_AUS3 := #ZSW1_BITS[5];
    #RD_WR_DB.RD_FU.Zustandswort1.X6_SPERRE := #ZSW1_BITS[6];
    #RD_WR_DB.RD_FU.Zustandswort1.X7_WARN := #ZSW1_BITS[7];
    #RD_WR_DB.RD_FU.Zustandswort1."X8_AB-SOLIS" := #ZSW1_BITS[8];
    #RD_WR_DB.RD_FU.Zustandswort1.X9_PLC := #ZSW1_BITS[9];
    #RD_WR_DB.RD_FU.Zustandswort1.X10_MAX_n := #ZSW1_BITS[10];
    #RD_WR_DB.RD_FU.Zustandswort1.X11_IMP := #ZSW1_BITS[11];
    #RD_WR_DB.RD_FU.Zustandswort1.X12_MHBO := #ZSW1_BITS[12];
    #RD_WR_DB.RD_FU.Zustandswort1.X13_UETA := #ZSW1_BITS[13];
    #RD_WR_DB.RD_FU.Zustandswort1."X14_RL-LL" := #ZSW1_BITS[14];
    #RD_WR_DB.RD_FU.Zustandswort1.X15_UEFU := #ZSW1_BITS[15];

Code: 
// Warn Code
    
    #RD_WR_DB.RD_FU.WARN_CODE := #InData_word[4];
    
// Fehler Code
    
    #RD_WR_DB.RD_FU.FAULT_CODE := #InData_word[5];

Ich habe auch bereits Siemens Anwendungsbeispiele ausprobiert, und habe dort ein ähnliches Phänomen beobachten können.

Hoffentlich könnt ihr damit etwas anfangen und mir evtl Tipps geben, wie man es besser lösen kann bzw. mir meinen Fehler aufzeigen könnt.

Ich arbeite mit Tia v16 Update3
Firmwareversion CPU v3.2, vom FU kann ich leider nicht sagen, da die Anlage beim Kunden steht und wir Aufgrund der aktuellen Situation nicht hin dürfen.

Das empfangene Wort vom FU habe ich auch schon gedreht, Stichwort ROL . Aber wie bereits oben geschrieben, verändert sich das Zustandswort nicht, bzw. nur wenn der FU in Betrieb genommen wurde und wieder deaktiviert wurde.

Der Bit für PLC-Steuerung ist ebenfalls gesetzt.
 
Zuletzt bearbeitet:
TaHan schrieb:
Code: 
    #ZSW1_word := #InData_word[0];
    
    #TempWORD := #ZSW1_word AND 16#0001;
    FOR #TempINT := 1 TO 16 DO
[COLOR="#FF0000"]        IF #TempWORD <> 0 THEN
            #TempArray[#TempINT] := true;
        END_IF;
[/COLOR]        #TempWORD := SHR(IN := #InData_word[0],
                     N := #TempINT) AND 16#0001;
    END_FOR;
Zum Vergrößern anklicken....
Bei einer S7-300 wird TEMP-Speicher nicht automatisch initialisiert. Das allermeistens überflüssige automatische Initialisieren des kompletten TEMP-Speichers eines Bausteins wurde erst bei S7-1x00 eingeführt für Programmierer die das nicht beachten... Ich weiß nicht, ob das die Ursache Deines Problems ist, aber die Schleife zum Kopieren der Word-Bits in ein BOOL-Array funktioniert deshalb nicht korrekt. Ich würde einfach so programmieren:
Code: 
    #TempWORD := #InData_word[0]; // #ZSW1_word
    FOR #TempINT := 1 TO 16 DO
        #TempArray[#TempINT] := (#TempWORD AND 16#0001) <> 0;
        #TempWORD := SHR(IN := #TempWORD, N := 1);
    END_FOR;

Harald
 
Ph3niX schrieb:
Wie in diesem Beitrag zu sehen, hast du die Bits im Zustandswort und wahrscheinlich ebenso im Steuerwort verdreht:

Erbitte Hilfe zum Steuer- bzw. Zustandswort

Hier findest du die Konfiguration der Standardtelegramme als UDT:
https://support.industry.siemens.co...ndardtelegrammen-im-tia-portal?dti=0&lc=de-WW
Zum Vergrößern anklicken....


Wenn ich das Steuerwort nicht drehe, wird dieses Fehlerhaft an den FU übergeben. Beim Steuerwort habe ich das High-Byte gegen das Low-Byte ausgetauscht. Damit kann ich den FU über die SPS steuern.

Ich habe zuvor meinen Code mithilfe einer 1500er CPU ausprobiert und es hat recht gut funktioniert. Das ich nicht den gleichen Code für eine 300er nehemen kann ist mir schon klar. Diesen habe ich aber schon angepasst. Da ich keine Erfahrung mit der Programmierung einer 300er CPU habe, kann ich nicht sagen, ob die Änderung so korrekt ist.

Aber zurück zu meinem Problem. Bevor ich auch nur daran denke das Zustandswort richtig anzuordnen muss ich es zuvor auslesen können. Dies geschieht jedoch nicht. Parallel dazu probiere ich unterschiedliche Befehle über eine 1500er und einem gleichwertigen FU (G120C), um beobachten zu können, welche Zustanswörter an die SPS übertragen werden. Bei der 300er geschieht sogut wie garnichts, obwohl die Anfangsadresse der Ausgänge vom FU stimmen. Ich erhalte nur die IST-Werte für Drehzahl, Drehmoment und Strom korrekt übermittelt.

Kurz zusammengefasst; PZD1 (Zustandswort) ändert sich nur, wenn der Antrieb eingeschaltet wird; PZD5 ( Warnmeldung) zeigt einen Wert an, obwohl im FU dieser Wert = 0 ist; PZD6 (Fehlermeldung) wird fehlerhaft angezeigt ( im FU z.B. 16#0070 [Aussage vom Kunden, auf die ich mich verlassen muss; ich vermute dass es 70[SUB]10[/SUB] ist] und in der SPS 16#0080 ).

Erst dachte ich, dass die Bits verdreht sind, aber nach dem umwandeln in den Binärcode sieht man, dass es ein ganz anderer Wert ist.

Würden die Werte für Drehmoment, Drehzahl und Strom falsch oder garnicht dargestellt, würde ich den Fehler eher in der Adressierung suchen, leider ist es so, wie es ist.
 
Zuletzt bearbeitet:
PN/DP schrieb:
Bei einer S7-300 wird TEMP-Speicher nicht automatisch initialisiert. Das allermeistens überflüssige automatische Initialisieren des kompletten TEMP-Speichers eines Bausteins wurde erst bei S7-1x00 eingeführt für Programmierer die das nicht beachten... Ich weiß nicht, ob das die Ursache Deines Problems ist, aber die Schleife zum Kopieren der Word-Bits in ein BOOL-Array funktioniert deshalb nicht korrekt. Ich würde einfach so programmieren:
Code: 
    #TempWORD := #InData_word[0]; // #ZSW1_word
    FOR #TempINT := 1 TO 16 DO
        #TempArray[#TempINT] := (#TempWORD AND 16#0001) <> 0;
        #TempWORD := SHR(IN := #TempWORD, N := 1);
    END_FOR;

Harald
Zum Vergrößern anklicken....

Danke für deine Antwort, leider klappt das nicht. Jetzt erhalte ich nur noch den wert 16#0100. Als Zustandswort wird der Wert 16#EB31 empfangen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Guten Tag,

das TIA 16 Startdrive Upd 3 wurde von Siemens zurückgezogen.

Die in der Update Version angelegten Projekte lassen sich mit neueren Updates nicht mehr öffnen. Man kann das Projekt bei Siemens einschicken.

Ist unwahrscheinlich dass das damit zusammenhängt. Aber man weiss ja nie.

Grüße
 
slider_7 schrieb:
Guten Tag,

das TIA 16 Startdrive Upd 3 wurde von Siemens zurückgezogen.

Die in der Update Version angelegten Projekte lassen sich mit neueren Updates nicht mehr öffnen. Man kann das Projekt bei Siemens einschicken.

Ist unwahrscheinlich dass das damit zusammenhängt. Aber man weiss ja nie.

Grüße
Zum Vergrößern anklicken....

Gut zu wissen.
Jedoch wurde der FU mittels GSD-Datei parametriert.

Trifft das auch auf TIA 16 Update 3 auch zu, dass Siemens es zurückgezogen hat?

Startdrive hat bei uns Update 5, Update 3 haben wir übersprungen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich habe versucht mittels Pointer direkt die Eingänge auszulesen. Das Problem bleibt weiterhin bestehen. Das heißt für mich ja nur noch, dass die Kommunikation zwischen FU und der CPU nicht richtig funktioniert.
Ich werde es mal mit einem anderen FU versuchen, um zu sehen, ob das Problem weiterhin besteht.
 
Guten Tag.

Moeglicherweise kommst Du mit der Ueberlagerung eines Wortes in ein Array [0..15] of Bool weiter. Dies wuerde Dir dann vermutlich auch die gesamte Schleife ersparen.

Da wir im Unterforum „TIA“ sind, gehe ich davon aus, dass auch der gepostete Code aus einem TIA-Projekt stammt und sich in einer FC oder einem FB befindet.
Ich mutmaße, dass Deine Variable „#ZSW1_word“ in der Bausteinschnittstelle der FC bzw. des FB im Bereich „Temp“ deklariert wurde und vom Datentyp „Word“ ist.
Ich mutmaße, dass Deine Variable „#ZSW1_BITS“ in der Bausteinschnittstelle Der FC bzw. des FB im Bereich „Temp“ deklariert wurde und vom Datentyp „Array [1..16] of Bool“ ist.
In dem folgenden Beispiel verwende ich andere Namen, damit Du deine Bausteinschnittstelle nicht ausseinanderpfluecken musst und weil mir ist nicht bekannt, ob das Ueberlagern auch mit einem Array [1..16] of Bool funktioniert.

Um ein Wort auf ein Array [0..15] of Bool zu überlagern, sind folgende Schritte erforderlich:

  1. Gehe in die Bausteinschnittstelle der FC bzw. des FB.
  2. Deklariere im Bereich „Temp“ eine Variable. Fuer dieses Beispiel verwende ich den Namen „TmpWord“.
  3. Waehle fuer die Variable „TmpWord“ den Datentyp „Word“ aus bestaetige die Eingabe.
  4. Deklariere direkt in der Zeile unterhalb der Variablen „TmpWord“ eine weitere Variable. Fuer dieses Beispiel verwende ich den Namen „TmpArray“.
  5. Waehle fuer die Variable „TmpArray“ den Datentyp „AT“ aus und bestaetige die Eingabe.
  6. Nach Bestaetigung des Datentyps „AT“ erscheint neben dem Namen der Variablen „TmpArray“ der Text „AT „TmpWord““ und der Datentyp der Variablen „TmpArray“ aendert sich von allein in „Word“.
  7. Aendere den Datentypen für die Variable „TmpArray“ von „Word“ in Array [0..15] of Bool.
  8. Gehe in das Code-Fenster der FC bzw. des FB.
  9. Weise der tempraeren Variablen „TmpWord“ den Wert Deiner Prozessdaten zu. Das sollte, wenn ich Deinen geposteten Code richtig lese, die Variable „#InData_word[0]“ sein.

Damit waere die Ueberlagerung schon abgeschlossen und Dir stehen die einzelnen Bits des Zustandswortes in der Variablen „TmpArray“ zur Verfuegung.

Mit freundlichen Grueßen,
Teilnehmer
 
Ich habe meinen Fehler gefunden.
Im Projekt ist die GSD-Datei mit dem Telegram 352 abgelegt, im FU selbst ist diese aber auf 999 eingestellt.
Da es mein erster FU ist, habe ich diese Möglichkeit gar nicht in betracht gezogen.

Nachdem ich den Kunden gebeten habe Starter zu installiert, konnte ich den betroffenen FU auslesen und somit meinen Fehler finden.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Teilnehmer schrieb:
Guten Tag.

Moeglicherweise kommst Du mit der Ueberlagerung eines Wortes in ein Array [0..15] of Bool weiter. Dies wuerde Dir dann vermutlich auch die gesamte Schleife ersparen.

Da wir im Unterforum „TIA“ sind, gehe ich davon aus, dass auch der gepostete Code aus einem TIA-Projekt stammt und sich in einer FC oder einem FB befindet.
Ich mutmaße, dass Deine Variable „#ZSW1_word“ in der Bausteinschnittstelle der FC bzw. des FB im Bereich „Temp“ deklariert wurde und vom Datentyp „Word“ ist.
Ich mutmaße, dass Deine Variable „#ZSW1_BITS“ in der Bausteinschnittstelle Der FC bzw. des FB im Bereich „Temp“ deklariert wurde und vom Datentyp „Array [1..16] of Bool“ ist.
In dem folgenden Beispiel verwende ich andere Namen, damit Du deine Bausteinschnittstelle nicht ausseinanderpfluecken musst und weil mir ist nicht bekannt, ob das Ueberlagern auch mit einem Array [1..16] of Bool funktioniert.

Um ein Wort auf ein Array [0..15] of Bool zu überlagern, sind folgende Schritte erforderlich:

  1. Gehe in die Bausteinschnittstelle der FC bzw. des FB.
  2. Deklariere im Bereich „Temp“ eine Variable. Fuer dieses Beispiel verwende ich den Namen „TmpWord“.
  3. Waehle fuer die Variable „TmpWord“ den Datentyp „Word“ aus bestaetige die Eingabe.
  4. Deklariere direkt in der Zeile unterhalb der Variablen „TmpWord“ eine weitere Variable. Fuer dieses Beispiel verwende ich den Namen „TmpArray“.
  5. Waehle fuer die Variable „TmpArray“ den Datentyp „AT“ aus und bestaetige die Eingabe.
  6. Nach Bestaetigung des Datentyps „AT“ erscheint neben dem Namen der Variablen „TmpArray“ der Text „AT „TmpWord““ und der Datentyp der Variablen „TmpArray“ aendert sich von allein in „Word“.
  7. Aendere den Datentypen für die Variable „TmpArray“ von „Word“ in Array [0..15] of Bool.
  8. Gehe in das Code-Fenster der FC bzw. des FB.
  9. Weise der tempraeren Variablen „TmpWord“ den Wert Deiner Prozessdaten zu. Das sollte, wenn ich Deinen geposteten Code richtig lese, die Variable „#InData_word[0]“ sein.

Damit waere die Ueberlagerung schon abgeschlossen und Dir stehen die einzelnen Bits des Zustandswortes in der Variablen „TmpArray“ zur Verfuegung.

Mit freundlichen Grueßen,
Teilnehmer
Zum Vergrößern anklicken....

Du gehst davon richtig aus, dass ich TIA nutze.
So habe ich es auch am Anfang programmiert und mich gewundert, dass so ein Fehler-Bild aufgetreten ist.
Anschließend habe ich den Code etwas verändert, aber das Fehler-Bild blieb weiterhin bestehen.

Am Ende lags nicht an der Programmierung, sondern das abändern im FU durch eine andere Partei auf ein freies Telegram.

Trotzdem danke für dein Hilfestellung;)
 
waere es nicht am einfachsten , man legt sich ein Datentypen Protokol352In / Protokol352Out an , man kann sie natuerlich auch aus der Siemens DRIVE BIB nehmen .

die Datentypen in einen DB eingebaut und mit dem SFC sofort in den DB einlesen bzw von dort schreiben ?
 
Peter Gedöns schrieb:
waere es nicht am einfachsten , man legt sich ein Datentypen Protokol352In / Protokol352Out an , man kann sie natuerlich auch aus der Siemens DRIVE BIB nehmen .

die Datentypen in einen DB eingebaut und mit dem SFC sofort in den DB einlesen bzw von dort schreiben ?
Zum Vergrößern anklicken....

Das wäre nicht nur einfacher, sondern würde auch schneller funktionieren. Jedoch gibt es nun einmal Kunden, die dann besondere Wünsche äußern. Und wenn das der FU hergibt, dann wird versucht diesem Wunsch zu entsprechen.
 
Zurück
Oben