1
Bestehende Module / Existing Modules / Re: Nochmal Actuator_3P
« am: 30. April 2009, 07:42:19 »
ist unterwegs.
Gruß
Andreas
Gruß
Andreas
Beiträge anzeigen
Diese Sektion erlaubt es ihnen alle Beiträge dieses Mitglieds zu sehen. Beachten sie, dass sie nur solche Beiträge sehen können, zu denen sie auch Zugriffsrechte haben.
Seiten: [1]
2
Bestehende Module / Existing Modules / Re: Widerstandsmessung Wago
« am: 30. April 2009, 07:31:24 »
Hallo Wu Fu,
in dem von Dir geposteten Link zur WAGO 750-461 ist auch eine Variante /020-000 für NTC20 aufgeführt.
Gruß
Andreas
in dem von Dir geposteten Link zur WAGO 750-461 ist auch eine Variante /020-000 für NTC20 aufgeführt.
Gruß
Andreas
3
Bestehende Module / Existing Modules / Geht FADE verkehrt herum?
« am: 11. Dezember 2008, 10:59:44 »
Hallo,
laut Doku (und auch Bausteinbeschreibung) soll IN1 aktiv sein, wenn F = FALSE und IN2 wenn F = TRUE. Scheint aber andersherum zu sein. Außerdem ist in der Doku F als REAL angegeben.
Gruß
Andreas
laut Doku (und auch Bausteinbeschreibung) soll IN1 aktiv sein, wenn F = FALSE und IN2 wenn F = TRUE. Scheint aber andersherum zu sein. Außerdem ist in der Doku F als REAL angegeben.
Gruß
Andreas
4
Bestehende Module / Existing Modules / Re: Wann ONTIME zurückgesetzt?
« am: 08. Dezember 2008, 21:24:14 »
Ok, dann anders formuliert: die vergangenen Sekunden seit dem letzten Reset. M.E. 'nur' ein weiteres DWORD.
Gruß
Andreas
Gruß
Andreas
5
Bestehende Module / Existing Modules / Wann ONTIME zurückgesetzt?
« am: 08. Dezember 2008, 19:33:28 »
Hallo,
da ich nie weiß, wann ich ONTIME resettet habe, wäre ein Ausgang für den Zeitpunkt des letzten Resets interessant. Ist das sinnvoll?
Gruß
Andreas
da ich nie weiß, wann ich ONTIME resettet habe, wäre ein Ausgang für den Zeitpunkt des letzten Resets interessant. Ist das sinnvoll?
Gruß
Andreas
6
Anwendungsbeispiele / Application Examples / Re: PT1000 Umschalter mit gen_SQ und TONOF
« am: 14. November 2008, 18:23:36 »
igitt - Statistik 
die http://www.wago.com/wagoweb/documentation/750/ger_dat/d051400d.pdf sagen 108
Bedeutet für mich nach Deiner Rechnung, daß mir nach 50 Jahren die Hälfte ausgefallen ist. Ich kenne nicht die MTBF von Analogbaugruppen. Außerdem habe ich in dieser Zeit bestimmt schon den 2. oder 3. Controller, weil ich dem Flash rübergeholfen habe.
Ich will hier keinen Streit vom Zaun brechen. Für meine Anwendung bedeutet das, daß ich mal irgendwann einen zu warmen oder zu kalten Raum habe. Also verschwendete (oder eingesparte
) Energie. Wenns ganz dumm kommt, und der Raum Frost bekommt, ziehen wir mal wieder die Statistik zu Rate und berechnen, wieviel ausgefallene Relais, welche über mehrere Tage in einem Dauerfrostklima in einem bewohnten Haus unbemerkt zu Frostschäden führen können.
Fehlmessungen auf Grund Verschleiß bedeuten in dieser Anordnung eine vorgetäuschte höhere Temperatur, welche idR Frau umgehend bemängeln wird
Nochmal - wir reden hier über eine kostengünstige Lösung für den Privatgebrauch. Wenn man Deine und meine Argumente beachtet und diese Lösung mit Bedacht einsetzt, spricht meiner Meinung nichts dagegen.
die http://www.wago.com/wagoweb/documentation/750/ger_dat/d051400d.pdf sagen 108
Bedeutet für mich nach Deiner Rechnung, daß mir nach 50 Jahren die Hälfte ausgefallen ist. Ich kenne nicht die MTBF von Analogbaugruppen. Außerdem habe ich in dieser Zeit bestimmt schon den 2. oder 3. Controller, weil ich dem Flash rübergeholfen habe.
Ich will hier keinen Streit vom Zaun brechen. Für meine Anwendung bedeutet das, daß ich mal irgendwann einen zu warmen oder zu kalten Raum habe. Also verschwendete (oder eingesparte
) Energie. Wenns ganz dumm kommt, und der Raum Frost bekommt, ziehen wir mal wieder die Statistik zu Rate und berechnen, wieviel ausgefallene Relais, welche über mehrere Tage in einem Dauerfrostklima in einem bewohnten Haus unbemerkt zu Frostschäden führen können.Fehlmessungen auf Grund Verschleiß bedeuten in dieser Anordnung eine vorgetäuschte höhere Temperatur, welche idR Frau umgehend bemängeln wird
Nochmal - wir reden hier über eine kostengünstige Lösung für den Privatgebrauch. Wenn man Deine und meine Argumente beachtet und diese Lösung mit Bedacht einsetzt, spricht meiner Meinung nichts dagegen.
7
Anwendungsbeispiele / Application Examples / Re: PT1000 Umschalter mit gen_SQ und TONOF
« am: 14. November 2008, 16:55:28 »
Hallo,
mein 750-514 ist mit 2x105 Schaltspielen bei 1A DC angegeben. Ich gehe davon aus, daß sich bei dem geringen Meßstrom die Lebenserwartung den garantierten mechanischen Schaltspielen von 108 nähert. Bei meiner Anwendung erfolgt die schnellste Abfrage aller 30 Sekunden. Wenn ich mich jetzt nicht verrechnet habe, bekomme ich dann in 95 Jahren die ersten Probleme. Damit kann ich sterben
Ich denke, für den Hausgebrauch ist das eine kostengünstige Lösung. In der Firma würde ich es eher nicht machen.
Gruß
Andreas
mein 750-514 ist mit 2x105 Schaltspielen bei 1A DC angegeben. Ich gehe davon aus, daß sich bei dem geringen Meßstrom die Lebenserwartung den garantierten mechanischen Schaltspielen von 108 nähert. Bei meiner Anwendung erfolgt die schnellste Abfrage aller 30 Sekunden. Wenn ich mich jetzt nicht verrechnet habe, bekomme ich dann in 95 Jahren die ersten Probleme. Damit kann ich sterben
Ich denke, für den Hausgebrauch ist das eine kostengünstige Lösung. In der Firma würde ich es eher nicht machen.
Gruß
Andreas
8
Anwendungsbeispiele / Application Examples / Re: PT1000 Umschalter mit gen_SQ und TONOF
« am: 14. November 2008, 08:42:11 »
Hallo Martin,
habe ähnliches bei mir laufen. Einen Analogeingang für NI1000 und mehrere DO mit vergoldeten Kontaktausgängen. Also keine externen Relais. NI1000 um die Einflüsse der Übergangswiderstände der Kontakte so gering wie möglich zu halten. PT1000 sollte aber ähnlich gut funktionieren. Für das ganze habe ich einen 'Multiplexer' geschrieben, welcher zyklisch die Relais ansteuert und dann die Messwerte auf den entsprechenden Ausgang schreibt. Zusätzlich läßt sich für jeden Messwert ein Offset festlegen, um eventuelle Leitungswiderstände auszugleichen.
Wenn's Dich interessiert, einfach nur den angehänten Code als exp Datei abspeichern und in Dein Projekt importieren.
Sens_In ist der Analogeingang, Sens_Count die Anzahl der angeschlossenen Sensoren. Mit SampleTime legst Du fest, wie schnell von Eingang zu Eingang geschaltet wird. Die Sens-Ausgänge steuern den DO/Relais und an den Temp-Ausgängen stehen permanent die Ausgelesenen Temperaturen an.
Gruß
Andreas
habe ähnliches bei mir laufen. Einen Analogeingang für NI1000 und mehrere DO mit vergoldeten Kontaktausgängen. Also keine externen Relais. NI1000 um die Einflüsse der Übergangswiderstände der Kontakte so gering wie möglich zu halten. PT1000 sollte aber ähnlich gut funktionieren. Für das ganze habe ich einen 'Multiplexer' geschrieben, welcher zyklisch die Relais ansteuert und dann die Messwerte auf den entsprechenden Ausgang schreibt. Zusätzlich läßt sich für jeden Messwert ein Offset festlegen, um eventuelle Leitungswiderstände auszugleichen.
Wenn's Dich interessiert, einfach nur den angehänten Code als exp Datei abspeichern und in Dein Projekt importieren.
Sens_In ist der Analogeingang, Sens_Count die Anzahl der angeschlossenen Sensoren. Mit SampleTime legst Du fest, wie schnell von Eingang zu Eingang geschaltet wird. Die Sens-Ausgänge steuern den DO/Relais und an den Temp-Ausgängen stehen permanent die Ausgelesenen Temperaturen an.
Gruß
Andreas
Code: [Auswählen]
(* @NESTEDCOMMENTS := 'Yes' *)
(* @PATH := '' *)
(* @SYMFILEFLAGS := '2048' *)
FUNCTION_BLOCK SENS_MUX
VAR_INPUT
Sens_In:WORD;
Sens_Count:INT;
Sample_Time:TIME := t#10s;
Offset_Temp0:REAL;
Offset_Temp1:REAL;
Offset_Temp2:REAL;
Offset_Temp3:REAL;
Offset_Temp4:REAL;
Offset_Temp5:REAL;
Offset_Temp6:REAL;
Offset_Temp7:REAL;
Offset_Temp8:REAL;
Offset_Temp9:REAL;
END_VAR
VAR_OUTPUT
Sens0:BOOL;
Sens1:BOOL;
Sens2:BOOL;
Sens3:BOOL;
Sens4:BOOL;
Sens5:BOOL;
Sens6:BOOL;
Sens7:BOOL;
Sens8:BOOL;
Sens9:BOOL;
END_VAR
VAR_OUTPUT PERSISTENT
Temp_0:REAL;
Temp_1:REAL;
Temp_2:REAL;
Temp_3:REAL;
Temp_4:REAL;
Temp_5:REAL;
Temp_6:REAL;
Temp_7:REAL;
Temp_8:REAL;
Temp_9:REAL;
END_VAR
VAR
Curr_Sens:INT := 0;
StartTime:TIME := t#0s;
WaitTime:TIME;
END_VAR
(* @END_DECLARATION := '0' *)
IF TIME() - StartTime >= Sample_Time THEN;
StartTime:=TIME();
WaitTime := StartTime;
IF Curr_Sens < Sens_Count - 1 THEN
Curr_Sens := Curr_Sens + 1;
ELSE;
Curr_Sens := 0;
END_IF;
Sens0:=FALSE;
Sens1:=FALSE;
Sens2:=FALSE;
Sens3:=FALSE;
Sens4:=FALSE;
Sens5:=FALSE;
Sens6:=FALSE;
Sens7:=FALSE;
Sens8:=FALSE;
Sens9:=FALSE;
CASE Curr_Sens OF
0:Sens0:=TRUE;
1:Sens1:=TRUE;
2:Sens2:=TRUE;
3:Sens3:=TRUE;
4:Sens4:=TRUE;
5:Sens5:=TRUE;
6:Sens6:=TRUE;
7:Sens7:=TRUE;
8:Sens8:=TRUE;
9:Sens9:=TRUE;
END_CASE;
ELSIF TIME() -WaitTime >= t#3s THEN;
CASE Curr_Sens OF
0:Temp_0 := WORD_TO_REAL(Sens_In)/10+Offset_Temp0;
1:Temp_1 := WORD_TO_REAL(Sens_In)/10+Offset_Temp1;
2:Temp_2 := WORD_TO_REAL(Sens_In)/10+Offset_Temp2;
3:Temp_3 := WORD_TO_REAL(Sens_In)/10+Offset_Temp3;
4:Temp_4 := WORD_TO_REAL(Sens_In)/10+Offset_Temp4;
5:Temp_5 := WORD_TO_REAL(Sens_In)/10+Offset_Temp5;
6:Temp_6 := WORD_TO_REAL(Sens_In)/10+Offset_Temp6;
7:Temp_7 := WORD_TO_REAL(Sens_In)/10+Offset_Temp7;
8:Temp_8 := WORD_TO_REAL(Sens_In)/10+Offset_Temp8;
9:Temp_9 := WORD_TO_REAL(Sens_In)/10+Offset_Temp9;
END_CASE;
END_IF;
END_FUNCTION_BLOCK
9
Bestehende Module / Existing Modules / Re: Eingeschränktes Verhalten bei SCALE_D
« am: 14. November 2008, 07:20:14 »
Hallo Hugo,
warum muß I_LO < I_HI sein? Der von mir gepostete Code kommt mit allen Konstellationen klar, soweit ich das getestet habe. Ich finde es intuitiver so, in "Datenflußrichtung" zu denken.
Gruß
Andreas
warum muß I_LO < I_HI sein? Der von mir gepostete Code kommt mit allen Konstellationen klar, soweit ich das getestet habe. Ich finde es intuitiver so, in "Datenflußrichtung" zu denken.
Gruß
Andreas
10
Bestehende Module / Existing Modules / Eingeschränktes Verhalten bei SCALE_D
« am: 13. November 2008, 18:26:45 »
Hallo,
wollte gerade SCALE_D verwenden und hab festgestellt, daß er mit Werten <> 0 für I_LO und O_LO nicht richtig rechnet, geschweige denn, mit absteigenden Werten. Ich habe z.B. einen Eingang für einen NTC Widerstand, welcher bei einem Eingangswort von 2970 -15°C entspricht und bei 1390 +20°C entspricht.
Anbei der Code, der die Funktion universell macht:
Gruß
Andreas
wollte gerade SCALE_D verwenden und hab festgestellt, daß er mit Werten <> 0 für I_LO und O_LO nicht richtig rechnet, geschweige denn, mit absteigenden Werten. Ich habe z.B. einen Eingang für einen NTC Widerstand, welcher bei einem Eingangswort von 2970 -15°C entspricht und bei 1390 +20°C entspricht.
Anbei der Code, der die Funktion universell macht:
Code: [Auswählen]
IF I_LO > I_HI THEN;
Value := LIMIT(I_HI,X,I_LO);
ELSE;
Value := LIMIT(I_LO,X,I_HI);
END_IF;
SCALE_D := O_LO + DWORD_TO_REAL(ABS(I_LO - Value)) * ABS(O_LO -O_HI) / DWORD_TO_REAL(ABS(I_LO - I_HI));Gruß
Andreas
11
Bestehende Module / Existing Modules / Stoßfreie Umschaltung
« am: 11. November 2008, 11:02:57 »
Hallo,
ist es nicht möglich, den Reglern (zB CTRL_PID eine stoßfreie Umschaltung mitzugeben. Mich stört manchmal, daß bei der Umschaltung von Hand auf Automatik der Regler je nach Reset-Eingang den Ausgang auf 0 oder den aktuellen Integratorwert setzt, anstatt von der aktuellen Position weiterzurechnen? Auf den ersten Blick würde ich sagen, daß man den Reset-Wert von oben zum Integrator runterreichen müßte, um die Funktion zu erreichen. Mit Reset dann nach Bedarf von der übergeordneten Funktion entweder auf 0 (default) oder Y setzen.
Gruß
Andreas
ist es nicht möglich, den Reglern (zB CTRL_PID eine stoßfreie Umschaltung mitzugeben. Mich stört manchmal, daß bei der Umschaltung von Hand auf Automatik der Regler je nach Reset-Eingang den Ausgang auf 0 oder den aktuellen Integratorwert setzt, anstatt von der aktuellen Position weiterzurechnen? Auf den ersten Blick würde ich sagen, daß man den Reset-Wert von oben zum Integrator runterreichen müßte, um die Funktion zu erreichen. Mit Reset dann nach Bedarf von der übergeordneten Funktion entweder auf 0 (default) oder Y setzen.
Gruß
Andreas
12
Bestehende Module / Existing Modules / Re: Nochmal Actuator_3P
« am: 16. September 2008, 07:58:41 »
Hallo Controlfreak,
da begrenztes Interesse hier, will ich das Forum nicht vollmüllen. Änderung ist zu Dir unterwegs.
Gruß
Andreas
da begrenztes Interesse hier, will ich das Forum nicht vollmüllen. Änderung ist zu Dir unterwegs.
Gruß
Andreas
13
Bestehende Module / Existing Modules / Nochmal Actuator_3P
« am: 01. September 2008, 14:08:01 »
Hallo,
ich verwende den Actuator_3P nach einem PID-Regler zur Ansteuerung meines Heizkreismischers. Dieser hat keinen Endschalter. Selbst bei einer cal_runtime von 2 Minuten hat er sich schon mehrmals festgefahren (pos 0 der 1 erreicht, obwohl physikalische Endlage noch nicht erreicht war). Die cal_time noch weiter runterzusetzen widerstrebt mir doch. Dann wird ja ständig die ach so schöne Regelung durcheinandergewürfelt.
Ich habe jetzt den Baustein um eine 'Auto_Cal'-Funktion erweitert. Diese beruht unter Umgehung der bereits eingebauten Cal und Diag_funktion darauf, daß bei einem In-Wert von 0 oder 1 grundsätzlich der jeweilige Ausgang mit max_runtime angesteuert wird. Dieser Vorgang wird aber durch einen erneuten In-Wert 0>in<1 wieder unterbrochen.
Für Anwendungen, bei denen es auf die absolute Stellung ankommt, ist das sicher nicht geeignet, aber bei einem vorgeschalteten stetigen Regler halte ich das für sinnvoll.
Bei Interesse, kann ich die Änderung hier reinstellen.
Gruß
Andreas
ich verwende den Actuator_3P nach einem PID-Regler zur Ansteuerung meines Heizkreismischers. Dieser hat keinen Endschalter. Selbst bei einer cal_runtime von 2 Minuten hat er sich schon mehrmals festgefahren (pos 0 der 1 erreicht, obwohl physikalische Endlage noch nicht erreicht war). Die cal_time noch weiter runterzusetzen widerstrebt mir doch. Dann wird ja ständig die ach so schöne Regelung durcheinandergewürfelt.
Ich habe jetzt den Baustein um eine 'Auto_Cal'-Funktion erweitert. Diese beruht unter Umgehung der bereits eingebauten Cal und Diag_funktion darauf, daß bei einem In-Wert von 0 oder 1 grundsätzlich der jeweilige Ausgang mit max_runtime angesteuert wird. Dieser Vorgang wird aber durch einen erneuten In-Wert 0>in<1 wieder unterbrochen.
Für Anwendungen, bei denen es auf die absolute Stellung ankommt, ist das sicher nicht geeignet, aber bei einem vorgeschalteten stetigen Regler halte ich das für sinnvoll.
Bei Interesse, kann ich die Änderung hier reinstellen.
Gruß
Andreas
14
Bestehende Module / Existing Modules / FT_PID geändert?
« am: 05. Dezember 2007, 15:52:02 »
Hallo,
bin neu hier, deshalb erstmal danke für die Lib.
Habe mich gestern gleich frisch auf die 240 gestürtzt und bei meinem gerade werdenden Projekt schnell mal die Regler ausgetauscht. Seitdem 'hängt' sich der Regler auf, wenn er an die Limits stößt. Arbeitet dann offensichtlich nur noch als P-Regler.
Wenn ich mir den neuen Quellcode ansehe ist das auch klar - aber auch Absicht?
IF ABS(diff) <= int_band AND NOT overflow AND TN > 0 THEN
(* integrator is within int_band and needs to be run *)
integ(in := diff, K := 1/TN, run := TRUE, rst := FALSE, out_min := int_limit_L, out_max := int_limit_H);
(* check if integrator has reached its limits and set overflow *)
IF integ.Out >= int_limit_H OR integ.Out <= int_limit_L THEN overflow := TRUE; END_IF;
ELSE
(* int_band is exceeded, integrator needs to be cleared *)
integ(rst := TRUE);
END_IF;
Ich könnte natürlich den overflow permanent auf rst schreiben aber wo ist der Mehrwert?
Danke für Aufklärung
Gruß
Andreas
bin neu hier, deshalb erstmal danke für die Lib.
Habe mich gestern gleich frisch auf die 240 gestürtzt und bei meinem gerade werdenden Projekt schnell mal die Regler ausgetauscht. Seitdem 'hängt' sich der Regler auf, wenn er an die Limits stößt. Arbeitet dann offensichtlich nur noch als P-Regler.
Wenn ich mir den neuen Quellcode ansehe ist das auch klar - aber auch Absicht?
IF ABS(diff) <= int_band AND NOT overflow AND TN > 0 THEN
(* integrator is within int_band and needs to be run *)
integ(in := diff, K := 1/TN, run := TRUE, rst := FALSE, out_min := int_limit_L, out_max := int_limit_H);
(* check if integrator has reached its limits and set overflow *)
IF integ.Out >= int_limit_H OR integ.Out <= int_limit_L THEN overflow := TRUE; END_IF;
ELSE
(* int_band is exceeded, integrator needs to be cleared *)
integ(rst := TRUE);
END_IF;
Ich könnte natürlich den overflow permanent auf rst schreiben aber wo ist der Mehrwert?
Danke für Aufklärung
Gruß
Andreas
Seiten: [1]