Step 7 CPU 315-2DP kann keine Ausgänge größer 127.7 schalten

Zuviel Werbung?
-> Hier kostenlos registrieren
Naja ich bin nicht so der Freund vom Fehler kaschieren. Und das macht man ja hier...
Was würdest du denn in diesem Fall machen? Es liegt vermutlich nicht an Fehlern in der Programmierung. Die Kommunikation zwischen SPS und Panel läuft nicht schnell genug ab. Das Tastaturbit kommt meist garnicht in der SPS an. In anderer Richtung werden Störmeldungen einfach nicht am Panel erkannt. Den Fall hatte ich mal, hatten wir auch hier im Forum diskutiert. Die Ursache war die selbe.

Andererseits gibt es natürlich auch handgemachte Effekte, wenn die Zykluszeit plötzlich überraschend klein wird. Ich denke da z.Bsp. an die Dämpfung von Realwerten, falls die Berechnung im Programmzyklus erfolgt. Bei moderneren Steuerungen kann man eine Mindestzykluszeit einstellen. Warum also nicht auch bei einer S7300? Ich synchronisiere z.Bsp. meinen OB1 auf den OB35-Zyklus (meist 10ms), in dem ich am Ende des OB1 eine Repeat-Schleife laufen lasse, bis ein Bit im OB35 gesetzt wird.
 
Was würdest du denn in diesem Fall machen? Es liegt vermutlich nicht an Fehlern in der Programmierung. Die Kommunikation zwischen SPS und Panel läuft nicht schnell genug ab. Das Tastaturbit kommt meist garnicht in der SPS an. In anderer Richtung werden Störmeldungen einfach nicht am Panel erkannt. Den Fall hatte ich mal, hatten wir auch hier im Forum diskutiert. Die Ursache war die selbe.

z.B. mit SetBit im Panel und FP im Programm welches das Bit wieder zurücksetzt.

Bei moderneren Steuerungen kann man eine Mindestzykluszeit einstellen. Warum also nicht auch bei einer S7300? Ich synchronisiere z.Bsp. meinen OB1 auf den OB35-Zyklus (meist 10ms), in dem ich am Ende des OB1 eine Repeat-Schleife laufen lasse, bis ein Bit im OB35 gesetzt wird.

Ich denke diese einstellbare Mindestzykluszeit ist ebenfalls ein Zugeständnis an schlechte Programme welche möglichst billig Migriert werden sollen. Ohne das man dazu einen guten und damit teuren Programmierer braucht. Ich wüsste definitiv keinen Grund warum man die Zykluszeit künstlich verlängern sollte.
Fänd ich ja geil wenn man ne S5 ersetzt bei der man mit nem Taster das Licht eingeschaltet hat. Das Licht geht da spürbar verzögert an. Jetzt kauft man sich ne neue CPU die um Faktoren schneller ist. Aber verzögert sie mit der Mindestzykluszeit auf S5 Niveau so das alles genauso zäh bleibt wie bis anhin. Alle Medianbildungen, alle Lagersuchen etc. Nur damit der Reset Button immernoch durchkommt.

mfG René
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Danke René.
Genau das habe ich schon früher in diesem Thread angeregt.
Nicht nur die Kommunikation zur HMI mit Handshake, sondern auch weiter zu den angeschlossenen Kontroller.
Dann wird ein Schuh daraus.

o.T. ich habe nach drei Monate bei meinem jetzigen Arbeitgeber auf der Messe ein Maschine fertig machen sollen.
Die Erweiterung war in sich stabil und lief. Dann kam eine 573.4 und meine Achse fuhr durch die Werkzeugwechslerklappe.
Schön war das nicht, doch die veränderten Zykluszeiten haben zu diesem Fehler geführt.
Daher habe ich mir angewöhnt, IMMER mit handshake zu arbeiten.

bike
 
Sorry, was habe ich nicht verstanden?
Nur weil ich der Meinung bin, dass Klimmzüge mit Zeiten kein guter Stil sind?
Ist Handshake falsch?
Wir verwenden auch normale Timer, egal S5 oder FB, nur wenn es keine andere Lösung gibt.
ggF mus eben ein Sensor nachgerüstet werden. So funktioniert es inzwschen bei uns relativ gut. ;-)
Ist das wirklich falsch?


bike
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Sorry, was habe ich nicht verstanden?
Nur weil ich der Meinung bin, dass Klimmzüge mit Zeiten kein guter Stil sind?
Ist Handshake falsch?..
Das primäre Problem ist doch ganz einfach ein recht schneller OB1-Zyklus, oder siehst du das anders? Es bleibt für die HMI-Kommuniukation einfach nicht genügend Zeit. Das äußert sich an nicht ankommenden Tastenbits wie vom TE beschrieben, oder an nicht angezeigten Störmeldungen wie von mir angedeutet. Eine (geringe) Zykluszeitverlängerung schaffte in beiden Fällen Abhilfe. Was ist denn daran nicht zu verstehen? Wieso redet ihr von einem Fehler? Kommunikation benötigt etwas Zeit, das ist ganz normal. Entsprechende Maßnahmen haben m.E. nichts mit "Klimmzügen" oder "Fehler kaschieren" zu tun. Natürlich wäre es schöner, wenn der Anwender nicht mit solchen Nebensächlichkeiten in Berührung kommen würde. "Handshake" ist notwendig, dort wo er gebraucht wird. Allerdings sehe ich zunächst keinerlei Zusammenhang zum Thema.
 
Ich sehe den Zusammenhang schon.
Ein Maschine / Anlage soll lange gut und zuverlässig laufen und produzieren.
Wenn jemand sich bei der Programmierung auf die Zykluszeit verlässt, dann läuft etwas echt schief.
Wenn du mit gutem Gewissen deinem Kunden eine solche Software verkaufen kannst, dann gut ich kann dies nicht.

Und der Hinweis von mir hat sehr wohl etwas mit dem Threat zu tun, denn ich möchte aufzeigen, dass es eine Lösung gibt, ohne OB 1 Zeitverzögerung einzubauen. Was wird bei der nächsten Hardwareänderung sein?
Wenn ein Problem bekannt, dann ist es besser dies zu lösen und NICHT zu kaschieren.

Soviel von mir und wenn jemand es besser findet zu basteln, dann soll der oder die das tun.
Ich finde es bescheiden und werde bestimmt nicht solchen Mist unterstützen.
Auch ein PLC Programmierer sollte eine Ehre haben.


bike
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@bike
Vielleicht glaubst du ja einem Siemens FAQ:
https://support.industry.siemens.com/cs/ww/de/view/23818213

Die Lösung die Siemens höchst selbst da präsentiert macht im Kern auch nix anderes als die Zykluszeit zu pushen.
Wenn auch scheinbar etwas aufwändiger als die WAIT Variante.

Jetzt kannst du natürlich auf Siemens schimpfen... und hast damit vielleicht sogar recht, da sich hier doch recht deutlich ein strukturelles Grundproblem der BuB Kommunikation offenbart.
 
Zuletzt bearbeitet:
Zurück
Oben