SCL Zähler/Timerproblem

bayernburn

Level-1
Beiträge
38
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Liebes SPS Forum,

ich bin beim Programmieren mit SCl noch ziemlich neu und bei mir ist folgendes Problem aufgetreten.
Ich habe mir eine SCL Quelle (FC) erstellt, die mir verschiedenste Pulse erzeugt. Wenn ich diesen FC alleine im OB1 aufrufe, funktioniert dieser einwandfrei.
Wenn ich jedoch einen weiteren von mir erstellten FC (auch in SCL) im OB1 aufrufe, dann funktioniert mein Pulse FC nicht mehr. Hier ist das Problem, dass mein verlängerter Impuls nicht mehr automatisch neu startet und somit der ganze weitere Verlauf des Programmes stehen bleibt.

Im zweiten FC wird die Kommunikation zw. SPS und Visualisierung realisiert.

Bei uns in der Fa. ist es so, dass alle unsere Standardfunktionen bereits in AWL existent sind und auch zu 100% funktionieren.
Aufgrund des "neuen" TIA Portals und dem Wegfall der AWL Sprache sind wir nun gezwungen, alle Standardfunktionen auf SCL umzustellen, was in anbetracht unserer vielen Standardfunktionen, sehr sehr umfangreich ist.

Ich verwende zum Programmieren der SCL Quellen den SCL Editor V5.3+SP5 und Step7 V5.5.
Als Test-CPU habe ich eine CPU319 laufen.

Hier noch ein Auszug aus dem Programmcode.

Code:
//Some internal functions:
//for example an output called -SYS_CYCLUSTIME is set and reset (all 256
//cyclus). This is a easy way to measure the cyclustime from the RS-Processor
//at any time.
//There is also a creation from a multible takt (which is used for lamps and
//other time sensitive funktions).
//Also the management for the so called LongTimers is calculated here.
//
//Diverse interne Funktionen:
//zum Beispiel wird ein Blinktakt mit verschiedenen Taktraten erzeugt (wird
//fuer Lampensteuerung oder Zeitschaltuhren benoetigt). Ausserdem wird auf
//einfache Weise die Zykluszeit des RS-Prozessors gemessen und auf einen Ausgang
//geschaltet (nach jeweils 256 Zyklen).
//FC3
FUNCTION "System" : VOID
 TITLE ='Internal Actions'
// KNOW_HOW_PROTECT
 AUTHOR  :Maier
 FAMILY  :Syst
 NAME    :General
 VERSION :'1.0'

  VAR_TEMP      
   SplitDummy :BYTE;                    // do not enter any var before !
   SplitDummy2:BYTE;                      
   SplitDummy3:BYTE;                       
   BufferB    :BYTE;
   BufferI    :INT;
   BufferW    :WORD;
   tBCD       :S5TIME;   
   tBCD2      :S5TIME;    
   tBCD_Cnt   :WORD;
   tBCD_Cnt2  :WORD; 
   tBCD_Cnt3  :WORD; 
   tBCD_Cnt4  :WORD;   
   tBCD_Cnt_B :BYTE;
   tBCD_Cnt_B2:BYTE;
   tBCD_Cnt_B3:BYTE;
   tBCD_Cnt_B4:BYTE;           
   t_Out      :BOOL;
   t_Out2     :BOOL;
   t_Out3     :BOOL;   
   Reset_Cnt  :BOOL;
   Reset_Cnt3 :BOOL; 
   Reset_Cnt4 :BOOL;  
   t_Cnt_Out  :WORD;
   t_Cnt_Out2 :WORD;
   t_Cnt_Out3 :WORD; 
   t_Cnt_Out4 :WORD;    
   Buffer_I   :WORD;
   Buffer_I2  :INT;      
   ATSplitDummy AT SplitDummy : ARRAY[0..7] OF BOOL;      // used to split the source and target   
   ATSplitDummy2 AT SplitDummy2 : ARRAY[0..7] OF BOOL;      // used to split the source and target 
   ATSplitDummy3 AT SplitDummy3 : ARRAY[0..7] OF BOOL;      // used to split the source and target                  
  END_VAR
LABEL
    SEC;
END_LABEL
  
  BEGIN        
            
    tBCD := S_PEXT(
    T_NO :=Syst_Time,
    S    := NOT t_Out,
    TV   :=T#250ms,
    Q    := t_Out); 
    
    
    tBCD_Cnt := S_CU(
    C_NO := Syst_CountFlash,
    CU   := t_Out,
    R    := ATSplitDummy[5],
    CV := t_Cnt_Out);
    
    tBCD_Cnt_B := WORD_TO_BYTE(t_Cnt_Out);
    
    SplitDummy := tBCD_Cnt_B;
    
       "Flash_0.5" := ATSplitDummy[0];    // 2 Hz
       
       "Flash_1.0" := ATSplitDummy[1];    // 1 Hz
       
       "Flash_2.0" := ATSplitDummy[2];    // 0.5 Hz
       
       "Flash_4.0" := ATSplitDummy[3];    // 0.25 Hz
      
       "Flash_8.0" := ATSplitDummy[4];

Vielen Dank schonmal im Voraus für eure kompetente Unterstützung.

LG
 
Hallo,

Aufgrund des "neuen" TIA Portals und dem Wegfall der AWL Sprache sind wir nun gezwungen

Bei mir ist AWL noch vorhanden :confused:

Deine Variablen sind alle Temporäre. Bei einem FC Aufruf im Programm werden die imho nichtüberschrieben. Beim 2. schon. Also irgendetwas sollte zwischengespeichert, bzw Parameter von aussen beschalten werden.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Verpolt,

vielen Dank für deine superschnelle Antwort.

Bei mir ist AWL noch vorhanden

Bei mir auch. Das Problem ist nur, wenn wir eine neue 1200er CPU einsetzen müssen (Kundenvorgabe), kommen wir mit unseren AWL Funktionen nicht mehr weiter und aus diesem Grund arbeiten wir schonmal präventiv vor.

Das mit den temp Variablen hab ich mir schon gedacht, nur in AWL ist das ganze viel einfacher gegangen. Da musste ich z.b. nicht den Ausgang Q (beim S_PEXT) belegen um den Status später im Programm abzufragen oder auch den Eingang S.
Da sah das ganze so aus:

Code:
//Some internal functions:
//for example an output called -SYS_CYCLUSTIME is set and reset (all 256
//cyclus). This is a easy way to measure the cyclustime from the RS-Processor
//at any time.
//There is also a creation from a multible takt (which is used for lamps and
//other time sensitive funktions).
//Also the management for the so called LongTimers is calculated here.
//
//Diverse interne Funktionen:
//zum Beispiel wird ein Blinktakt mit verschiedenen Taktraten erzeugt (wird
//fuer Lampensteuerung oder Zeitschaltuhren benoetigt). Ausserdem wird auf
//einfache Weise die Zykluszeit des RS-Prozessors gemessen und auf einen Ausgang
//geschaltet (nach jeweils 256 Zyklen).
//FC3
FUNCTION "System" : VOID
 TITLE =Internal Actions
KNOW_HOW_PROTECT
 AUTHOR  :RRRbyGJ
 FAMILY  :Syst
 NAME    :General
 VERSION :4.1

  VAR_TEMP
   SplitDummy :BYTE;                    // do not enter any var before !
   BufferB    :BYTE;
   BufferI    :INT;
   BufferW    :WORD;
  END_VAR

  BEGIN
  NETWORK
                                        // --------------------------------
       ON   "Syst_Time";                // *** Creating multible takt
       L    S5TIME#250ms;
       SV   "Syst_Time";
       ZV   "Syst_CountFlash";
       L    "Syst_CountFlash";
       T    SplitDummy;                 //splitting byte
       U    L 0.0;
       =    "Flash_0.5";                // 2 Hz
       U    L 0.1;
       =    "Flash_1.0";                // 1 Hz
       U    L 0.2;
       =    "Flash_2.0";                // 0.5 Hz
       U    L 0.3;
       =    "Flash_4.0";                // 0.25 Hz
       U    L 0.4;
       =    "Flash_8.0";
       U    L 0.5;                      //reset counter
       R    "Syst_CountFlash";
                                        // --------------------------------

Wie kann ich das ganze in SCL nun ähnlich/ident gestalten??

Danke.

LG
Bayernburn
 
Das mit einem FB wollen wir vermeiden. Aus diesem Grund werden wir das Ganze jetzt so lösen, dass wir uns einen DB erzeugen. Aus diesem lesen wir uns am Anfang des Bausteins die Daten aus und am Ende schreiben wir die Daten wieder in den DB.

LG
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Der Fehler liegt wohl in der falschen Verwendung der Temp-Var. Das betrifft dann AWL genauso, wie SCL. Eine Temp-Var ist immer nur im Baustein, während eines Zyklus gültig und sollte ohnehin vor Verwendung initialisiert, also mit einem gültigen Wert beschrieben werden. Wenn du Temp-Var nutzt, um Daten "zwischenzuspeichern", also im nächsten SPS-Zyklus damit weiterzuarbeiten, dann landen diese Daten ja auf dem Lokal-Stack. Diesen benutzen auch die anderen Bausteine deiner Prioritätsebene, also z.Bsp. weitere FC, die du nach deinem FC aufrufst. Hast du nur deinen FC am laufen, geht das, denn kein anderer FC lagert seine Daten im Lokal-Stack ab.
 
Code:
  ON  [COLOR=#ff0000] "Syst_Time"[/COLOR];                // *** Creating multible takt        
L    S5TIME#250ms;        
SV   [COLOR=#ff0000]"Syst_Time"[/COLOR];        
ZV   [COLOR=#ff0000]"Syst_CountFlash"[/COLOR];        
L    [COLOR=#ff0000]"Syst_CountFlash"[/COLOR];        
T    SplitDummy;                 //splitting byte        
U    L 0.0;        =    [COLOR=#ff0000]"Flash_0.5"[/COLOR];                // 2 Hz        
U    L 0.1;        =    [COLOR=#ff0000]"Flash_1.0"[/COLOR];                // 1 Hz        
U    L 0.2;        =   [COLOR=#ff0000] "Flash_2.0"[/COLOR];                // 0.5 Hz
U    L 0.3;        =   [COLOR=#ff0000] "Flash_4.0"[/COLOR];                // 0.25 Hz        
U    L 0.4;        =    [COLOR=#ff0000]"Flash_8.0[/COLOR]";        
U    L 0.5;                      //reset counter        
R   [COLOR=#ff0000] "Syst_CountFlash"[/COLOR];

Ihr hattet in AWL absolute Zugriffe im Baustein.
 
Wie schon kurz vorhin angesprochen löse ich das ganze jetzt über einen extra DB. Ich mache dort die sog. "Zwischenspeicherung" meiner temp Variablen. Sprich, ich lese zu Beginn meines FC's die Daten ein (schreibe die Daten vom DB in meine Temp-Variablen) und schreibe am Ende des FC's die Temp-Variablen wieder in den DB.
Somit ist dieses Problem gelöst.

Sollten jedoch weitere Lösungsvorschläge vorhanden sein, so bin ich natürlich sehr gerne bereit, mir diese anzuhören.

Vielen Dank an Alle für die schnelle Hilfe. :D

Gruß
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Also ich würde in jedem Fall einen FB mit Instanz einer DB-Verwendung vorziehen. Wie willst Du das mit dem DB machen, absolut adressiert? Wie soll der FC dann in einem anderen Projekt funktionieren wenn da der DB schon belegt ist? Bei uns läuft das so: FC nur dann wenn absolut gar nichts gespeichert werden muss (auch keine Flanke), also beispielsweise eine Berechnung eines Werts (Formel) anhand mehrerer Eingangsvariablen. Alles andere hat in einem FC nichts zu suchen. S5-Timer sind tabu. Wir leben im 21. Jahrhundert!
 
@ Oberchefe:
Danke für deine Infos.
Unsere Projekte sind immer so aufgebaut, dass gewisse FB's, FC's, DB's standardmäßig vorbelegt sind. Wir haben uns damit ein sog. Vorlagenprojekt kreiert.
D.h. es weiß bei uns jeder welche Bausteine bereits vergeben sind. Somit kann es bei uns nicht vorkommen, dass ein DB schon belegt ist.
Zu deiner konkreten Frage:
Ich habe das ganze so gelöst: Ich habe in einem unserer vorbelegten DB's eine Erweiterung mit meinen benötigten Variablen durchgeführt.
Diese werden nun wie folgt beschrieben:
Code:
    // Data transfer from DB3 to temp tags
    //------------------------------------
    SplitDummy := "SystemData".FC3_temp_Var.SplitDummy;
    t_Out      := "SystemData".FC3_temp_Var.t_Out;
    t_Out2     := "SystemData".FC3_temp_Var.t_Out2;
    Reset_Cnt  := "SystemData".FC3_temp_Var.Reset_Cnt;
    Reset_Cnt3 := "SystemData".FC3_temp_Var.Reset_Cnt3;
    Reset_Cnt4 := "SystemData".FC3_temp_Var.Reset_Cnt4;
    //------------------------------------
.
.
.
     // Data transfer from temp tags to DB3
    //------------------------------------
"SystemData".FC3_temp_Var.SplitDummy    := SplitDummy;
"SystemData".FC3_temp_Var.t_Out         := t_Out;
"SystemData".FC3_temp_Var.t_Out2        := t_Out2;
"SystemData".FC3_temp_Var.Reset_Cnt     := Reset_Cnt;
"SystemData".FC3_temp_Var.Reset_Cnt3    := Reset_Cnt3;
"SystemData".FC3_temp_Var.Reset_Cnt4    := Reset_Cnt4;
    //------------------------------------

Dazwischen arbeite ich mit den temp-Variablen.

Wenn du sagst, ihr verwendet keine S5 Timer mehr. Wie macht ihr es sonst? mit den SFB's? da wird ja wieder ein DB benötigt. Das ist für mich bzw. für uns nicht gerade der Weg den wir eig. gehen wollen, denn dann hat man in jedem Projekt eine Unmenge von DB's.

Für eine genauere Ausführung wie du mein Thema handhaben würdest, wäre ich dir dankbar.

Gruß
 
dann hat man in jedem Projekt eine Unmenge von DB's.

Jo, aber eigentlich interessieren Dich die DBs nicht, da Du ja alles im FB deklarierst.
Ihr habt einige wenige "große", welche auch schnell unübersichtlich werden können, wenn man nicht genug "Leer/Reserve-Plätze" eingeplant hat.

Oder halt InstanzDBs (Multiinstanzen) verwenden...

Ich programmiere wenn möglich in CFC, da sinds dann wirklich viele DBs, aber die interessieren garnicht mehr.

Tja, jeder hat so seinen Programmierstil, über das für und wider zu streiten ist müßig. Wenns vom Kunden/Firma so vorgegeben wird, machs halt so.

Achja und Timer in SCL: time := time + sampletime; (beim Aufruf des FB in nem Weckalarm-OB)

Gruß.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Also jetzt mal ganz langsam:
die Maschine wird in ein oder ein paar handvoll Bereiche aufgeteilt(also ca. 5 bis 25). Für jeden Teil gibt es einen FB samt zugehörigem IDB. In diesem IDB wird der SFB als Multiinstanz deklariert. Im OB1 werden die 5 bis 25 FBs aufgerufen mit Angabe des IDBs. Innerhalb der 5 bis 25 FBs werden Bausteine für diverse öfters (oder auch nicht) verwendete Programmteile aufgerufen, ebenfalls als Multiinstanz deklariert.
Hoffe ich bringe das um die Zeit noch halbwegs verständlich rüber. :ROFLMAO:
 
achso: es ist ja schön dass Ihr Euch in Eurer Firma einig seid was DB-Nummern angeht: aber wass passiert wenn Euer Kunde kommt und sagt dass er gerne "Seinen" DB (natürlich auch mit festgelegter Nummer) in Eurem Programm dringend braucht (für Diagnose/Scada/was auch immer)? Alle Euren guten Bausteine von Hand anpassen?
 
@ Oberchefe:
ich vermute mal, das du in der automobilindustrie oder so was ähnliches tätig bist. dann verstehe ich deine aussagen natürlich. denn in dieser branche ist es üblich, dass es kundenseitig eigene bausteine gibt.
meine firma ist jedoch im wasserbereich tätig und da hat KEIN kunde irgend welche selbst geschriebenen FB's, FC's,...; aus diesem grund, ist es für uns ein leichtes unsere struktur mit den FB's, FC's,... immer beizubehalten.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
meine firma ist jedoch im wasserbereich tätig.

Gerade dieser Bereich, bzw. die Prozessautomatisierung allgemein, mit seinen ganzen Ventilen, Pumpen, Lüftern, Motoren, ist ja prädestiniert dafür, FBs für die Komponenten zu schreiben und diese dann nach Bedarf aufzurufen.
Auf jeden Fall solltet Ihr auch mal über CFC nachdenken, mit den ganzen Funktionen AS-OS übersetzen, Meldungen etc. ist das echt ne super Sache für den Bereich...

aber wie gesagt, es ist müßig, über Vor-, Nachtteile von Programmierumgebungen/Programmierstrategien zu streiten....
Gruß.
 
Ich finde es ja toll, das ihr euren (zweifelhaften) AWL-Kram jetzt auf SCL umsetzen wollt,
aber das Argument mit der S7-1200 ist mir jetzt nicht so wirklich klar ...

T,Z gibt es da überhaupt nicht mehr, also kannst du deine diesbezügliche Funktion sowieso vergessen.
Kurzum nach heutigen Maßstäben wirklich zukuntsträchtig ist dieser Programmierstil sicher nicht,
also kannst du dir die Aktion im Prinzip schenken, da das auf einer S7-1200 eh nie so laufen wird, sprich du bei AWL bleiben kannst.

Mfg
Manuel
 
Zurück
Oben