# SFB4 funktioniert nicht richtig auf 416-2DP



## Astralavista (15 Dezember 2008)

Hallo!

Hatte am WE eine Inbetriebnahme und dabei trat folgendes Problem auf:

Es wurden mehrere Timer mit SFB4 programmiert. Wenn man auf dem Eingang PT den Wert 0 vorgibt, bleibt der Ausgang Q des Timers immer auf FALSE.
Sobald der Zeitwert größer als 0 ist funktioniert der Timer wieder ohne Probleme.
Festgestellt wurde das ganze auf einer 416-2DP CPU mit Firmware V1.1.2.
Könnte es sein das vielleicht durch ein Firmwareupgrade das Problem gelöst wird?
Auf PLCSim funktioniert das Programm auch mit Zeitwerten T#0ms, deswegen kam die Frage auf.

Gruß Ingo


----------



## Larry Laffer (15 Dezember 2008)

Hallo,
ich kann mich erinnern, dass wir das Thema vor einiger Zeit schon mal hatten - mit gleichem Ausgang.  Danach (so meine Erinnerung) laufen die SFB ohne Zeit-Vorgabe nicht (ich meine sogar unabhängig von der CPU).

Wäre es denn ein Problem, grundsätzlich 1ms auf die Vorgabe zu addieren um diesen Zustand zu vermeiden ? Oder ggf. sogar in einer eventuellen HMI-Eingabe den Vorgabewert "0" zu verhindern ?

Gruß
LL


----------



## Astralavista (15 Dezember 2008)

Wäre eine Möglichkeit, die ich aber verhindern wollte.
Ich wollte jetzt erstmal versuchen das Problem an der Ursache anzupacken und nicht drum herum zu programmieren.
Mit der Visu gibts schonmal Probleme, da dort die 0 eingegeben werden muss und das bleibt auch so. Der / die Parameter in denen die 0 jetzt drin steht sind qualifiziert (Pharma-Industrie).
Und zusätzlichen Programmcode um einen "Bug" von Siemens zu umgehen brauche ich auch nicht wirklich.


----------



## Kai (15 Dezember 2008)

Larry Laffer schrieb:


> ich kann mich erinnern, dass wir das Thema vor einiger Zeit schon mal hatten - mit gleichem Ausgang. Danach (so meine Erinnerung) laufen die SFB ohne Zeit-Vorgabe nicht (ich meine sogar unabhängig von der CPU).


 
http://www.sps-forum.de/showthread.php?t=17257

Gruß Kai


----------



## MSB (15 Dezember 2008)

Es ist zwar schon alles gesagt, aber das muss noch rein:

It's not a bug, it's a feature !


----------



## Onkel Dagobert (15 Dezember 2008)

MSB schrieb:


> ..It's not a bug, it's a feature !


It's not a feature, it's our future! Solche Peinlichkeiten sind nach Auslieferung leider nicht mehr zu korrigieren. Oder hat es wirklich einen einen Grund dass es so ist?

Eine relativ einfache Möglichkeit wäre, einen eigenen FB zu schreiben, der die SFB4 aufruft und der Zeitvorgabe 1ms hinzu addiert. Oder halt gleich etwas eigenes.


Gruß, Onkel


----------



## Sarek (16 Dezember 2008)

Onkel Dagobert schrieb:


> It's not a feature, it's our future! Solche Peinlichkeiten sind nach Auslieferung leider nicht mehr zu korrigieren. Oder hat es wirklich einen einen Grund dass es so ist?
> 
> Eine relativ einfache Möglichkeit wäre, einen eigenen FB zu schreiben, der die SFB4 aufruft und der Zeitvorgabe 1ms hinzu addiert. Oder halt gleich etwas eigenes.
> 
> ...


 
Hat aber den Nachteil das der "Ausgang" der Zeit um einen Zyklus verzögert wird.

Übrigens: Die Speed7 verhält sich hier anders als die S7, Ausgang wird sofort durchgeschaltet.
Hab ich auch erst gemerkt nachdem ich ein Programm auf der VIPA 313SC getestet habe und in der realen Maschine mit S7-313C liefs dann nicht.


----------



## HeizDuese (16 Dezember 2008)

In meinen Augen bleibt das auch ein Fehler: eine Verzögerung von 0ms bedeutet nun mal direktes durchschalten und nicht unendliches warten.


----------



## Larry Laffer (22 Dezember 2008)

... ich muß hier noch etwas anhängen - einfach weil es mir noch unter den Nägeln brennt :

Es ist aus meiner Sicht nicht so schlimm, wenn Siemens einen nicht richtig funktionierenden SFB auf den Markt bringt. Das kann jedem passieren ...
Viel schlimmer ist es nach meiner Meinung, die dann bekannter Weise nicht korrekt funktionierende Applikation trotzdem einzusetzen. 
Wie von *Onkel Dagobert* schon geschrieben ist es doch nicht so schwer, sich einen "eigenen" Baustein zu erstellen, der so funktioniert, wie man es braucht (das ist übrigens ganz generell der Weg, den ich hier beschreite). Fehler, die ich selber mache kann ich auch korrigieren - bei den Fehlern anderer wird das schon erheblich schwieriger ...

Gruß
LL


----------



## FrankW (22 Dezember 2008)

Ob die Funktion nun als richtig oder falsch bewertet wird, in der Beschreibung steht eindeutig:


> Falls Instanzen dieses SFB nach Neustart (Warmstart) initialisiert sein sollen, müssen Sie im OB 100 die zu initialisierenden Instanzen mit PT = 0 ms aufrufen.


wer also PT= 0 eingibt muss wissen, dass er damit den SFB initialisiert

und außerdem:


> PT INPUT TIME E, A, M, D, L, Konst. Zeitdauer, um die die steigende Flanke am Eingang IN verzögert wird. PT muß *positiv* sein.


positiv ist halt > 0.


----------



## Sarek (22 Dezember 2008)

Auszug aus Wikipedia



> In der mathematischen Literatur und speziell auch in der Informatik ist es teilweise auch gebräuchlich, die Null zu den positiven Zahlen hinzuzunehmen (in der Informatik wird teilweise auch zwischen −0, 0 und +0 unterschieden). Deshalb gibt es auch den einheitlich verwendeten Begriff der _echt positiven Zahlen_, bei denen die Null nicht hinzugerechnet wird.


----------



## HeizDuese (22 Dezember 2008)

FrankW schrieb:


> Ob die Funktion nun als richtig oder falsch bewertet wird, in der Beschreibung steht eindeutig:
> 
> wer also PT= 0 eingibt muss wissen, dass er damit den SFB initialisiert
> 
> ...



Die Zahl 0 hat gar kein Vorzeichen - oder wenn schon, dann beide.

Wie kann man so einen blöden Fehler nur schön reden wollen?


Eine Verzögerung von 0ms ist NICHT unendlich verzögern- PUNKT.
Ich kenne bisher keinen anderen Steuerungs- Hersteller, der das so handhabt, wie Siemens das beim TON macht.


Im übrigen bin ich davon überzeugt, dass diese Initalisierungsbeschreibung erst NACH Bekanntmachung dieses Verhaltens entstanden ist.
Eine Initalisierung fehlt als getrennter, binärer Eingang nicht nur am TON, bei TOF ist es noch tragischer, hier kann man nicht so einfach wie beim alten S5 - SA - Timer per R-Eingang und den Ausgang vorzeitig zurücksetzen.


----------



## kermit (22 Dezember 2008)

FrankW schrieb:


> ...positiv ist halt > 0.


nee!

der negative Zahlenraum eines Integers von -32768 bis -1 ist genau so groß, wie der positive Zahlenraum von 0 bis 32767.

Logisch nachvollziehbar wäre, den SFB mit Eingabe von einem negativen Zeitwert (z.B. -1) zu initialisieren


----------



## Lipperlandstern (22 Dezember 2008)

kermit schrieb:


> nee!
> 
> der negative Zahlenraum eines Integers von -32768 bis -1 ist genau so groß, wie der positive Zahlenraum von 0 bis 32767.
> 
> Logisch nachvollziehbar wäre, den SFB mit Eingabe von einem negativen Zeitwert (z.B. -1) zu initialisieren



Jetzt mal ne ganz andere Frage in diesem Zusammenhang.... Warum muss man diesen Baustein initialisieren können ? Muss man das machen ? Ich setze die Bausteine auch ein ( bei mir kommen 0 msec nicht vor hatte das Problem aber schon mal bei einer Fehleingabe  die nicht abgefangen wurde )


----------



## HeizDuese (22 Dezember 2008)

Lipperlandstern schrieb:


> Jetzt mal ne ganz andere Frage in diesem Zusammenhang.... Warum muss man diesen Baustein initialisieren können ? Muss man das machen ? Ich setze die Bausteine auch ein ( bei mir kommen 0 msec nicht vor hatte das Problem aber schon mal bei einer Fehleingabe  die nicht abgefangen wurde )



Ein TON könnte bzw. initalisiert bei LOW auf dem IN - Eingang - beim TOF geht das aber leider nicht 

Blöd kann es werden, wenn der Wert auf einer HMI-Station eingegeben werden kann und dort jemand, der keine Verzögerung möchte, eine 0 einträgt.


----------



## Sarek (22 Dezember 2008)

HeizDuese schrieb:


> Im übrigen bin ich davon überzeugt, dass diese Initalisierungsbeschreibung erst NACH Bekanntmachung dieses Verhaltens entstanden ist.


 
Davon bin ich auch überzeugt

It's a feature, not a bug!


----------



## Lipperlandstern (22 Dezember 2008)

HeizDuese schrieb:


> Blöd kann es werden, wenn der Wert auf einer HMI-Station eingegeben werden kann und dort jemand, der keine Verzögerung möchte, eine 0 einträgt.



Zumindest bei WinCC flexible kannst du die Grenzen des Wertes festlegen. Damit kann man diesen Fehler recht einfach umgehen. Wenn es Situationen gibt in dem eine Zeit von 0ms gebraucht wird, darf man halt diesen Baustein nicht verwenden. 

Siemens ist halt Siemens ........


----------



## Lupo (23 Dezember 2008)

Das Ding hat noch ein weiteres "Feature" :
Bekommt es den "0 nach 1"-Wechsel am Eingang nicht mit - also im ersten Zyklus ist der Eingang noch 0 und im zweiten Zyklus ist er 1 - dann startet es möglicherweise auch nicht.


----------



## Ralle (23 Dezember 2008)

Lupo schrieb:


> Das Ding hat noch ein weiteres "Feature" :
> Bekommt es den "0 nach 1"-Wechsel am Eingang nicht mit - also im ersten Zyklus ist der Eingang noch 0 und im zweiten Zyklus ist er 1 - dann startet es möglicherweise auch nicht.



Das ist aber nun mal bei flankengetriggerten Funktionen so, die Flanke sollte schon korrekt kommen. Oder was genau meinst du mit "nicht mitbekommen"?


----------



## peter(R) (23 Dezember 2008)

Nur mal so als Info bevor ihr nur über S7 schimpft.

BEI MITSUBISHI ISTS GENAU DAS GLEICHE !!!

Eine Zeit mit 0 vorbelegt schaltet nie.

peter(R)


----------



## HeizDuese (23 Dezember 2008)

peter(R) schrieb:


> Nur mal so als Info bevor ihr nur über S7 schimpft.
> 
> BEI MITSUBISHI ISTS GENAU DAS GLEICHE !!!
> 
> ...




Hoho - dann weiß ich, vom wem die "abgekupfert" haben.  *ROFL*


----------



## MSB (23 Dezember 2008)

Zu Mitsubishi:
Momentan in Ermangelung realer SPSen, nur mit GX-Simulator getestet,
aber wenigstens im Simulator funktioniert PT=0 wie gewünscht.

Mfg
Manuel


----------



## peter(R) (23 Dezember 2008)

Das bezweifle ich nicht. 
Es gilt ja auch vom Themenstarter im ertsen Beitrag:
<<  Auf PLCSim funktioniert das Programm auch mit Zeitwerten T#0ms  >>

Allerdings muss ich in sofern relativieren, daß meine Aussage nur für A1S CPU´s von Mitsubishi gilt. An denen hatte ich das gleiche Problem.
Wie das jetzt mit den Q´s ist - keine Ahnung.

peter(R)


----------



## MSB (23 Dezember 2008)

Also bei meiner PLC-Sim Version funktioniert PT=0 auch nicht,
es könnte allerdings sein, das der TE noch eine ältere PLC-Sim-Version hat,
da war der SFB4 funktionell ja gar nicht implementiert, also nur als NOP0,
mit anderen Worten, die Zeit war praktisch immer 0.

P.S. Gerade noch mal probiert, wenn ich das Projekt für eine A1S-CPU erstelle,
funktioniert PT=0 auch nicht, bei FX und Q aber schon ...

Mfg
Manuel


----------



## peter(R) (23 Dezember 2008)

@MSB
was mich mal wieder lehrt :
"Immer schön aufpassen mit den Aussagen und gaaanz genau sagen für was sie gelten sonst kanns Missverständnisse geben  ) !!

Mit Mitsubishi gehts halt manchmal doch !!!  

peter(R)

P.S. Wobei ich es schon etwas seltsam finde, daß es bei zwei mit der gleichen Software geschriebenen Programmen mal geht (FX) mal nicht (A1S). 
Aber da gibts bei Mitsubishi ja auch noch den schönen Befehl <CHK> der geht selbst in der A1S Welt nur bei manchen CPU´s (steht aber nirgends geschrieben in welchen und warum nicht ).


----------



## Astralavista (23 Dezember 2008)

MSB schrieb:


> Also bei meiner PLC-Sim Version funktioniert PT=0 auch nicht,
> es könnte allerdings sein, das der TE noch eine ältere PLC-Sim-Version hat,
> da war der SFB4 funktionell ja gar nicht implementiert, also nur als NOP0,
> mit anderen Worten, die Zeit war praktisch immer 0.
> ...



Das kuriose ist ja, ich hatte erst die PLCSim V5.3 SP1!!
Bei der Version hat der TON die Laufzeit gar nicht abgewartet, sondern bei jedem Zeitwert immer direkt durchgeschaltet. Kurz: Es waren keine Verzögerungen unter PLCSim möglich.
Dann durch Google etc das HF1 für diese Version "entdeckt", die das Problem mit dem TON beheben sollte.
Jetzt bin ich auf V5.3 SP1 HF1 und habe durch dieses Upgrade nur einen anderen Bug. Danke Siemens!!!!


----------



## peter(R) (23 Dezember 2008)

Verstehe ich jetzt nicht ganz. 
Deine "alte" PLCSim hat so funktioniert wie es sollte (direkt durchgeschaltet )
aber nicht so wie die "reale" CPU also hat die Simulation falsch funktioniert weil sie ja nicht so falsch funktionierte wie die CPU die ja falsch funktioniert.

Jetzt hast du wie sich das gehört eine Simulation (die ja die CPU simulieren soll ) die genauso falsch funktioniert wie die CPU 

ALSO FUNKTIONIERT SIE RICHTIG !!!!   :???roll:

(oder so ähnlich .... )

peter(R)


----------



## Astralavista (23 Dezember 2008)

Nee, leider nicht. Nochmal kurz zur Info:

PLCSim V5.3 SP1:
TON schaltet direkt durch, auch wenn ein Zeitwert eingegeben wird (z.B. T#3s). Mit dieser Version sind überhaupt keine Verzögerungen möglich.

PLCSim V5.3 SP1 HF1:
TON funktioniert mit Zeitwerten und schaltet verzögert durch. Bei T#0ms schaltet er direkt durch.

Reale CPU:
TON funktioniert mit Zeitwerten, schaltet aber bei T#0ms gar nicht mehr durch.

Was für eine Version von PLCSim habt ihr denn?


----------



## peter(R) (23 Dezember 2008)

Jetzt habe ichs auch verstanden
also funktioniert ausser der  PLCSim V5.3 SP1 HF1   nix richtig



....   oder ????

( weil die geht so wie wir uns das an der CPU wünschen würden wenn wir was zu wünschen hätten )  muss es wirklich der SFB4 sein ???


peter(R)


----------



## Astralavista (23 Dezember 2008)

Genau so ist es.
Man lernt ja nie aus ... und im Nachhinein hätte ich das Programm wohl eher mit INT-Zählern programmiert die ich als Timer benutze. Damit lässt sich auch besser rechnen etc.
Aber nun ist es halt mal so das ich am Anfang für die SFB4 entschieden habe und alles fertig programmiert ist. Kann ja schlecht jetzt alles wieder umschmeissen.
Bin das Problem jetzt umgangen indem ich einen Vergleicher nach jedem Timer programmiert habe, der den Zeitwert auf >0 vergleicht. Damit setze ich mir dann einen Merker der den Timer überbrückt.
Find ich zwar Käse, aber was anderes ist mir auf die schnelle nicht eingefallen.
Oder andere / bessere Lösungsvorschläge?


----------



## zotos (23 Dezember 2008)

Programmiere Dir einfach einen eigenen Schnittstellenkompatiblen TON und zwar einen der geht. Obwohl ich mich daran erinnern kann das Siemens bei einigen CPUs auch Probleme mit dem Zeit SFC hatte den man dafür verwenden würde (SFC1 oder so, kann mich die Scheiß nummern nie merken).


----------



## peter(R) (23 Dezember 2008)

Nee so was ähnliches hätte ich wohl auch gemacht.

Würde gerne das Gesicht des Programmierers sehen der sich das in 10 Jahren anschaut und sich fragt was für ein Penner solchen Mist programmiert hat da er ja dann wohl den Hintergrund nicht kennt  *ROFL*

( ist jetzt wirklich nur spassig gemeint. Ich habe ab und an auch solche Leichen im Keller )


peter(R)


----------



## Larry Laffer (23 Dezember 2008)

zotos schrieb:


> Programmiere Dir einfach einen eigenen Schnittstellenkompatiblen TON und zwar einen der geht.


 
*ACK*
der Meinung bin ich auch - für mich habe ich es auf diese Weise gelösst :
Ich habe einen Baustein, der mir unter Anderem die Systemzeit des CPU ausliest und diese dann in einer Global-Variablen zurückliefert. Diese Global-Variable verwende ich für meinen FB_Timer, der dann im Prinzip nach den gleichen Vorgaben wie der SFB4 arbeitet ...

Gruß
LL


----------



## Flinn (24 Dezember 2008)

Larry Laffer schrieb:


> *ACK*
> der Meinung bin ich auch - für mich habe ich es auf diese Weise gelösst :
> Ich habe einen Baustein, der mir unter Anderem die Systemzeit des CPU ausliest und diese dann in einer Global-Variablen zurückliefert. Diese Global-Variable verwende ich für meinen FB_Timer, der dann im Prinzip nach den gleichen Vorgaben wie der SFB4 arbeitet ...
> 
> ...


 
Larry,
warum nimmst Du nicht einfach den SFC "TimeTicks" (habe gerade die SFC-Nummer nicht im Kopf) für deinen selbstgebauten Timer TON bzw. TOF? Der liefert ein TIME-Wert (abgelaufene ms seit CPU-Start als Doppelwort). Ist easy zu händl'n.

Gruß
Flinn


----------



## bike (24 Dezember 2008)

peter(R) schrieb:


> muss es wirklich der SFB4 sein ???



Diese Frage stell ich mir auch immer wieder.
Es gibt S5timer, die funktionieren ohne Probleme, doch leider sind es nicht immer genug :-( (das ist die einzige Einschränkung).


bike


----------



## dalbi (24 Dezember 2008)

Aber Vorsicht bei Überlauf und CPU-Neustart mit dem SFC64 "TIME_TCK" da dieser von 0 bis 2147483647 ms zählt.

Gruss Daniel


----------

