Zykluszeit definiert erhöhen

mkd

Level-2
Beiträge
197
Reaktionspunkte
30
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

ich möchte die Zykluszeit einer aktuellen S7-315 erhöhen.
Ziel ist es die eine Art Mindestzykluszeit, wie sie bei der 400er Reihe möglich ist, nach zu bauen.
Da die Anlage noch massiv vergrößert wird möchte ich schon jetzt unter realen Bedingungen testen.

Elegant wäre eine Funktion die es ermöglicht, eine Mindestzykluszeit vorzugeben und dann entsprechend der aktuellen Zeit am Ende vom OB 1 zu warten.

Jetzt habe ich, durch die Forensuche, den SFC 47 gefunden. So weit so gut.
Erster Ansatz war, die Startzeit im Date Time Format des OB1 auszulesen, dann nach allen Bausteinaufrufen die nun aktuelle Systemzeit auszulesen und entsprechend zu verrechnen.
Jetzt kenne ich ja die aktuelle Zykluszeit und muss nur um x ms verlängern...

Die Startzeit des OB1 bekomme ich ja aus der Temp Variable des OB1.
Lese ich jetzt mit dem SFC1 die aktuelle Zeit zum Zeitpunkt des Aufrufs aus ?
Zusätzlich frage ich mich ob es Standardfunktionen gibt, die es ermöglichen zwei Date Time Formate auf Ihre Differenz hinz zu überprüfen

Hat jemand mal so etwas realisiert ?


Daniel
 
in den variablen des ob1 hast du doch die letzte zykluszeit in
ms zur verfügung. da musst du dann gar nichts mehr rechnen.
(ob1_prev_cycl)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Aber die letzte Zykluszeit hätte ich dann doch schon künstlich mit dem SFC verlängert.

Ich möchte wissen wie lange mein Programm bis zum Ende vom OB1 gebraucht hat um dann definiert zu verlängern.
 
Zusätzlich frage ich mich ob es Standardfunktionen gibt, die es ermöglichen zwei Date Time Formate auf Ihre Differenz hinz zu überprüfen


stdlibs -> iec -> FC 34 SB_DT_DT

Beschreibung

Die Funktion FC 34 subtrahiert zwei Zeitpunkte (Format DT) und liefert als Ergebnis eine Zeitdauer (Format TIME). Die Zeitpunkte müssen in Bereich von DT#1990-01-01-00:00:00.000 und DT#2089-12-31-23:59:59.999 liegen. Die Funktion führt keine Eingangsprüfung durch. Ist der erste Zeitpunkt (Parameter T1) größer (jünger) als der zweite (Parameter DT2), ist das Ergebnis positiv; ist der erste Zeitpunkt kleiner (älter) als der zweite, ist das Ergebnis negativ. Liegt das Ergebnis der Subtraktion außerhalb des TIME-Zahlenbereichs, wird das Ergebnis auf den entsprechenden Wert begrenzt und das Binärergebnis BIE auf "0" gesetzt.

Parameter Deklaration Datentyp Speicherbereich Beschreibung
DT1 INPUT DATE_AND_TIME D, L Erster Zeitpunkt im Format DT
DT2 INPUT DATE_AND_TIME D, L Zweiter Zeitpunkt im Format DT
RET_VAL OUTPUT TIME E, A, M, D, L Differenz im Format TIME
Die Eingangsparameter können nur mit einer symbolisch definierten Variable belegt werden.


Frank


P.S.
Ein Code und auch die Art des Einlesens von EAs sollte
so robust sein, dass es solche Aktionen nicht braucht.
 
sollwert zykluszeit - letzte zykluszeit => differenzzeit

wartezeit = wartezeit + differenzzeit

wartezeit begrenzen auf sinnvolle werte (0...300ms z.b.)

sfc47 aufrufen mit wartezeit
 
danke ibfs,

aber mkd hat meinen ansatz anscheinend nicht verstanden.
es braucht dazu keinen fc34. der aufwand mit date_time
ist nicht notwendig.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

der OB35 wird schon genutzt - und dass mit einer viel höheren Zykluszeit als gewünscht.

Ich bin von anderen Steuerungen eine Mindestzykluszeit gewöhnt. Meiner Meinung nach eine schöne Funktion.
Im aktuellen Fall möchte ich die Momentane Zykluszeit von 3...4ms auf ca. 10 ms erhöhen. Das bringt mir einige Vorteile.
Sicherlich sollte Code so geschrieben sein dass er bei 20 oder 40ms immer noch sauber arbeitet. Letztendlich möchte ich aber mein Programm unter realen Bedingungen (die sich irgendwann mal durch massive Programmerweiterungen einstellen werden) verlässlich testen. Dafür braucht es eine Mindestzykluszeit. Jedenfalls ein "nice to have".

Apropos stabile Programme und das unabhängig von Zykluszeiten:
Ich habe schon einige 300er CPU´s gegen schnellere getauscht und mir danach wegen zu schneller Zykluszeiten Fehler eingehandelt. Das waren in den meisten Fällen nicht meine Programme. Zusätzlich bestimmt meiner Meinung nach der Prozess oder Kommunikationen wie schnell ich arbeiten muss.


Daniel
 
Hallo Daniel,

jetzt nur mal am Rande, könntest du eventuell kurz erklären wie bei einer längeren Zykluszeit Fehler im Programm auftreten können? Mir wurde immer eingetrichtert Zykluszeiten so gering wie möglich zu halten, bezeichne mich allerdings noch als Anfänger auf dem Gebiet der SPS Programmierung.

Gruß
Christoph
 
Hallo,

kurze Zykluszeiten sind m.M.n. immer besser als zu lange.
Mit der langen Zykluszeit muss man einfach leben.

Dann kommt es noch auf die Anlage, welche gesteuert werden soll, an.
Ich habe Steuerungen programmiert wo wir so dynamisch aggieren das Reaktionszeiten von Greifern + vorgeschaltete Ventile berücksichtigt werden müssen da alle Bewegungen von einer Kurvenscheibe abhängen.

Es gibt viele Beispiele wo die Zykluszeit wichtig ist. Mal ist eine möglichst kurze Verarbeitungszeit, mal eine gleibleibende interessant. Mal geht es auch um die Kommunikation mit anderen Systemen und da ist die Kommunikationsleistung der CPU bei verschiedenen Zykluszeiten interessant.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Apropos stabile Programme und das unabhängig von Zykluszeiten:
Ich habe schon einige 300er CPU´s gegen schnellere getauscht und mir danach wegen zu schneller Zykluszeiten Fehler eingehandelt.

Ein Programm muss innerhalb einer normalen Spanne von 1-20 ms
sicher und Zykluszeitunabhängig funktionieren.

Das mit zunehmender Zykluszeit der Maschinendurchsatz und die
Taktzeit leidet versteht sich von selbst.

Wenn es bei sehr geringen Zykluszeiten Probleme gibt, das ist 99,9%
der Fälle das Programm fehlerbehaftet.

Typische Fehler sind FEHLENDE oder UNVOLLSTÄNDIGE Verriegelungen
zwischen Programmabläufen und Schrittketten. Das gewisse Fehler dann
aufgrund einer höheren Programmträgkeit nicht mehr auffallen, heißt
nicht dass das Programm fehlerfrei ist!

Frank
 
mkd hat meinen ansatz anscheinend nicht verstanden.
es braucht dazu keinen fc34. der aufwand mit date_time
ist nicht notwendig.
mkd hat Deinen Ansatz schon frühzeitig verstanden und als unbrauchbar verworfen.
Aber die letzte Zykluszeit hätte ich dann doch schon künstlich mit dem SFC verlängert.

sollwert zykluszeit - letzte zykluszeit => differenzzeit

wartezeit = wartezeit + differenzzeit
Bei Deiner Formel ist idealerweise letzte_zykluszeit = sollwert_zykluszeit und differenzzeit = 0. Um wieviele ms muß nun der gerade laufende OB1-Zyklus verlängert werden?

Deshalb nutzt die letzte Zykluszeit nichts, man muß die aktuelle Uhrzeit (oder je nach CPU die Systemzeit SFC64) abfragen, um zu wissen, wie lang der aktuelle OB1-Zyklus bisher ist.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hier mal (m)ein Lösungsansatz:

Code:
FUNCTION FC100 : INT

VAR_TEMP
    dtActualTime: DATE_AND_TIME;    //aktuelle Zeit
    dtStartTime: DATE_AND_TIME;     //OB 1 Startzeit
    tDiffTime: TIME;                //Differenz zwischen OB1 Startzeit
    iWaitTime: INT;                 //Wartezeit in µs 
    iError: INT;                    //Error SFC1 READ_CLK
    
    
    dintTemp1: DINT;
    
    
END_VAR

VAR_INPUT 
      OB1_DATE_TIME: DATE_AND_TIME;     //OB1 Startzeit
      iCycleTime: INT;                  //gewünschte Zykluszeit in µs
END_VAR


//Startzeit von OB1
dtStartTime:= OB1_DATE_TIME;


//aktuelle Zeit lesen
iError :=READ_CLK(CDT := dtActualTime);



//Differenz aus OB1 Start Zeit und aktueller Zeit
tDiffTime := SB_DT_DT(DT1 := dtActualTime ,DT2 := dtStartTime);  
 
 
//Debug... 
dintTemp1:= TIME_TO_DINT(tDiffTime);
 

iWaitTime := (iCycleTime - DINT_TO_INT(TIME_TO_DINT(tDiffTime))*1000);

IF ( iWaittime > 0) THEN  
    WAIT(WT := iWaitTime); //Warten...
    FC100 := 1;            //alles gut
ELSE
    FC100 := 0;            //Sollzykluszeit größer aktuelle Zykluszeit 
END_IF;
 
Zurück
Oben