Step 7 Überlauf an PEW (AI) in ersten OB1 zyklen

TIA_TESTER

Level-1
Beiträge
103
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

habe da eine einfach Frage auf die ich kein reim habe.

Ich lese mehrere Analoge Eingäge direkt über die Peripherie ein. Also nicht aus dem Prozessabbild.

Jetzt hab ich einen Vergleich auf 32767 (Überlauf) programmiert. Und jeden Neustart der CPU kriege ich dann einen Überlauffehler (Obwohl der richtige Sensor dran ist etc). Sperre ich die Überwachung für 1sec. nach Anlauf läuft alles durch.

Wer weis wieso das so ist. Und wie man es eleganter lösen könnte.

Ich danke im voraus,

TT
 
Ich versuche mir die Frage selbst zu beantworten:

Ist die Integrationszeit meiner Karte größer als meine Zykluszeit und dadurch hab ich in den ersten Zyklen keine richtigen Werte???

Wie könnte man das "elegant" umgehen.

Danke Gruß TT
 
Hallo TT,

Schreib noch kurz welche Hardware du benutzt.
Software ist an deine profilname zu sehen TIA....
Und füge dein code mal ein.

Bram

Hallo,

ist eine 331-7kf02 AI Karte an der mehrere Thermoelemente angeschlossen sind. Projektiert hab ich mit Step7:p

Code hab ich jetzt nicht da... aber ist ein einfach er INT Vergleich:

PEWxx == 32767
S Fehler_AI

mir fällt als einziges ein das Fehlersetzten für Zeit xx zu unterdrücken nach Neustart (müsste halt mal nach der Integrationszeit schauen). Oder?

Gruß TT

EDIT: Wenn ich die Adressen ins Prozessabbild lege hab ich auch nix gewonnen oder? Dort wird ja auch nur "Der Überlauf" eingelesen... Ich habe das Problem nur bei einem der beiden benutzten Kanäle.
 
Zuletzt bearbeitet:
Die Antwort steckt schon in Deiner Fragestellung: in den ersten OB1-Zyklen das PEW nicht auswerten. Noch einfacher: die ersten OB1-Zyklen einfach nichts tun. Dazu eine Anlaufzeit (TON) von 1s abwarten und solange die noch nicht abgelaufen ist den OB1 gleich wieder beenden.
Code:
L #OB1_SCAN_1
L B#16#3
<>I
= "ZYKLUS1"

UN "ZYKLUS1"
L S5T#1S
SE T1
U T1
= "Anlauf_fertig"

UN "Anlauf_fertig"
BEB

//ab hier das normale Programm
...
Weckalarme OB3x und Prozessalarme OB4x am besten auch gleich wieder beenden, solange der Anlauf noch nicht abgeschlossen ist.
Code:
UN "Anlauf_fertig"
BEB

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich lese mehrere Analoge Eingäge direkt über die Peripherie ein. Also nicht aus dem Prozessabbild.

Jetzt hab ich einen Vergleich auf 32767 ...............
TT
Nur so am Rande:
Mir ist nicht so ganz klar was Du meinst mit <Direkt über die Peripherie, nicht über Prozeßabbild>.
Aber bei Analogbaugruppen ist "Vollausschlag" 27648 und nicht 32767.
Hat aber wahrscheinlich mit deinem eigentl. Problem nichts zu tun.
 
Nur so am Rande:
Mir ist nicht so ganz klar was Du meinst mit <Direkt über die Peripherie, nicht über Prozeßabbild>.
Aber bei Analogbaugruppen ist "Vollausschlag" 27648 und nicht 32767.
Hat aber wahrscheinlich mit deinem eigentl. Problem nichts zu tun.

Bist du Siemensprogrammierer?

1. PEW oder EW
2. 32768 aka 16#7fff = Fehlerwert, bei Überlauf oder Unterlauf
3. Er hat TC Eingänge, d.h. Temperatur mit einer Kommastelle, d.h. 27648 wären 2764,8 °C oder F
 
"direkt über die Peripherie" = direkt von der Baugruppe einlesen: L PEW256
"Prozeßabbild" = aus dem vor dem OB1-Aufruf eingelesenen Puffer einlesen: L EW256

Siemens-Analogeingangsbaugruppen liefern auch größere Werte als 27648 - der sogenannte Übersteuerungsbereich bis ca. 118% des nominellen Bereichs.

Mit 32767 und -32768 werden besondere Fehlerzustände signalisiert (Überlauf, Drahtbruch, Wandlungswert ungültig, ...)

Der TE will den Hardware-Fehlerzustand melden/signalisieren, bei Spannung-Ein wird aber bis zum ersten echten Wandlungswert unerwünscht eine (falsche) Fehler-Meldung erzeugt, die will er unterdrücken.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Danke Harald, ich hab schon an mir selbst gezweifelt und das Handbuch der Karte runtergeladen..... aber 32767 und -32768 stimmen, so hab ich es auch programmiert.

Will Kabelbruch und eben den Überlauf feststellen und Vergleiche wie schon erwähnt auf == und setzte mir dann ein "Fehler-Bit",.... Jetzt hab ich heute im weiteren Programmverlauf festgestellt das in den ersten (leider nicht nur DER erste) OB1 Zyklen einer der beiden oben genannten Werte reinkommt. Jetzt wäre es natürlich möglich die ganze Programmbearbeitung "hinauszuzögern", werde mir deinen Vorschlag in ruhe ansehen heute Abend Harald.

Aber: Kann mir jemand sagen woran es denn liegt? Dachte immer OB100 wird während/nach Hochlauf durchlaufen und anschließend (WENN DIE HARDWARE BEREIT IST) der OB1 das erste mal?

Oder hab ich da einen denkfehler? Hatte das " == 32767 " mal auskommentiert und dann kam auch kein Fehler....
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Die Analogeingabekarte meldet beim starten, daß sie vorhanden ist. Unabhängig davon, ob schon für alle Kanäle Meßwerte vorliegen. Kommunikationskarten melden auch daß sie vorhanden sind, unabhängig davon, ob schon Daten empfangen wurden.

Harald
 
Die Analogeingabekarte meldet beim starten, daß sie vorhanden ist. Unabhängig davon, ob schon für alle Kanäle Meßwerte vorliegen. Kommunikationskarten melden auch daß sie vorhanden sind, unabhängig davon, ob schon Daten empfangen wurden.

Harald

Hmm dann ist die einzige möglichkeit tatsächlich das "herauszögern" der bearbeitung? Wie gesagt schaue mir dein Vorschlag dafür mal den du gepostet hast.

Danke Gruß TT
 
Ja, das ist nunmal so. Und das Verzögern der Programmbearbeitung per Timer im OB1 ist durchaus üblich. Oft aber, weil bei Spannung-Ein auf externe Geräte gewartet werden soll, welche langsamer hochfahren als die SPS.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Danke euch!!! Hab es jetzt so gemacht das ich bei restart Zeit x alle Bausteine (ob1+35) in Netzwerk 1 beende. Funktioniert soweit und hoffe das beim nächsten Einsatz das Problem damit behoben ist. :)

Danke für den Hinweis das es öfter so gemacht wird. Ich hatte eine ähnlich Idee: eine gewisse Zeit nach Anlauf über einen Sprung ans Ende des ob1 zu springen, dass ganze aber irgendwie als pfusch abgetan im ersten Moment:))



Gesendet von meinem ALE-L21 mit Tapatalk
 
Evtl. auch einfach mal über eine generelle Zeitverzögerung von solchen Fehlern nachdenken. Ich mach bei Analogwerten meist das ganze so das Unter-/Überlauf eh erst nach einiger Zeit (so 1 bis max. 5s) einen Fehler auslösen, damit hättest du auch indirekt dein Problem ja gelöst gehabt.
 
Ich hatte es schon das solche Fehler gar nicht während des Hochlauf kommen sondern
schon beim abschalten zuvor. Da war die Versorgung der AI-Karte früher weg als die
CPU was zum Einlesefehler führte. Dadurch wurde das Störbit bei mir gesetzt und erst
beim nächsten Hochlauf dann angezeigt.
Behoben hab ich das dadurch dass beim Hochlauf diese Störbits im ersten Zyklus
generell zurückgesetzt werden.

Gruß
Thomas
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Evtl. auch einfach mal über eine generelle Zeitverzögerung von solchen Fehlern nachdenken. Ich mach bei Analogwerten meist das ganze so das Unter-/Überlauf eh erst nach einiger Zeit (so 1 bis max. 5s) einen Fehler auslösen, damit hättest du auch indirekt dein Problem ja gelöst gehabt.

Hallo, nicht ganz,... hatte ich auch erst gemacht das der "Fehler" 1sec anstehen muss. Aber ich hab in der Zeit keinen richtigen Temperaturwert was mir an anderer Stelle probleme bereitet.... Klar kann man auch wieder was programmieren.

Aber ich halte die Möglichkeit am Anfang alles erstmal n Paar sekunden nicht zu bearbeiten für eine gute Lösung. Auch wenn mich Eliot´s einwand nachdenklich stimmt, jetzt wo du es sagst hatte ich das auch schonmal das mir beim Ausschalten "mist gesetzt wurde" da eine Karte früher weg war wie die CPU.... Unfassbar wie man (ich) Dinge vergisst wenn man länger raus ist:)

In dem Fall (das die Karte beim ausschalten zuerst weg ist und keine Werte liefert) würde aber ein Diagnoseeintrag in der CPU stehen müssen das die Baugruppe ausgefallen ist oder? Nur um das mal auszuschließen. Bin leider erst in ein paar Tagen an der Anlage:(

Ich danke im vorraus für die Hilfe und die Denkanstöße, hat mir sehr geholfen!
 
Zurück
Oben