Step 7 LGF_LimRateOfChangeCI (FB), wie starten?

[Saufautomat]

Zuviel Werbung?
-> Hier kostenlos registrieren

Damit meine Pumpe brav startet will ich vor dem PID das erste mal eine Rampe verwenden. Dafür nehme ich den LGF LimRateOfChangeCI und rufe ihn auch im OB30 auf.
Dieser startet nicht. Zuerst hatte ich callOB testweise gar nicht belegt. Nun versuche ich es eine Weile nach der LGF-Anleitung:


Ich habe es an verschiedenen Orten probiert und andere OBs verwendet aber es wird nicht akzeptiert:



Was muss ich dort anhängen? Wahrscheinlich ist es etwas sehr einfaches aber ich sehe es nicht^^

 

[UDP]

Mal ins blaue geraten aus deinem ersten Screenshot: Nur die Nummer des OBs? Also statt %OB30 nur 30 ?

Ansonsten mal den FB öffnen und schauen wie der Eingang deklariert ist?

 

[sps_klassik]

Zuviel Werbung?
-> Hier kostenlos registrieren

T#100ms.?

 

[sps_klassik]

Ich wuerde den auch noch einfach im OB1 aufrufen.Ausser es muss wirklich zeitsynchron und sehr genau sein.

 

[Saufautomat]

T#100ms wird entsprechend auch nicht akzeptiert

Im letzten Screenshot fehlt noch ein Detail:
Zum Testen wechsle ich den enDefaultOutvalue von 0->1->0


Der angezeigte Status ist nicht im LGF PDF gelistet. Der ist bei "TIA Portal Online Hilfe". Dazu finde ich aktuell aber noch nichts

 

[sps_klassik]

Zuviel Werbung?
-> Hier kostenlos registrieren

und 1(oB1) akzeptiert er auch nicht?

 

[sps_klassik]

Der braucht doch einen Instanz DB?Hast du den angelegt.Was steht dort drinnen.

 

[Mrtain]

Die Nummer des OB. In deinem Fall 30.
Mit enDefaultValue wirst du die Rampe starten müssen.

 

[Botimperator]

Zuviel Werbung?
-> Hier kostenlos registrieren

Der angezeigte Status ist nicht im LGF PDF gelistet. Der ist bei "TIA Portal Online Hilfe". Dazu finde ich aktuell aber noch nichts

16#8600 ist eine der allgemeinen Standard-Fehlerklassen.
Schau mal im Baustein nach wo die betreffende Konstante aufgerufen wird & welche Sub-Funktion den SubfunctionStatus wirft.

Die Variable für den Call-OB findest du in den Systemkonstanten der SPS.

 

[Saufautomat]

Die Nummer des OB. In deinem Fall 30.
Mit enDefaultValue wirst du die Rampe starten müssen.

Tatsächlich, so einfach war es.



Vielen Dank euch allen

 

[Saufautomat]

16#8600 ist eine der allgemeinen Standard-Fehlerklassen.
Schau mal im Baustein nach wo die betreffende Konstante aufgerufen wird & welche Sub-Funktion den SubfunctionStatus wirft.

Die Variable für den Call-OB findest du in den Systemkonstanten der SPS.

Falls jemand mal per Google hierher gelangt, so sieht es aus:

 

[Mrtain]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die im Baustein intern verwendete Funktion QRY_CINT ist für den Fehler verantwortlich.

QRY_CINT wird benutz, um die weckalarm Parameter auszulesen. Wenn du am LGF Baustein die falsche Nummer angibst, erklärt sich der Fehler.
Das ist in der Doku aber auch beschrieben:


Der Wert im subFunctionStatus ist dann der Fehler, den QRY_CINT ausgibt.

lGF Doku

 

[Mrtain]

Ich wuerde den auch noch einfach im OB1 aufrufen.Ausser es muss wirklich zeitsynchron und sehr genau sein.

Da der Baustein intern QRY_CINT wäre ein Aufruf in ein Weckalarm OB schon zu empfehlen.

 

[sps_klassik]

Geht ja nur um den Hochlauf einer Pumpe.Braucht man nicht.

 

[sps_klassik]

Zuviel Werbung?
-> Hier kostenlos registrieren

Der Regler selbst muss in einem OB35 aufgerufen werden.(Bsp 100ms.) damit er immer zu gleichen Zeiten den Istwert kriegt.

Wenn er dann umschaltet auf den Regler ist ja keine Regelabweichung da.

 

[Mrtain]

Geht ja nur um den Hochlauf einer Pumpe.Braucht man nicht.

Was der TE braucht oder nicht weiß ich nicht. Aber gut, dass du das mittels Glaskugel beurteilen kannst.

Der Rampenbaustein wird die eingestellte Weckalarm-Zeit über QRY_CINT auslesen und mit der Zeit intern die Rampe berechnen. Für mich klingt es logisch und nachvollziehbar, dass der FB dann auch im selben Weckalarm OB aufgerufen wird. Es spricht ja auch nichts dagegen, Regler und Rampenbaustein im gleichen OB zu verwenden.
Den FB in OB1 aufzurufen, während er aber mit dem zyklischen Aufrufintervallen eines Weckalarm-OB rechnet, scheint mir aber der falsche Weg zu sein - auch wenn es möglich wäre.