Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Seite 1 von 4 123 ... LetzteLetzte
Ergebnis 1 bis 10 von 32

Thema: merkwürdiges(?) Verhalten Schnittstelle OUT

  1. #1
    Registriert seit
    23.01.2006
    Beiträge
    75
    Danke
    17
    Erhielt 7 Danke für 4 Beiträge

    Standard


    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
    Zitieren Zitieren merkwürdiges(?) Verhalten Schnittstelle OUT  

  2. #2
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.163
    Danke
    921
    Erhielt 3.286 Danke für 2.655 Beiträge

    Standard

    Wo ist DATA deklariert?
    Wie werden die Variablen in DATA beschrieben?

    Gab es eine Warnung vom SCL-Copmpiler?

    Harald
    Es ist immer wieder überraschend, wie etwas plötzlich funktioniert, sobald man alles richtig macht.

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  3. #3
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.163
    Danke
    921
    Erhielt 3.286 Danke für 2.655 Beiträge

    Standard

    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
    Es ist immer wieder überraschend, wie etwas plötzlich funktioniert, sobald man alles richtig macht.

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  4. #4
    Registriert seit
    23.01.2006
    Beiträge
    75
    Danke
    17
    Erhielt 7 Danke für 4 Beiträge

    Standard

    Zitat Zitat von PN/DP Beitrag anzeigen
    Wo ist DATA deklariert?
    In der temp Schnittstelle.

    Zitat Zitat von PN/DP Beitrag anzeigen
    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

    Zitat Zitat von PN/DP Beitrag anzeigen
    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
    Zitat Zitat von PN/DP Beitrag anzeigen
    Was für eine CPU ist das?
    315-2EH14-0AB0 v3.2.6

    Zitat Zitat von PN/DP Beitrag anzeigen
    Welche TIA-Version?
    Tia v13 / SP1

    Zitat Zitat von PN/DP Beitrag anzeigen
    Variablen tatsächlich in OUT oder vielleicht versehentlich in IN_OUT?
    Sind als OUT deklariert.

    Zitat Zitat von PN/DP Beitrag anzeigen
    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 ?

  5. #5
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.163
    Danke
    921
    Erhielt 3.286 Danke für 2.655 Beiträge

    Standard

    "???" --> Du sollst Siemens anrufen

    Harald
    Es ist immer wieder überraschend, wie etwas plötzlich funktioniert, sobald man alles richtig macht.

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  6. #6
    Registriert seit
    24.04.2013
    Beiträge
    309
    Danke
    23
    Erhielt 160 Danke für 88 Beiträge

    Standard

    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

  7. Folgende 8 Benutzer sagen Danke zu HelleBarde für den nützlichen Beitrag:

    Blockmove (01.02.2015),Joe (02.02.2015),Lockenfrosch (02.02.2015),Markus (02.02.2015),Pipboy (04.02.2015),Ralle (02.02.2015),RGerlach (02.02.2015),rostiger Nagel (01.02.2015)

  8. #7
    Registriert seit
    27.06.2009
    Ort
    am Nordharz
    Beiträge
    3.713
    Danke
    443
    Erhielt 914 Danke für 739 Beiträge

    Standard

    Zitat Zitat von PN/DP Beitrag anzeigen
    Sind Deine 3 OUT_...-Variablen tatsächlich in OUT oder vielleicht versehentlich in IN_OUT?
    Bei In_OUT wären sie doch auf der linken Eingangsseite des FCs und nicht auf der rechten, oder?

  9. Folgende 2 Benutzer sagen Danke zu hucki für den nützlichen Beitrag:

    PN/DP (01.02.2015),UniMog (31.01.2015)

  10. #8
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.163
    Danke
    921
    Erhielt 3.286 Danke für 2.655 Beiträge

    Standard

    @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
    Es ist immer wieder überraschend, wie etwas plötzlich funktioniert, sobald man alles richtig macht.

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  11. #9
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.163
    Danke
    921
    Erhielt 3.286 Danke für 2.655 Beiträge

    Standard

    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
    Es ist immer wieder überraschend, wie etwas plötzlich funktioniert, sobald man alles richtig macht.

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  12. Folgende 2 Benutzer sagen Danke zu PN/DP für den nützlichen Beitrag:

    Draco Malfoy (01.02.2015),Lockenfrosch (02.02.2015)

  13. #10
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.163
    Danke
    921
    Erhielt 3.286 Danke für 2.655 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von PN/DP Beitrag anzeigen
    Wie kann man sehen, welchen Code der TIA-SCL-Compiler erzeugt?
    Da hier eine S7-300 programmiert wird, könnte man den Baustein in eine CPU laden und mit Step7 classic aus der CPU herausladen und anschauen. Falls es in dem TIA keine bessere Möglichkeit gibt.

    Harald
    Es ist immer wieder überraschend, wie etwas plötzlich funktioniert, sobald man alles richtig macht.

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  14. Folgender Benutzer sagt Danke zu PN/DP für den nützlichen Beitrag:

    Lockenfrosch (03.02.2015)

Ähnliche Themen

  1. Merkwürdiges beim Referenzdaten Erzeugen
    Von Werner v. Siemens im Forum Simatic
    Antworten: 5
    Letzter Beitrag: 27.10.2008, 09:54
  2. Merkwürdiges Problem
    Von zwerg77 im Forum Simatic
    Antworten: 5
    Letzter Beitrag: 27.11.2007, 13:15
  3. Merkwürdiges Profibus Problem ?!
    Von dietere im Forum Feldbusse
    Antworten: 5
    Letzter Beitrag: 07.11.2007, 11:42
  4. merkwürdiges phänomen ?
    Von volker im Forum Simatic
    Antworten: 10
    Letzter Beitrag: 27.09.2006, 08:40
  5. Antworten: 2
    Letzter Beitrag: 21.12.2005, 14:29

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •