Beiträge

ist unterwegs.

Gruß
Andreas

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

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

Ok, dann anders formuliert: die vergangenen Sekunden seit dem letzten Reset. M.E. 'nur' ein weiteres DWORD.

Gruß
Andreas

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

igitt - Statistik  ???

die http://www.wago.com/wagoweb/documentation/750/ger_dat/d051400d.pdf sagen 10⁸
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  ;D) 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.

Hallo,

mein 750-514 ist mit 2x10⁵ Schaltspielen bei 1A DC angegeben. Ich gehe davon aus, daß sich bei dem geringen Meßstrom die Lebenserwartung den garantierten mechanischen  Schaltspielen von 10⁸ 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

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

Code Auswählen Erweitern

(* @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


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

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:

Code Auswählen Erweitern

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

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

Hallo Controlfreak,

da begrenztes Interesse hier, will ich das Forum nicht vollmüllen. Änderung ist zu Dir unterwegs.

Gruß
Andreas

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

[NOT overflow]

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