Beiträge

... den D-Anteil habe ich noch nicht getestet

die verwendeten LIB's habe ich angehängt (ausser OSCAT und STANDARD.LIB)

(beim 1. mal hochzählen funktionierts noch ... nach Sollwert unter Istwert geht nichts mehr / DIESE AUSSAGE GILT NUR FÜR "OHNE ZYKLUSBEGRENZUNG")

Bitte das Projekt nach dem Downlaod aus dem Forum löschen!

... das selbe Problem taucht auch beim INT_BAND auf.

... noch mals ein Fehler im PID

Der Ausgang geht schön langsam auf 100 (mit dem I-Anteil), erreicht der die int-LIM-Grenze zB.: 150, wird der I-Anteil ausgeschaltet (Es bleibt nicht nur der I_Regler stehen sondern der bisher berechnete I-Wert wird auf 0 gesetzt). Dh. Der Ausgang bricht bei kleinem P-Anteil auf nahezu 0 zusammen.

Das bedeutet, daß man die Einstellungen int-LIM auf keinen Fall verwenden darf und sie unbedingt auf SEHR, SEHR große Werte zu setzen sind.

... Das Projekt bekommst Du wenn ich den D-Anteil getestet hab.

Danke

... noch eine Anregung

Könnt ihr beim nächsten Release die P, I, D - Anteile als Output auswerfen. Der Regler ist dann viel einfacher einzustellen.

Vielen Dank

8ms

Das habe ich grad gemacht.

Wenn der Regler nur alle 100ms abgefragt wird funktioniert das Teil. :P

(zumindest der I-Anteil)

... Ich kann mir nun selber behelfen, das paßt soweit mal.


PS: Das Möller-Teil hat keine Tasks! Alles geht immer Reihum ... Ich hoffe in alle Ewigkeit.

Hallo Hugo

Bin grad am durchanalysieren. Kann ich irgendwo die Abtastzeit auf ca. 0.1s reduzieren? Ich habe Deine Beschreibung vom FT_INT gelesen und das hängt vielleicht damit zusammen.

Danke

Hallo Hugo

Wie versprochen gehe ich dem Ganzen nochmals auf den Grund. Ich möchte das Möller-Teil UNBEDINGT mit Deinem PID-Regler machen. (Der Möller-Regler macht eine SEHR unangenehme Vereinfachung beim D-Anteil und ist für hohe D-Anteile nahezu unbrauchbar).

Trotzdem lassen sich die Probleme mit Deinem Regler auch nicht lösen. Zuerst beschäftige ich mich mal mit dem SEHR interessanten I-Anteil. ???

Der I-Anteil fängt nach ca. 5 min an zu regeln. (in der Zwichenzeit passiert am Regler rein gar nichts) (Xw=Regelabweichung ist nahezu konstant). ???

siehe beiliegendes Bitmap

[gelöscht durch Administrator]

Hallo Hugo

NOISE :=0
LIMIT_L:=-100; LIMIT_H:=100
INT_LIMIT_L:=-10000; INT_LIMIT_L:=10000
INT_BAND:=(da habe ich von 0 bis 100 alles durchprobiert) ... habe das mit dem Aussschalten des I-Anteils schon berücksichtigt. aber wenn ich Xi=20 Xs=21 habe muss sich ja nach einiger Zeit was tun. Aber da war nix. -> wobei ich das Problem mit dem Tn nicht so genau analysiert habe wie mit dem Tv.
MANUAL_IN:=0, MANUAL:=0, RST:=0,
KP, TN, TV diverse (eigentlich logische Werte mit einem hohen TV-Anteil ... zumindest in der Originalversion, danach habe ich die ganze Palette durchprobiert)

aber bereits bei TV=0.2 geht der Regler ab wie von der Tarantel gestochen.
dafür reagiert er auf eine dauernde Regelabweichung (zB Tn=60) überhaupt nicht.

Da ich das Projekt verkauft habe muss ich leider auf den Möller-Regler umswitchen.
Der hat zwar auch ein paar Macken (habe von denen grad 'nen Neuen bekommen muss den auch noch probieren)

Mir wäre Dein PID-Regler VIEL LIEBER, weil da habe ich den SourceCode. Aber mir rennt die Zeit davon. SORRY!!!

Danke für Deine Antwort.

PS: In 2 Wochen werde ich den mit der Wago wieder mal probieren. Wenn's dort gut geht melde ich mich nochmals.

Hallo Leute

Ich spiele mich seit 1 Tag mit dem PID-Regler.
??? Irgendwie reagiert er nicht so wie erwartet (... die selben Werte, auf anderen Produkte machen was ganz anderes)
Könnt ihr bitte die Einheiten für KP (... ohne Einheit?), Tn (s?), Tv (s?) angeben.
Kp ist Ok. Aber insbesondere Tn und Tv reagieren wie der Teufel (Hmm?) ... ich habe in meinem Leben schon 100-te PID-Regelungen eingestellt, aber der FT-PID hat einen Turbo beim Tv und der Tn schläft fast ein. Ich habe des Gefühl beide stimmen um den Faktor 1000 nicht. Kann das sein?

Vielen Dank

verwendete SW-Release V2.7
verwendeter Regler EC4P-222

... lt. meinen letzten Tests funktioniert der Tn-Anteil bei mir überhaupt nicht.

Ich nehme an es geht um den wasserseitigen Frostschutz. Der luftseitige schaltet eh nur ab oder das Ganze wird mit einem L&G-Fühler gemacht und der braucht keine Regelung.

... schau Dir mal das an. Es funktioniert.

mg

[gelöscht durch Administrator]

Wenn man den Programmbereich ....

>   ontime := ontime + DWORD_TO_REAL( TIME_TO_DWORD(tx - last))/3600000.0;
>   last_on := last_on + DWORD_TO_REAL(TIME_TO_DWORD(tx - last))/3600000.0;
>   IF in AND NOT edge THEN
>      cycles := cycles +1;
>      last_on := 0;
>   END_IF;
>END_IF;
>last := tx;

mit dem Programmbereich ....

>   IF ontime <> ontime + DWORD_TO_REAL( TIME_TO_DWORD(tx - last))/3600000.0 THEN
>      ontime := ontime + DWORD_TO_REAL( TIME_TO_DWORD(tx - last))/3600000.0;
>      laston := laston + DWORD_TO_REAL(TIME_TO_DWORD(tx - last))/3600000.0;
>      last := tx;
>   END_IF;
>   IF in AND NOT edge THEN
>      cycles := cycles +1;
>      last_on := 0;
>   END_IF;
>END_IF;

... ersetzt funktionierts einwandfrei.

Das mit der Ungenauigkeit des REAL war wirklich das Problem.
Evtl. könnte man das mit dem LREAL auch lösen (ist bei sehr kurzen Einschaltungen auch besser aber in der HLK uninteressant und braucht mehr Speicher) aber es löst das Problem nicht.
Irgendwann hat man das Problem (da existiert unsere Welt dann aber nicht mehr)

Mario
(aber bitte nochmals vorher testen)

Das ist 100% Deine Software. Die Ein- und Ausgänge wurden mit der Visu belegt. NUR - der Reset wurde auf OnTime:=255.9 geändert
Dh.: Nach einem Reset sollte das Ding bei 255.9 anfangen zu zählen. Bleibt aber auf dem Wert stehen. Nach weiteren Analysen hab ich gesehen, daß das mit dem Summierer irgendwie zusammenhängt.

Super!  :) Danke für Deine schnelle Antwort

Mario


M_runtime measures the ontime of a signal in hours.
the output is of type real because the time type will overflow within 49 days.
the units are hours.

*)
(* @END_DECLARATION := '0' *)
(* at first we need to determine if the sps was powered off *)

tx := TIME();
IF NOT power THEN
   power := TRUE;
   cycles := cycles +1;
ELSIF rst THEN
   ontime := 255.9;        (*----------------------------------- zum Testen verändert ------------------------------------------------*)
   cycles := 0;
   last_on := 0;
ELSIF in THEN
   ontime := ontime + DWORD_TO_REAL( TIME_TO_DWORD(tx - last))/3600000.0;  (*----------- da taucht das Problem auf -------------*)
   last_on := last_on + DWORD_TO_REAL(TIME_TO_DWORD(tx - last))/3600000.0;
   IF in AND NOT edge THEN
      cycles := cycles +1;
      last_on := 0;
   END_IF;
END_IF;
last := tx;
edge := in;

(* revision history
hm 22.2.2007      rev 1.1
   changed VAR RETAIN PERSISTENT to VAR RETAIN for better compatibility
   wago lon contollers do not support persisitent

*)

 :o... habe das in den falschen Ordner getan ... Bitte korrigieren. Danke

WAGO 750-841:
Ich glaube mal der Befehl OnTime geht nicht korrekt. Wenn die Stundenzahl größer wird (zB >256 ... das hängt aber von der Programmgröße ab, da bei großen Durchrechnungszeiten das Ganze besser funktioniert), erfolgt keine Addition auf die Variable ontime.. Meiner Meinung ist das wegen der Ungenauigkeit der Addition bei größeren Werten.

Evtl ist das Ganze mit einem Task besser zu lösen. Aber da ich erst seit 1 Woche mit dem Ding rumspiele - kennne ich mich eigentlich GARNICHT aus.