SFB4 "TON" schaltet bei Zeitvorgabe t#0MS nicht durch

hubert

Level-2
Beiträge
401
Reaktionspunkte
26
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Leute.

Bin schon wieder etwas am Testen. Für eine Anlage, die ich mach wollte ich in einem FB mehrmals den SFB4 "TON" vwewenden. Dabei ist mir folgendes aufgefallen. Setzte ich den Sollwert auf 0ms so schaltet der Ausgang dieses Bausteines nicht durch obwohl am IN ein "1" Signal anliegt, gebe ich statt desen z.B. 1ms funktioniert er wieder. Dieses Phänomän ist mir in PLCSIM und auch an einer CPU315-2DP aufgefallen. Das kann doch nicht sein wenn ich als Zeitvorgabe 0 eingebe das der Baustein nicht mehr funktioniert. Wollte den Baustein deshalb verwenden, da ich mir dann den Spass mit den ganzen Taktmerkern sparen kann, wegen der unterschiedlichen Zykluszeiten der CPU. Ist euch dieses Phänomen auch schon aufgefallen?
 
Hallo Hubert,

zu diesem 'Phänomen' steht in der S7-Hilfe:

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.
( Hinweis: Der Wertebereich ist durch den Datentyp TIME festgelegt.)

Also, soll wohl heißen: nicht negativ und größer Null.

mfg.
Rolf
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Rolf.

Meine Zeitvorgabe war aber positiv. Wenn der Kunde z.B. für eine Startverzögerung die von mir so programmiert worden ist 0 eingibt muss es doch auch funktionieren. Bei der S5time funktioniert es doch auch. Ich kann in der Beschreibung des FB's aber nichts lesen, dass die Zeitvorgabe nicht 0 sein darf.
 
Zuletzt bearbeitet:
Klarer Fall:
Hilfe nicht richtig gelesen + Anfängerfehler + nie probiert

PT muss Positiv sein wie von RolfB schon erwähnt, und 0 ist weder positiv noch negativ,
sondern halt eben "null".

Ich habe mir beholfen das ich vor jedem TON bei Zeitwert <= 0 einfach 1 in den entsprechenden Zeitwert schreiben.

Mfg
Manuel
 
Hallo Manuel.

Habe diesen Baustein das erstemal verwendet und halt dieses Phänomen festgestellt. Hatte ich bis jetzt bei keinem der S5#time Bausteine dieses Phänomen. Deine Lösung mit dem Vergleich ist auch nicht schlecht, aber etwas aufwendig. Habe mir die Funktion des Bausteines nun selber geschrieben und sie funktioniert wunderbar. Oft hilft halt einfach selber schreiben. Werde mir aber die Sache mit ungleich 0 merken.
 
Tja wie heißts so schön in einer Kindersendung:
Ob ihr wirklich richtig steht seht ihr wenn das Licht angeht.

Prinzipiell kenne ich die Problematik, scheinbar gibts die auch (na klar) nur bei Siemens.
Seitdem ich allerdings bei einer Inbetriebnahme vor der Parametrierung div. Zeiten damit Probleme hatte,
fange ich derartige Probleme halt unmittelbar vorm Timer ab.

Mfg
Manuel
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Dieses Verhalten zeigt der TON bei S7 seit Anfang an - ich persönlich halte es nicht für richtig (korrekt wäre, bei t#0ms im gleichen Zyklus den Q auf high zu setzen), aber Siemens wird es wohl nicht mehr rausnehmen- man weiß ja nicht, wer alles dieses Verhalten ausgenutzt hat. Saublöd ist natürlich, wenn man über HMI dem Anlagenbediener die Änderung des Verzögerungwertes erlaubt. Wenn dieser keine Verzögerung wünscht und als Zeit 0 s eingibt (*1000) wird er sich wundern, dass der gewünschte Effekt nicht auftritt, wenn man in der Software diesen Ausnahmefall nicht vorgesehen hat.
 
Das mit dem Vorgeschalteten Vergleicher und umschalten von allen Werten <= 0 auf 1 wäre mir auch zu doof. Ich kann es gut nachvollziehen das Du Dir den TON nachgebaut hast.

Leider habe ich keine Ausgabe der IEC61131-3 zur Hand. IMHO sollten solche Normen, Gesetze und Vorschriften sollten frei im Internet zur Verfügung stehen.

Aber ich habe es gerade in CoDeSys getestet und da wird bei PT := T#0ms der Ausgang Q durchgeschaltet sobald der Eingang IN true ist.

Ich hätte vermutet das der Ausgang Q intern einfach mit
Q := ET >= PT;
gebildet wird. Was ja bei dem Verhalten vom SFB4 nicht der Fall sein kann.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das PT nicht 0 sein darf, ergibt sich wohl eher aus einem anderen Text ebenfalls in der Hilfe zum SFB4.

Das Betriebssystem setzt die Instanzen des SFB 4 "TON" bei Kaltstart zurück. 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. Falls Instanzen dieses SFB innerhalb eines anderen Bausteins enthalten sind, erreichen Sie das Rücksetzen dieser Instanzen z. B. durch Initialisierung des übergeordenten Bausteins.
Nun ja, wie auch immer, sowas betrachte ich als typisch Siemens.
Intern scheint der SFB4 wohl mit irgend einer Art von Systemzeit zu arbeiten,
jedenfalls wenn man sich während dem Betrieb des Timers mal die zugehörige Instanz mit den Stats "ATIME" und "STIME" anschaut.

P.S. Volker hat auf seiner Homepage einige Timer-FC's, realisiert mit Taktmerkern.

Mfg
Manuel
 
Siemens' IEC-Timer machen mich traurig. Und das zu Weihnachten! Ich hab die Dinger nie angefasst, weil Siemensbausteine mir allgemein zu viel und zu komplexe Funktionalität zur Verfügung stellen, manchmal eben unerwartete Ergebnisse liefern und oft auch nicht laufzeiteffizient sind.

Meine Timer sind meistens AWL-Zehnzeiler, da strick ich nicht mal einen extra FB oder FC draus, die stützen sich auf den OB1-PREV-CYCLE (wenn nicht CPU318 ) und deren Verhalten ist anhand des überschaubaren Codes zweifelsfrei nachvollziehbar. Ob remanent, wann remanent, ob bei -1 abgeschaltet, alles geht und ist ohne Handbuch aus dem Code ersichtlich!

Schade eigentlich - ich denke, die IEC wollte durch Normung ermöglichen, dass Code leichter portierbar ist. Stemmt sich Siemens dagegen, indem die Timer seltsame Eigenschaften haben? ist es Politik?
 
Hallo Leute.

Ist die Funktion der Bausteine nicht nach der IEC genomert. Ich hatte schon gedacht das es so sei. Aber wie ich feststelle wehrt sich Siemens dagegen genau nach dieser Norm zu Programmieren. Habe es aber auch schon mit Siemens Alarmbausteinr (SFC17, SFC18 und SFC19) erlebt. Die zeigen ein unterschiedliches verhalten auf einer S7-300 und S7-400. Die Antwort von Siemens laut nach einer Servicezahlung von ca.100€, die Bausteine werden von zwei unterschiedlichen Programmieren geschrieben, dass kann doch nicht sein oder. Wie seht ihr das?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Leute.

Ist die Funktion der Bausteine nicht nach der IEC genomert. Ich hatte schon gedacht das es so sei. Aber wie ich feststelle wehrt sich Siemens dagegen genau nach dieser Norm zu Programmieren. Habe es aber auch schon mit Siemens Alarmbausteinr (SFC17, SFC18 und SFC19) erlebt. Die zeigen ein unterschiedliches verhalten auf einer S7-300 und S7-400. Die Antwort von Siemens laut nach einer Servicezahlung von ca.100€, die Bausteine werden von zwei unterschiedlichen Programmieren geschrieben, dass kann doch nicht sein oder. Wie seht ihr das?

Ja, leider ist das so, offensichtlich sind die auch nicht in der Lage miteinader zu sprechen. Das sieht man ja auch immer wieder am Step7-Manager, das weiß der eine Programmierer nicht, was der andere tut, nicht mal innerhalb einer Programmierumgebung ist die Bedienung komplett einheitlich (siehe Symolikeditor und Datenbausteineditor, warum müssen die komplett unterschiedlich sein?

Noch schlimmer finde ich, daß die Dinge manchmal sogar noch schlechter werden. Wir hatten heute ein OP77A in der mache, die Dinger sind ja Komplettschrott. Dauern kommt Kommunikationsüberlast ($50000), sowas gab es beim OP7 nie. Gut, 512 Fehlermeldungen sind projektiert, aber das konnte das Micker-OP7 problemlos :twisted: .

Ich bin ja eigentlich einer, der ganz gerne Step7 programmiert, aber ich fürchte, die schießen sich selbst ab, wenn sie weiter auf solchen Schrott setzen.
 
also, inzwischen hab ich mich ja sogar daran gewöhnt, den Code so zu stricken, dass er sowohl auf zwei- wie auch vier-Akku-CPUs läuft. Dass dabei ein Lade-Befehl nur auf die ersten zwei Akkus wirkt, Push/Pop und diverse Arithmetik auf alle vier - ich berücksichte es halt und schreibe aber den Code lauffähig für alle.

@Ralle: ja, ich glaub, die haben sich noch nie sich mit SAA ... etc. befasst. Dementsprechend haben wir Anwender Schwierigkeiten, unseren Maschinen und Anlagen ein Look and Feel von Siemens mitzugeben. Jeder macht es halt so, wie es ihm gefällt, und Maschine A ist grundsätzlich anders bedienbar als Maschine B - obwohl beidesmal Siemens drin ist :mad:

@hubert: nein, das kann nicht sein - ist aber so! Automobile verschiedener Hersteller erscheinen mir so langsam einheitlicher, als das, was bei Siemens so scheinbar aus einem Hause kommt. Aber Siemens ist nicht Siemens - die lassen sehr viel extern von Hinz und Kunz zusammenschustern :twisted:
 
Zurück
Oben