TIA merkwürdiges(?) Verhalten Schnittstelle OUT

Lockenfrosch

Level-1
Beiträge
79
Reaktionspunkte
7
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Leute,

erstmal eine Entschuldigung für den etwas unpräzisen Titel, aber ich wusste nicht wie ich mein Problem in wenigen Worten zusammenfassen sollte (was mich übrigens auch darin hindert die Suchfunktionen effektiv zu nutzen :/ ).
Zu meinen Problem:

Ich habe an der Schnittstelle OUT, eines in SCL geschriebenen FC´s, Dummy-Varaiablen zugewiesen, in der Erwartung, dass dies keinen Effekt auf den Code im Baustein hat. Dummerweise lag ich daneben... Bei einer eindeutigen Zuweisung ist alles im grünen Bereich, nutze ich allerdings 3-mal dieselbe Variable verhält sich das Ganze so:
In Screenshot 2 ist zu sehen, dass die Schnittstelle OUT in den Zeilen 207 bis 211 zugewiesen wird, mit den Variabel aus einer UDT-Structur mit den Namen "DATA". Soweit ist die Welt noch in Ordnung. In den Zeilen 215 / 217 / 219 habe ich ein paar Testvariabelen eingefügt, um den Zustand prüfen zu können. An der Stelle ist auch noch alles ok. Aber dann, etwas tiefer, in den Zeilen 236 und 241 wird der Status, der "DATA"-Variablen, mit diesen auf gelb hinterlegten Fragezeichen zurück gegeben und die IF-Bedingung ist erfüllt, was eigentlich nicht sein dürfte. Die "DATA"-Variablen werden nur lesend bearbeitet, wieso ist die IF-Bedingung auf einmal erfüllt, obwohl die Variable ein paar Zeilen höher den Zustand Null hat, was habe ich falsch gemacht?


SCL_diag.jpg

SCL_diag2.jpg
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Was für eine CPU ist das? Welche TIA-Version?

Sind Deine 3 OUT_...-Variablen tatsächlich in OUT oder vielleicht versehentlich in IN_OUT?
Wie ist #Dummy_Bool deklariert?

Harald
 
Wo ist DATA deklariert?
In der temp Schnittstelle.

Wie werden die Variablen in DATA beschrieben?
Mittels AT-Zuweisung über eine Schleife. Am Anfang des FCs werden sie aus einen DB gelesen und am Ende wieder zurück-geschrieben

Gab es eine Warnung vom SCL-Copmpiler?
Nein.
Wie gesagt, der Baustein funktioniert, es sei denn ich weise 3-mal dieselbe Variable zu, dabei ist es egal in welchen Speicherbereich die Variable liegt

Ein Schreenshot zur visuellen Darstellung der funktionierenden und der nicht funktionierenden Version.
SCL_diag3.jpg
Was für eine CPU ist das?

315-2EH14-0AB0 v3.2.6

Welche TIA-Version?
Tia v13 / SP1

Variablen tatsächlich in OUT oder vielleicht versehentlich in IN_OUT?
Sind als OUT deklariert.

Wie ist #Dummy_Bool deklariert?
In der temp Schnittstelle.


P.S.: Was hat es denn überhaupt mit diesen merkwürdigen Fragezeichen auf gelben Grund auf sich ?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Lockenfrosch

die ??? auf gelbem Grund liefert das Portal, wenn es den Wert nicht besorgen kann. Oder will, in deinem Fall hat ein Entwickler offenbar gedacht, wenn ich schon in der Zeile vorher das Ergebnis anzeige, dann brauch ich doch nicht nochmal den Wert holen.

Übergabe von Parametern ist ein vertracktes Thema. Vor allem bei AS300 und AS400. Bei 1200 und 1500 ist es ein klein wenig "vernünftiger", dafür gibt es Variant -- aber lassen wir das jetzt.

Was passiert bei 300/400 wenn einfache Datentypen (sowas wie BOOL oder INT) an einen FC übergeben werden. Siemens macht bei FC immer eine Übergabe per Referenz, egal ob nun für IN, OUT oder INOUT. D.h. es wird ein Zeiger auf den Speicher gebildet der zu der Variable gehört, die du außen angelegt hast. D.h. alle drei Zeiger zeigen auf #DUMMY_Bool. Egal auf welchen Ausgang du jetzt schreibst, es werden immer alle Ausgänge verändert.

Jetzt kommt es aber auch noch darauf an, was du außen angelegt hast. S. unterscheidet drei verschiedene Zeiger. Kurze mit 32 Bit, mittlere mit 48 Bit und lange mit 80Bit. Die langen kennen wir als ANY. Dir Mittleren als Pointer. Dir kurzen kennen wir als Inhalt der Adressregister AR1 und AR2. Bei der Parameterübergabe werden die kurzen 32Bit Zeiger verwendet.

Das hat aber nun seltsame Effekte. Wenn du einen IN, OUT oder INOUT Parameter mit E, A oder M versorgst, dann zeigt der Zeiger geanu da drauf. Wenn du einen mit TEMP versorgst, dann zeigt der auf L, das aber im aufgerufenen Baustein gar kein L sein kann, denn der hat ja einen eigenen L Bereich, also zeigt der auf V. Also V ist der L vom Aufrufer. Das verhält sich aber immernoch so wie E,A,M.

Richtig seltsam wir es jetzt, wenn du einen INPUT mit einer Konstanten versorgst. Ein Zeiger kann nicht auf Konstanten zeigen. Deshalb wird der Wert in eine unsichtbare TEMP gelegt und nun kommt da der Zeiger drauf. Also drausen denkst du es wäre eine Konstante, drinner darft du aber draufschreiben und die Konstante verändern.

Noch eigenartiger ist es jetzt, wenn du eine Variable aus einem DB übergibst. Auch in diesem Falle, wird eine Kopie im L-Bereich des Aufrufer gemacht. Solange du nicht mit verschiedenen OB arbeitest, verhält sich das harmlos. Vor dem Aufruf wird rein kopiert, hinterher wieder raus.

Wenn du jetzt aber mit verschiedenen OB arbeitest und wärend du im aufgerufenen Baustein bist ein OB-Wechsel stattfindet, dann kann man seltsamens beobachten. Die geschriebenen E,A,M sind auch in der unterbrechenden Ablaufebene sichtbar. Die geschriebenen DBwerte aber nicht. Nach dem was ich bisher erklärt habe, sollte auch klar sein warum.

Falsch verhält sich das System bei der Übergabe von PE und PA. Also den dirketen Peripheriezugriffen. Der 32Bit Zeiger kann nicht zwischen PE und PA unterscheiden. Du legst außen PE an und schreibst dann innen drauf. Da nicht unterschieden wird, hast du jetzt direkt auf PA geschrieben. Ja herrgotsazemt ... es ist dringend von PE und PA Übergabe abzuraten.

Was ich jetzt erklärt habe, gilt für die einfachen Datentypen. So von BOOL bis REAL. Bei String, Array und Struct, wird im TEMP ein für dich unsichtbarer 48Bit Zeiger angelegt und ein 32 Bit Zeiger darauf übergeben. C-Programierer freuen sich ... zwei Sterne Programmierung.
Macht das jetzt einen Unterschied. Ja, denn nun ist das mit den DB Zugriffen bei Unterbrechungen wieder anders. Beim Schreiben wird zwei mal dereferenziert, d.h. der unterbrechende sieht die bereits geschriebenen Werte. Bei den einfachen Datentypen hat er das nicht.

Also was ich erklärt habe sind die Regeln für FC Aufrufe auf 300/400. Bei FB sieht das ganz anders aus. Und bei 1200/1500 gibt es nochmal zwei Sätze von Regeln. Genug verwirrt? Ich denke schon, ich selbst habe ungefähr die ganze V4 (lang ist es her) gebraucht um das raus zu bekommen.

Trotz dieses Wissens, kann ich mir aber den Wert in Zeile 236 auch nicht erklären. DATA wird immer nur gelesen. Was mich jetzt allerdings stutzig macht ... was meinst du mit "einer AT Zuweisung über einer Schleife"

'n schön' Tach auch
HB
 
@hucki
Du hast ja recht, doch ich traue dem TIA nicht. Lieber nochmal hinschauen bzw. nachfragen.
Vielleicht hat irgendein Designer oder Überschlauer festgelegt, daß es manchmal besser aussieht, wenn auch IN_OUT rechts dargestellt werden??! Es werden ja auch Baustein-Übergabeparameter und Strukturmember einfach ausgeblendet/versteckt, vielleicht weil irgendjemand meint, die vollen wahren Details würden die Zielgruppe Programmierer überfordern...

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Daß man bei S7-300/400 FC-Ausgänge im FC nicht lesen soll, weil außen womöglich die selben Variablen angeschlossen sind, das war auch in Step7 classic schon so und ist auch dokumentiert (das geht nur dann gut, wenn am OUT DB-Variablen angeschlossen sind, weil nur diese (im Gegensatz zu E,A,M,L,Px) erst nach Ende des FC geschrieben werden).

Der Witz ist, der TE liest die Ausgänge garnicht. Trotzdem läßt sich das Programm in seinem FC davon beeinflussen, daß am OUT die selbe Variable angeschlossen ist - das ist für mich eindeutig ein Fehler im SCL-Compiler. Das classic-SCL V5.3 hat diesen Bug nicht.

Wie kann man sehen, welchen Code der TIA-SCL-Compiler erzeugt?
Für mich sieht das wie eine dumme missglückte "Optimierungs"-Geschichte aus.

Die IF-Bedingungen in den Zeilen 231, 236 und 241 können fälschlicherweise erfüllt sein, wenn statt der im Quelltext angegebenen Variablen die Kopien dieser Variablen verwendet werden. Vielleicht hat sich einer der Compilerbauer gedacht "Warum umständlich auf die Strukturvariable zugreifen, wenn ich auf eine Kopie der Variable viel einfacher zugreifen kann? - Das kann man doch optimieren!" :( Der Compiler sieht ja nicht, daß sich der Wert der Kopie nach der Zuweisung ändert, weil die OUT-Variablen verschiedene symbolische Namen haben, aber dummerweise draußen die selbe Adresse. (von Multitasking bzw. Alarm-OBs ganz abgesehen) In C kann man solcherart Compiler-Optimierungen mit dem Deklarations-Modifizierer "volatile" verhindern.

Vielleicht kommen die ??? auch genau daher, weil der Compiler in Wahrheit eine andere Variable verwendet als im Quelltext steht?

Verschwinden die ???, wenn Du den FC nur einmal aufrufst?
Vielleicht kann sich das TIA nicht entscheiden, ob es die Werte vom ersten oder zweiten Aufruf des FC anzeigt? ;)

Harald
 
Wenn man als außenstehender Betrachter das so liest: Wo genau muss man jetzt noch verschiedentlichen Mist im TIA erwarten, und sich hinterher darüber freuen daß ein logisch makelloses Programm plötzlich nicht funktioniert ?? Ich frage mich auch, ob es vor diesem Hintergrund etwas bringt, wenn man keine FCs, überhaupt keine temporären Lokaldaten und auch keine Merkerbereiche mehr verwendet, sondern nur noch FBs und DBs nutzt und die Variablen in STAT schreibt ?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Meine Frage wäre als erstes, wie er den FC beobachtet hat. Denn so wie es aussieht wird dieser im Programm mehrfach aufgerufen. Wenn man dann einfach den FC öffnet und in den Online-Status geht (Brille aufsetzen), werden nicht sinnvoll zu interpretierende Werte angezeigt.
Bei Step7 konnte man einen spezifischen FC mit dem aktuellen Lokaldatenstack beobachten, indem man in den Testmodus gewechselt, und dann den FC vom übergeordneten Baustein aus mit Aufrufpfad geöffnet hat.
 
Hallo HelleBarde

vielen Dank für den ausführlichen Input !!!
Aktuell beruhigt es mich etwas, dass ich nicht der Einzige bin der mit dem Systemverhalten etwas "überfordert" ist.

Hallo Lockenfrosch

Trotz dieses Wissens, kann ich mir aber den Wert in Zeile 236 auch nicht erklären. DATA wird immer nur gelesen. Was mich jetzt allerdings stutzig macht ... was meinst du mit "einer AT Zuweisung über einer Schleife"

'n schön' Tach auch
HB

"AT-Überlagerung" wäre wohl korrekt ausgedrück.
SCL_AT.jpg
Vuielleicht ist der Fehler auch hier zu suchen ?!?

Meine Frage wäre als erstes, wie er den FC beobachtet hat. Denn so wie es aussieht wird dieser im Programm mehrfach aufgerufen. Wenn man dann einfach den FC öffnet und in den Online-Status geht (Brille aufsetzen), werden nicht sinnvoll zu interpretierende Werte angezeigt.
Bei Step7 konnte man einen spezifischen FC mit dem aktuellen Lokaldatenstack beobachten, indem man in den Testmodus gewechselt, und dann den FC vom übergeordneten Baustein aus mit Aufrufpfad geöffnet hat.

Ich habe dafür gesorgt das der Baustein nur einmal im Aufruf ist.


P.S.: Ich habe mal ein Ticket bei Siemens erstellt, auch wenn meine Erwartungen nicht sehr groß ausfallen. Die erste Antwort bestätigt dies auch, tendenziell. Aber wer weiss...

Siemens Feedback:

>>Sie benutzen temporäre Varriablen lesend, ohne vorab diese zu schreiben.

>>Bitte sehen Sie hierzu die Online-Hilfe (Screenshot):

>>Variablen, die zum Speichern von temporären Zwischenergebnissen dienen. Temporäre Daten bleiben nur für einen Zyklus erhalten. Wenn Sie temporäre Lokaldaten verwenden, müssen Sie sicherstellen, dass die Werte >>innerhalb des Zyklus geschrieben werden, in dem Sie sie lesen wollen. Ansonsten sind die Werte zufällig.



Meine Antwort:

>>Aus meiner Sicht werden die temporären Variablen am Anfang jedes Zyklus beschrieben. Dies geschieht indirekt mittels AT Überlagerung (siehe Screenshot).
>>Für mich ist aktuell unklar wie es zu einen nicht eindeutigen Zustand der temporäre Variable kommen könnte und insbesondere wie die Schnittstelle OUT auf diese rückwirken soll.
 
Zuletzt bearbeitet:
Bastle ich den Code wie auf den Screenshot um, funktioniert es übrigens (selbst der Status passt). Meiner Meinung nach rückt das den Compiler noch mehr in den Fokus.
.SCL_diag4.jpg
 
Zuviel Werbung?
-> Hier kostenlos registrieren
>>Sie benutzen temporäre Varriablen lesend, ohne vorab diese zu schreiben.
>>Bitte sehen Sie hierzu die Online-Hilfe (Screenshot):
:ROFLMAO: Typisch Siemens-Hotline. Dort sitzen übrigens gar keine Siemens-Leute, es ist eine outgesourcte GmbH mit lustigen irgendwelchen Programmierern, die mal das Handbuch gründlich gelesen haben. Wenn Du Ihnen beharrlich fragen stellts, auf die sie nicht weiter zu antworten wissen, dann erstellen die einen Service-Request dann in der Entwicklungsabteilung von Siemens, und von dort kommt so nach 1-2 Monaten eine inhaltliche Antwort, in der Regel auf English.
 
Hast du schonmal den AWL-Code der von deinem Baustein erzeugt wird angesehen, oder hast du kein Step7 V5.x mehr? Wenn möglich kannst du den Quellcode auch hier reinstellen, kannst ihn ja etwas einkürzen wenn du nicht alles veröffentlichen willst.
 
...dann erstellen die einen Service-Request dann in der Entwicklungsabteilung von Siemens...

Da bin ich gestern schon gelandet. Der gute Herr hat mich gebeten den Code einzukürzen um ihn die Diagnose zu erleichtern. Das habe ich auch gemacht....
Für alle die es interessiert, so sieht das ganze etwas Diagnosefreundlicher aus:
Beschaltung von außen:
SCL_diag_new_1.jpg
Der gesamte Code:
SCL_diag_new_2.jpg
Online:
SCL_diag_new_3.jpg

Hast du schonmal den AWL-Code der von deinem Baustein erzeugt wird angesehen, oder hast du kein Step7 V5.x mehr?

Grad schnell gemacht, leider ist meine Zeit grad begrenzt um ihn mir im Detail anzuschauen.

Code:
FUNCTION FC 999 : VOID
TITLE =
VERSION : 0.1


VAR_OUTPUT
  OUT0 : BOOL ;    
  OUT1 : BOOL ;    
  OUT2 : BOOL ;    
  OUT3 : INT ;    
END_VAR
VAR_TEMP
  TEMP4 : STRUCT     
   TEMP5 : BOOL ;    
   TEMP6 : BOOL ;    
   TEMP7 : BOOL ;    
   TEMP8 : BOOL ;    
   TEMP9 : BOOL ;    
   TEMP10 : BOOL ;    
   TEMP11 : BOOL ;    
   TEMP12 : BOOL ;    
   TEMP13 : BOOL ;    
   TEMP14 : BOOL ;    
   TEMP15 : BOOL ;    
   TEMP16 : BOOL ;    
   TEMP17 : BOOL ;    
   TEMP18 : BOOL ;    
   TEMP19 : BOOL ;    
   TEMP20 : BOOL ;    
  END_STRUCT ;    
  TEMP21 : INT ;    
  TEMP22 : WORD ;    
END_VAR
BEGIN
NETWORK
TITLE =

      SET   ; 
      SAVE  ; 
      =     L      6.0; 
      L     W#16#3E7; 
      T     #TEMP22; 
      L     0; 
      T     #TEMP21; 
M002: L     #TEMP21; 
      L     15; 
      <=I   ; 
      SPBN  M001; 
      TAK   ; 
      ITD   ; 
      T     LD     8; 
      T     LD    12; 
      L     #TEMP22; 
      T     LW    16; 
      AUF   DB [LW 16]; 
      LAR1  LD     8; 
      U     DBX [AR1,P#0.0]; 
      LAR1  LD    12; 
      =     L [AR1,P#0.0]; 
      L     1; 
      L     #TEMP21; 
      +I    ; 
      T     #TEMP21; 
      SPA   M002; 
M001: CLR   ; 
      U     #TEMP4.TEMP5; 
      =     #OUT0; 
      U     #TEMP4.TEMP6; 
      =     #OUT1; 
      U     #TEMP4.TEMP7; 
      =     #OUT2; 
      L     0; 
      T     #OUT3; 
      U     #OUT0; 
      SPBN  M003; 
      L     100; 
      T     #OUT3; 
M003: CLR   ; 
      U     #OUT1; 
      SPBN  M004; 
      L     101; 
      T     #OUT3; 
M004: CLR   ; 
      U     #OUT2; 
      SPBN  M005; 
      L     102; 
      T     #OUT3; 
M005: L     0; 
      T     #TEMP21; 
M007: L     #TEMP21; 
      L     15; 
      <=I   ; 
      SPBN  M006; 
      L     #TEMP22; 
      T     LW    12; 
      L     #TEMP21; 
      ITD   ; 
      T     LD     8; 
      L     #TEMP21; 
      ITD   ; 
      LAR1  ; 
      U     L [AR1,P#0.0]; 
      AUF   DB [LW 12]; 
      LAR1  LD     8; 
      =     DBX [AR1,P#0.0]; 
      L     1; 
      L     #TEMP21; 
      +I    ; 
      T     #TEMP21; 
      SPA   M007; 
M006: CLR   ; 
      U     L      6.0; 
      SAVE  ; 
END_FUNCTION

kannst ihn ja etwas einkürzen wenn du nicht alles veröffentlichen willst.
Falls jemand interesse hat lade ich auch mein TIA Testprojekt hoch, da bin ich nicht zimperlich, das bissel Code ist kein Hexenwerk.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Für mich sieht das wie eine dumme missglückte "Optimierungs"-Geschichte aus.

Die IF-Bedingungen in den Zeilen 231, 236 und 241 können fälschlicherweise erfüllt sein, wenn statt der im Quelltext angegebenen Variablen die Kopien dieser Variablen verwendet werden. Vielleicht hat sich einer der Compilerbauer gedacht "Warum umständlich auf die Strukturvariable zugreifen, wenn ich auf eine Kopie der Variable viel einfacher zugreifen kann? - Das kann man doch optimieren!" :(

Genau diesen Mist hat der Compiler auch gemacht:
Code:
      U     #TEMP4.TEMP5; 
      =     #OUT0; 
      U     #TEMP4.TEMP6; 
      =     #OUT1; 
      U     #TEMP4.TEMP7; 
      =     #OUT2; 
      L     0; 
      T     #OUT3; 

      U     [COLOR="#FF0000"][B]#OUT0[/B][/COLOR];        [COLOR="#0000FF"]//falsch! Das muß: U #TEMP4.TEMP5[/COLOR]
      SPBN  M003; 
      L     100; 
      T     #OUT3; 
M003: CLR   ; 
      U     [COLOR="#FF0000"][B]#OUT1[/B][/COLOR];        [COLOR="#0000FF"]//falsch! Das muß: U #TEMP4.TEMP6[/COLOR]
      SPBN  M004; 
      L     101; 
      T     #OUT3; 
M004: CLR   ; 
      U     [COLOR="#FF0000"][B]#OUT2[/B][/COLOR];        [COLOR="#0000FF"]//falsch! Das muß: U #TEMP4.TEMP7[/COLOR]
      SPBN  M005; 
      L     102; 
      T     #OUT3; 
M005: L     0;

Es war natürlich nichts mit "uninitialisierte TEMP-Variablen lesen".

Sag Siemens, die sollen den Bug in ihrem SCL-Compiler suchen und beseitigen.

Harald
 
Hallo zusammen,
ich stehe gerade auf dem Schlauch. Ich versuche, das Problem im Simulator nachzuvollziehen. Wie komme ich im TIA-Portal an den vom SCL erzeugten AWL-Code?
Stichwort: Früher war alles einfacher...

Was vermutlich mit der von PN/DP entdeckten "Optimierung" zu tun hat:
Wenn man vor den IF-Abfragen einen Pseudo-Code wie etwa
#Data.Test_0 := #Data.Test_0;
schreibt, dann funktioniert die Diagnose.

Gruß
JSE
 
Erstmal Danke an alle für die Hilfestellungen !!!

Ich habe gerade mit Siemens gesprochen und nach langen hin und her hat er mir zustimmen müßen das der Compiler murx macht.
Und zwar gleich in doppelter Ausführung, da der Compiler mittels setzen eines Hakens, oh Wunder, dazu bewegt werden kann alles richtig zu übersetzen, auch wenn die Hakenbeschreibung nicht darauf schließen läßt, dass etwas anderst kompiliert wird.

Ist der Haken "Erweiterte Statusinformation erstellen" gesetzt
SCL_diag_new_5.jpg
sieht der AG-Abzug so aus:
SCL_diag_new_4.jpg


Auch führt der Haken dazu, dass die schwarz/gelben Fragezeichen verschwinden und der Status richtig angezeigt wird.
Naja, die Entwicklungsabteilung wird sich jetzt eingehend damit beschäftigen und sich dann bei mir melden.
 
Zuletzt bearbeitet:
Zurück
Oben