Step 7 Strukturen an Funktionen übergeben

patx · 31 August 2016

Welche SFC "SCALE" verwendest du? Nach meinem Verständnis müsstes du doch die Funktion "NORM-X" verwenden ???

RONIN · 31 August 2016

Ralle schrieb:
Vielleicht löscht du noch mal den FC105 (Scale) und ziehst ihn aus der Library in deinen Bausteinordner.

patx schrieb:
Welche SFC "SCALE" verwendest du? Nach meinem Verständnis müsstes du doch die Funktion "NORM-X" verwenden ???

So wie ich das lese...

SPS-EK schrieb:
So habe es weiter eingegrenzt und herausgefunden wann die CPU in Stop springt und zwar wenn ich die High und Low limit werte auf 16220.0 und -2700.0 setze.

Ist das vermutlich was selbst gebautes... sicher kein FC105 (da HL, LL nicht einstellbar)....

@TE: Versuch mal dein Problem zu reduzieren...
Reduzier den Programm mal auf das Minimum was zum Absturz führt. (Vielleicht ist das schon die Analogfunktion alleine)
Das könntest du ja hier einstellen. Zumindest könntest du den Code der Skalierfunktion zeigen die bei Einstellung 16220.0 / -2700.0 zum CPU-Stop führt....

SPS-EK · 31 August 2016

RONIN schrieb:
So wie ich das lese...

Ist das vermutlich was selbst gebautes... sicher kein FC105 (da HL, LL nicht einstellbar)....

@TE: Versuch mal dein Problem zu reduzieren...
Reduzier den Programm mal auf das Minimum was zum Absturz führt. (Vielleicht ist das schon die Analogfunktion alleine)
Das könntest du ja hier einstellen. Zumindest könntest du den Code der Skalierfunktion zeigen die bei Einstellung 16220.0 / -2700.0 zum CPU-Stop führt....

@ Ronin: Das Problem habe ich schon durch sukzessives ausklammern eingeschränkt.

@ All: Es liegt an der SCALE-SFC(FC105). Die hat sehr wohl ein HI-LIM und ein LOW-LIM für die Skalierung der Variable, ohne das kann man ja auch nicht skalieren. Die Probleme treten nur bei den zuvor beschriebenen Skalierungswerten auf. Der Code steht auf Seite eins, in der Funktion wird der FC105 gecallt und die Werte entsprechend Übergeben. Ausser einer weiteren Fehlerauswertung wird darin nichts gemacht und daran kann es nicht liegen, da es bei den anderen Analogwertverarbeitungen mit der selben Funktion funktioniert.
Ich reiche ja den Fehlercode des FC105 durch in mein FB dennoch wird kein Fehler angezeigt sondern die CPU springt in STOP.

Ralle · 31 August 2016

Wenn du auf den FC105 gehst und dann "F1" drückst, kommt eine rel. ausführliche Hilfe. Darin ist auch die Formel, nach welcher im FC 105 scaliert wird.
Das würde ich mal nachprogrammieren (Kann man eh gut gebrauchen, wenn mal "nicht"-Siemens-Analogwerte scaliert werden sollen, z.B. von einer Beckhoff-Klemme).
Dann sollte es funktionieren oder aber du kommst damit diesem ominösen Fehler auf die Spur.

PS: Hier mal nachgereicht ein etwas älterer Nachbau des FC105, als Quelle:

Code:

FUNCTION FC 105 : VOID
TITLE =Einlesen Analog Werte
//Skalierung eines Rohwertes
//Rohwert einstellbar 0..32000 (INT)
//Ausgangswert einstellbar 0,0 bis ... (REAL)
//
//OUT =  [ ((FLOAT (IN) – K1)/(K2–K1)) * (HI_LIM–LO_LIM)] + LO_LIM
AUTHOR : x2
NAME : Analog
VERSION : 1.1




VAR_INPUT
  IN_EW : WORD ;    //IN
  OG_Rohwert : INT ;    //K2 Oberer Wert Rohwert Eingangswort INT
  UG_Rohwert : INT ;    //K1 Oberer Wert Rohwert Eingangswort INT
  OG_Ausgang : REAL ;    //HI_LIM Oberer Analogausgangswert REAL
  UG_Ausgang : REAL ;    //LO_LIM Unterer Analogausgangswert REAL
END_VAR
VAR_OUTPUT
  OUT : REAL ;    //Ergebniss Ausgangswert REAL
END_VAR
VAR_TEMP
  OG_Rohwert_REAL : REAL ;    
  UG_Rohwert_REAL : REAL ;    
  K2wenigerK1 : REAL ;    //K2 - K1
  HI_LIM_LO_LIM : REAL ;    //HI LIM - LO LIM
  Zwischen_1 : REAL ;    
END_VAR
BEGIN
NETWORK
TITLE =Anfang


//OUT =  [ ((FLOAT (IN) – K1)/(K2–K1)) * (HI_LIM–LO_LIM)] + LO_LIM


NETWORK
TITLE =Wandelung OG/UG Rohwert in REAL


      L     #OG_Rohwert; 
      ITD   ; //16bit INT --> 32bit INT
      DTR   ; //32bit INT --> 32 REAL
      T     #OG_Rohwert_REAL; //32bit REAL


      L     #UG_Rohwert; 
      ITD   ; //16bit INT --> 32bit INT
      DTR   ; //32bit INT --> 32 REAL
      T     #UG_Rohwert_REAL; //32bit REAL


NETWORK
TITLE =UG Rohwert - OG Rohwert, K2-K1


      L     #OG_Rohwert_REAL; //32bit REAL
      L     #UG_Rohwert_REAL; //32bit REAL
      -R    ; 
      T     #K2wenigerK1; 


NETWORK
TITLE =HI_LIM–LO_LIM


      L     #OG_Ausgang; 
      L     #UG_Ausgang; 
      -R    ; 
      T     #HI_LIM_LO_LIM; 
NETWORK
TITLE =Zwischen 1


      L     #IN_EW; //Input
      ITD   ; //16bit INT --> 32bit INT
      DTR   ; //32bit INT --> 32 REAL
      L     #UG_Rohwert_REAL; // - K1
      -R    ; 
      L     #K2wenigerK1; // : K2-K1
      /R    ; 
      T     #Zwischen_1; //= ((FLOAT (IN) – K1)/(K2–K1))




NETWORK
TITLE =OUT


      L     #Zwischen_1; 
      L     #HI_LIM_LO_LIM; // =  [ #Zwischen_1 * (HI_LIM–LO_LIM)]
      *R    ; 
      L     #UG_Ausgang; //  + LO_LIM
      +R    ; 
      T     #OUT; // =  [ ((FLOAT (IN) – K1)/(K2–K1)) * (HI_LIM–LO_LIM)] + LO_LIM


END_FUNCTION

RONIN · 31 August 2016

SPS-EK schrieb:
@ All: Es liegt an der SCALE-SFC(FC105).
Die hat sehr wohl ein HI-LIM und ein LOW-LIM für die Skalierung der Variable, ohne das kann man ja auch nicht skalieren

Ah sorry, ich dachte dass du mit dem HighLimits/LowLimits (16220.0 und -2700.0) den Skalierbereich auf der Eingangsseite gemeint hast, der ist ja bei FC105 fest auf 0-27648 bzw. +/-27648.
Du hast aber ganz normal die Skaliergrenzen für den Ausgangswert gemeint... My Bad.

SPS-EK schrieb:
Die Probleme treten nur bei den zuvor beschriebenen Skalierungswerten auf. Der Code steht auf Seite eins, in der Funktion wird der FC105 gecallt und die Werte entsprechend Übergeben. Ausser einer weiteren Fehlerauswertung wird darin nichts gemacht und daran kann es nicht liegen, da es bei den anderen Analogwertverarbeitungen mit der selben Funktion funktioniert.
Ich reiche ja den Fehlercode des FC105 durch in mein FB dennoch wird kein Fehler angezeigt sondern die CPU springt in STOP.

Könntest du das mal als Mini-Projekt hochladen, dann könnte man das eventuell selber auf einer CPU probieren...

SPS-EK · 3 September 2016

Ralle schrieb:
Wenn du auf den FC105 gehst und dann "F1" drückst, kommt eine rel. ausführliche Hilfe. Darin ist auch die Formel, nach welcher im FC 105 scaliert wird.
Das würde ich mal nachprogrammieren (Kann man eh gut gebrauchen, wenn mal "nicht"-Siemens-Analogwerte scaliert werden sollen, z.B. von einer Beckhoff-Klemme).
Dann sollte es funktionieren oder aber du kommst damit diesem ominösen Fehler auf die Spur.

PS: Hier mal nachgereicht ein etwas älterer Nachbau des FC105, als Quelle:

Code:

FUNCTION FC 105 : VOID TITLE =Einlesen Analog Werte //Skalierung eines Rohwertes //Rohwert einstellbar 0..32000 (INT) //Ausgangswert einstellbar 0,0 bis ... (REAL) // //OUT = [ ((FLOAT (IN) – K1)/(K2–K1)) * (HI_LIM–LO_LIM)] + LO_LIM AUTHOR : x2 ...

Danke Ralle, für den Tipp. Die Formel habe ich dort gefunden.
Was meinst du mit "nicht Siemens Analogwert"? Zählen darunter auch 4-20mA Geber die nicht von Siemens stammen?
Wobei mich das wundern würde, wir haben noch nie Probleme mit dem FC105 und egl welchen 4-20mA oder mV Gebern gehabt.

RONIN schrieb:
Ah sorry, ich dachte dass du mit dem HighLimits/LowLimits (16220.0 und -2700.0) den Skalierbereich auf der Eingangsseite gemeint hast, der ist ja bei FC105 fest auf 0-27648 bzw. +/-27648.
Du hast aber ganz normal die Skaliergrenzen für den Ausgangswert gemeint... My Bad.

Könntest du das mal als Mini-Projekt hochladen, dann könnte man das eventuell selber auf einer CPU probieren...

Genau, komisch ist nur das die Funktion mir den Fehlercode nicht in den FB übergibt sondern direkt auf Stop springt wenn der Wert wie beschrieben oder 32767 ist. Dabei müsste mir die Funktion eigentlich den Fehlercode von Drahtbruch durch geben.

Das Miniprojekt wird schwierig, da viel in dem FB gemacht wird und das ganze Projekt schon etwas umfangreicher ist.

@ All: Mittlerweile verursacht nur noch ein Wert Probleme, ich habe noch eine Fehlerhaft Überlagerte Adressierung gehabt :icon_confused: Habt ihr noch ein Tipp was es sein könnte?

Ralle · 4 September 2016

Mit "Siemens-Analogwert" meine ich die Siemens-Hardware. Diese gehen im Rohwert von 0-27648, genau mit diesen Werten arbeitet auch der originale FC 105 von Siemens.
Wenn man z.B.Beckhoff-Karten verwendet, muß man anders skalieren, der Rohwert geht ja nach Karte bis 32000, bzw. die Karte kann auch ganz anders konfigureirt werden.
Dann kann man mit dem FC105 von Siemens nicht viel anfangen, sondern muß selbst rechnen. Das macht der von mir gepostete FC105.

SPS-EK · 12 September 2016

Also ich finde das Problem nicht, wieso bei dem einen Analogwert die CPU auf Stop geht.

Was mir gerade auffällt ist das Thema "lokale Fehlerbehandlung", diese habe ich für die Analogkonvertierungsfunktion nicht aktiviert sondern gebe nur den Fehlercode von FC105 in den aufrufenden Baustein am Ende zurück.

Code:

// END ====================================================================================================================================
// Return functionvalue
#analogue_input_converting := #t_av_scale_error_code;

Könnte es damit zusammenhängen?

Laut Hilfe wird bei Lesefehler

"Die Bearbeitung des Programms wird mit dem Ersatzwert "0" fortgesetzt."

In der Step 7 Pro Programmierleitfaden wird aber geschrieben:

CPU S7-1500:
– Bei einem Programmierfehler wechselt die CPU in den Betriebszustand STOP und
schreibt einen Eintrag in den Diagnosepuffer.
– Bei einem Peripheriezugriffsfehler bleibt die CPU im Betriebszustand RUN und schreibt
einen Eintrag in den Diagnosepuffer.

PN/DP · 12 September 2016

SPS-EK schrieb:
@ All: Mittlerweile verursacht nur noch ein Wert Probleme, ich habe noch eine Fehlerhaft Überlagerte Adressierung gehabt :icon_confused: Habt ihr noch ein Tipp was es sein könnte?

SPS-EK schrieb:
Also ich finde das Problem nicht, wieso bei dem einen Analogwert die CPU auf Stop geht.

Vielleicht noch eine weitere "Fehlerhaft Überlagerte Adressierung"?

Warum genau geht die CPU in STOP? --> siehe Diagnosepuffer der CPU
Wo genau geht die CPU in STOP? --> siehe Diagnosepuffer der CPU oder ggf. die Fehlerstelle eingrenzen durch stückweises deaktivieren von Code

SPS-EK schrieb:
Das Miniprojekt wird schwierig, da viel in dem FB gemacht wird und das ganze Projekt schon etwas umfangreicher ist.

Ist das wirklich so schwer, den Programmcode des einen FB soweit zu reduzieren, daß er vorzeigbar wird? Vielleicht verschwindet ja auch der Fehler beim Reduzieren - dann schau, was Du entfernt hast.

Harald

SPS-EK · 13 September 2016

Hallo PN/DP,

danke für dein Beitrag.

Ich habe den Code schon bis zu dem FC-Aufruf auskommentiert und nur noch meine Analogwertumrechnung aktiv gehabt und die CPU geht in Stop.
Diese Funktion wird mehrmals in dem FB aufgerufen und macht nur bei dem einen Wert ein Fehler. Die Adrsssierung stimmt, habe ich nun auch schon 3 mal geprüft.
Den Diagnosepuffer kann ich gerade nicht auswerten, wurde aber hier schonmal gepostet.

Das einzige was mir noch einfällt, ist das es mit der "lokalen Fehlerbehandlung" zu tun haben könnte. Diese habe ich inaktiv.

SPS-EK · 16 Oktober 2016

Hallo liebe Helfer,

ich wollte mich nochmal melden, da ich das Problem lokalisiert habe.
Bei der Auswertung eines Wertes hat sich durch eine weitere Abfrage eine Schleife gebildet wodurch die Zykluszeit anstieg und die CPU in Stop ging. Aufgefallen ist das mir, als der Analogwert verschiede Prozesswerte hatte und einmal funktionierte der Korrekte Ablauf udn die CPU ging nicht in Stop und hin und wieder auch nicht.

Danke nochmal an alle für die Infos und Hilfestellungen sowie Tipps

Abseits dessen habe ich dennoch ein paar Fragen, wie macht ihr denn die Fehlerauswertung von selbst geschriebenen Funtionen?
Gibt es da ein Fred der sich lohnt anzuschauen?

Julian1234 · 25 Oktober 2022

Hallo Leute,
ich habe auch diese Ereignis-ID: 16# 02:3500.
Dieses Problem, taucht nur sporadisch auf, d.h die CPU läuft teilweise 5 Monate, danach geht sie auf Stopp. Ich habe bereits die Zykluszeit erhöht, den OB 80 eingefügt und den RE_TRIGR eingefügt. Hatte jemand schonmal so ein ähnliches Problem?

DeltaMikeAir · 25 Oktober 2022

Julian1234 schrieb:
Hallo Leute,
ich habe auch diese Ereignis-ID: 16# 02:3500.
Dieses Problem, taucht nur sporadisch auf, d.h die CPU läuft teilweise 5 Monate, danach geht sie auf Stopp. Ich habe bereits die Zykluszeit erhöht, den OB 80 eingefügt und den RE_TRIGR eingefügt. Hatte jemand schonmal so ein ähnliches Problem?

Welche CPU, welche Firmwareversion?
Diagnosespeicher der CPU mal hier einstellen.

Julian1234 · 25 Oktober 2022

es handelt sich um eine 6ES7 512-1DK01-0AB0 mit der Firmware V2.8
Ich habe Momentan nur ein Bild der Fehlermeldungen

DeltaMikeAir · 25 Oktober 2022

Dann solltest du dich evtl. mal auf die Suche nach Schleifen begeben. Hast du irgendwo WHILE verwendet ?

Julian1234 · 25 Oktober 2022

Ja ich habe eine WHILE Schleife drinnen, diese wird aber regelmäßig durchlaufen. Ich habe aber das Problem immer erst nach 4-6 Monaten.

DeltaMikeAir · 25 Oktober 2022

Julian1234 schrieb:
Ja ich habe eine WHILE Schleife drinnen, diese wird aber regelmäßig durchlaufen. Ich habe aber das Problem immer erst nach 4-6 Monaten.

Zeig doch mal den CODE der Schleife

Und außerdem, für was braucht man in einer SPS eine WHILE Schleife? Ich würde sagen, dass zu >90% Wahrscheinlichkeit das Problem an dieser Schleife liegt

PN/DP · 25 Oktober 2022

Julian1234 schrieb:
Ja ich habe eine WHILE Schleife drinnen, diese wird aber regelmäßig durchlaufen. Ich habe aber das Problem immer erst nach 4-6 Monaten.

Vielleicht wird die Schleife normalerweise nur 10 mal durchlaufen und im Problemfall zigtausend mal? Oder die WHILE-Bedingung bleibt immer erfüllt und die Schleife endet nie? Welche Bedingung hält die Schleife am laufen, was muß passieren damit die Schleife endet?

Harald

PN/DP · 25 Oktober 2022

DeltaMikeAir schrieb:
für was braucht man in einer SPS eine WHILE Schleife?

z.B. Daten suchen in einem Speicherbereich

DeltaMikeAir · 25 Oktober 2022

PN/DP schrieb:
z.B. Daten suchen in einem Speicherbereich

Ja, z.b.
Ich mache das mit einer FOR Schleife und dann beim Fund EXIT.
While benutze ich grundsätzlich nicht.

Aber das muss ja nichts heißen.

Step 7 Strukturen an Funktionen übergeben

Level-1

Level-3

Level-1

Super-Moderator , User des Jahres 2006-2007

Level-3

Level-1

Super-Moderator , User des Jahres 2006-2007

Level-1

User des Jahres 2011-2013; 2015-2017; 2020-2022

Level-1

Level-1

Level-2

User des Jahres 2018; 2023

Level-2

User des Jahres 2018; 2023

Level-2

User des Jahres 2018; 2023

User des Jahres 2011-2013; 2015-2017; 2020-2022

User des Jahres 2011-2013; 2015-2017; 2020-2022

User des Jahres 2018; 2023

Similar threads

Wir schützen deine Privatsphäre