Beiträge

Hallo Jens,

...wie war das gleich mit dem Wald in den Bäumen...?

Das "Ergebnis := " hat gefehlt...

Manchmal hilft auch ein Gummihammer  - wegen den leichten Schlägen auf den Hinterkopf.

Danke!

Gruß, Jörg

Hallo liebe Leute,

ich fange grad an mit SCL zu programmieren und möchte wieder mal die o.g. Funktion nutzen. (TIA V13 Prof. SP1, Upd.7 unter Win7-64)  CPU ist eine S7-1214C, Dabei komme ich an einer Stelle nicht weiter. Beim Aufruf der Funktion LINEAR_INT in einem SCL-FB fehlt mir der Rückgabewert, spricht das Rechenergebnis der Funktion. Beim Übersetzen gibt es die Fehlermeldung "Die Funktion gibt einen Wert zurück" - ja wo denn?
Folgendes wird im SCL-Editor dargestellt:

"LINEAR_INT"(X := #Dummy, XY := "DB_Stützpunkte".XY, Pts := 9);    // "LINEAR_INT" ist mit Wellenlinie unterstrichen mit Info "..Funktion stimmt nicht mit formalen Parametern überein.."
                                                                                                             // ... wo ist der Ausgangs-/Return-Wert ? bzw. wo und wie gehört er da noch hin?
"LINEAR_INT"(X:=_real_in_, XY:=_struct_in_, Pts:=_int_in_);             // nackter Aufruf

Bei Nutzung der Fkt. in FUP ist der ENO- und Ret_Val-Ausgang da... und die Funktion tut dort auch ihren Dienst.

Ich habe schon div. Versuche unternommen die Ausg.-Variable "Ret-Val" in verschiedensten Versionen in den SCL-Aufruf nachzudefinieren, jedoch ohne Erfolg.
Ist bei der Übersetzung der OSCAT-Bibliothek bei mir was schief gelaufen?
Wie bekomme ich den Ausgangswert der LINEAR_INT-Berechnung unter SCL?

Gruß, Jörg

Hallo Dalbi,
Problem ist gelöst... Ich wollte mit meiner Fragerei auch nicht sagen , das dein(?) FB fehlerhaft ist - sondern ich habe nach einer Lösung für mein Problem gesucht...
Erst hatte ich versucht mit einem Multiinstanz-DB die Anzahl der verschiedenen DB-Aufrufe in meinem FB zu reduzieren, selbes Ergebnis. Daran lag es schon mal nicht.
Lösung bzw. die eigentliche Ursache war, daß bei Systemstart sporadisch ein Meßwert noch null war (oder Wert sehr nahe an null) und bei den nachfolgenden Berechnungsschritten eine Division erfolgte. Das gab dann ab und zu ein nan oder auch ein Überlauf des 32bit-Zahlenbereichs. Mit "...nan" oder "...inf" am Eingang kann das FT_AVG-Modul irgenwie nicht umgehen... ;)

Gruß, Quasi

Hi,
ich bin dabei ein kleines Projekt mit Verwendung der FT_AVG-Funktion (V3.11) zur Mittelwertbildung zu erstellen. Es sind 5 Meßwerte, die z.T. auch negativ werden können. In einem FB werden nacheinander - mit ein bischen Logik dazwischen -  5x der FB23 aufgerufen, jeder mit eigenem DB. Funktioniert soweit auch ganz gut - aber eben nicht zuverlässig.
Ein Problem ist das bei Änderung der Anzahl "n" diese nicht richtig in die Funktionen übernommen werden, d.h. der betreffende Ausgang gibt dann dauerhaft falsche Werte aus. Stelle ich "n" wieder auf den vorherigen Wert zurück, stimmt der Ausgang wieder. Das habe ich damit behoben, das ich mit externer Logik bei Änderung der Anzahl "n" einen kurzer Resetimpuls an "RST" gebe.

Zweites, größeres Problem: Manchmal - nach dem Einschalten der SPS (313C) - gibt der eine oder andere FT_AVG "nan" aus. Selbst bei Verwendung eines Anlauf-Timers, der den Reset-Eingang für 2s aktiviert, passiert das manchmal. Habe ich hier einen Denkfehler bei der Verwendung der Funktion?
Oder muß ich die 5x FT-AVG-Fkt. im Anlauf-OB initialisieren?
Den Eingang "E" wird dabei über einen einstellb. Taktgeber mit pos. Flanke getriggert (derzeit 5Hz) und bei Systemstart mit dem o.g. Anlauftimer für 2s aktiviert.
Ich habe auch schon versucht die FT_AVG's zeitlich versetzt nacheinander und mit 100ms Abstand über ein Schieberegister-Bit an "RST"  zu initialisieren.
Selbes unzuverlässiges Anlaufproblem... :(
Ich könnte jetzt zwar zeitgesteuert einen zusätzlichen Resetimpuls erzeugen um so die sporadischen Anlaufprobleme zu beseitigen aber ich denke das muß auch anders gehen.
Hat jemand den entscheidenden Tipp für mich?

Nachtrag: in der Online-Beobachtung des gestörten, zugehörigen IDBs sieht man schön wie die Meßwerte nach Takt eingelagert werden, n-Zähler läuft durch, Ausgang AVG zeigt jedoch DW#16#FFFFFFFF
Gruß, Quasi

Hi GU,
...ja, ist vor einiger Zeit gemacht worden...;
Der Baustein heißt SRAMP und ist FB217 in OSCAT 3.11.
Habe ich auch getestet und für gut befunden - kam aber nicht zum praktischen Einsatz.
(Der FB ruft aber noch einige andere FB/FC/DB auf, steht aber im Baustein drin)

Qu

Hi GU,
ich hatte vor einigen Wochen einen Versuchsaufbau mit FT_RMP auf einer alten 314IFM gemacht und ein wenig damit rumgespielt - mit einem Zeigerinstument am Ausgang. Das was du schreibst ist mir nicht aufgefallen...
Die Sache kam aber auch nicht zur Anwendung.
Qu

Hallo dalbi,

ich steh grad auf dem Schlauch mit der LINEAR_INT und dem XY-Eingang als ARRAY. Den DB habe ich hinbekommen, aber die Übergabe der Daten an den Baustein passt nicht (Fehler: Aktualdatentyp ARRAY passt nicht zu formalem Typ STRUCT des Formalparameters XY)
Hab schon einige Versuche mit Syntaxvariationen unternommen aber ohne Erfolg...

Quasi

 Hi,
ich habe neulich versucht einen Funktionsgenerator unter S7 mit der Oscat-Lib aufzubauen. Das soll dann auf einer 314IFM laufen. Hat auch alles soweit gut funktioniert bis auf den Analogausgang den ich mit AOUT bzw AOUT1 machen wollte. Ist zwar alles gut beschrieben - ich bekomme es aber einfach nicht hin. Beim Datenformat für den Analogausgang heisst es bei S: Bit15: Vorzeichen, dann 12 Datenbits und der Rest (Bit 2...0) mit 0 aufgefüllt. So habe ich es bei AOUT1 eingestellt und nach Fehlschlag viele Varianten durchprobiert. Der Eingang bekommt von einer Rampenfunktion REAL 0.0 - 100.0 vorgegeben wird zyklisch durchlaufen. Hi- & Low- Beschaltung am AOUT1-Modul habe ich auf 100.0 bzw 0.0 eingestellt und auch verschieden variiert. Der Ausgang machte zwar mal was aber nur in der letzten Stelle von f auf 8, sonst alles auf "f". ???
Erwartet hatte ich eine Funktion wie der FC106 "UNSCALE". (Der funktioniert problemlos...)
Wo liegt mein Fehler? Hat jemand vielleicht eine funktionierende Konfig. als Bsp.?
Jörg