31
Ankündigungen / Announcements / Re: Downloadmanager: "down"
« am: 13. April 2015, 04:36:32 »
DANKE 
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.
32
Ankündigungen / Announcements / Downloadmanager: "down"
« am: 06. April 2015, 05:24:27 »
Hallo Leute
Wolle mal die Codesys 3 zum erstem Mal ERNSTHAFT unter die Lupe nehmen und dazu das OSCAT herunterladen, ABER ...
Wegen einer gefundenen Schadsoftware wird die OSCAT-Webseite derzeit technisch untersucht. Der betroffene Downloadmanager wurde deaktiviert.
Ich wartete ein paar Tage, aber da ändert sich nichts. Ich habe schon vor ein paar Tagen mal die Oscat von der Codesys-page runtergeladen, aber die ist leider nicht mehr ganz aktuell.
Bis wann ist das Problem behoben?
Mg
Wolle mal die Codesys 3 zum erstem Mal ERNSTHAFT unter die Lupe nehmen und dazu das OSCAT herunterladen, ABER ...
Wegen einer gefundenen Schadsoftware wird die OSCAT-Webseite derzeit technisch untersucht. Der betroffene Downloadmanager wurde deaktiviert.
Ich wartete ein paar Tage, aber da ändert sich nichts. Ich habe schon vor ein paar Tagen mal die Oscat von der Codesys-page runtergeladen, aber die ist leider nicht mehr ganz aktuell.
Bis wann ist das Problem behoben?
Mg
33
oscat.lib fuer Step 7 / Re: CLK_PRG: fehlerhafter Startwert
« am: 05. Oktober 2014, 06:05:58 »Code: [Auswählen]
So wie ich das sehe empfiehlst Du die (obige) Lösung mit dem geänderten "init" UND mit deiner S_Time. Habe ich das richtig verstanden? Mir wäre das Lieb. Weil ich die S_Time gerne in diesen Baustein einbinden würde. Sonst habt man wieder x ähnliche Bausteine die derart (wie die S_Time) geändert werden müssen.
Code: [Auswählen]
"IDB_STIME"();
#tx := "IDB_STIME".tx;
IF #Q OR "IDB_STIME".init_happened THEN #last := #tx; END_IF;
Ich muß ehrlich sagen ich habe mich um die S_Time GAR NICHT gekümmert ich habs verwendet und (wie Du) erwartet daß es stimmt. Bisher hatte ich keine Probleme. Aber ich werde mal ein Projekt starten (im Moment nichts in Aussicht) wo ich die Änderungen einbinde und dann hätte ich auch ein paar Testergebnisse. Evtl. kann ich auch ein bestehendes ändern. Welche CPU wäre sinnvoll (1511, 1513, 315) könnte ich anbieten.
Danke Mg
34
oscat.lib fuer Step 7 / Re: CLK_PRG: fehlerhafter Startwert
« am: 29. September 2014, 06:13:39 »
Hallo Psyche
a) Ja STime
b) siehe Anhang
c) PWM_DC: Da gibt es viele Anwendungen dafür. In diesem Fall verwende ich es zum leistungsmäßigen Takten eines Befeuchterventilsventils für die Zusatzkühlungkühlung eines Tischkühlers (Außeneinheit). Aber auch die meisten Elektroheizungen werden so leistungsmäßig geregelt.
Die CLK_PRG Probleme gibt es nur bei der S7-315. Bei der 1500er funktioniert die erstaunlicherweise.
So nun noch was zu mir selbst, damit Du über meine Ahnungslosigkeit Bescheid weißt: ... ich bin mit der S7 zwangsbeglückt worden (bin eigentlich aus der Prozeßtechnik). Und ich machte bis vor 2 Jahren keine S7-Steuerungen. Aber alles ändert sich mal. Wir schreiben mit der S7 eigentlich NUR Prozeßkälteanlagen und neuerdings mache ich ein bischen Lüftung dazu (und M-Bus wurde auch schon entwickelt). Ich habe meine Software natürlich nun so aufgebaut wie ich das aus der Codesys-Welt kenne (Leider geht bei der S7 der CFC noch nicht ... da muß ich mich halt mit dem FUP abfinden, aber das geht auch, wenn auch die Übersichtlichkeit stark darunter leidet). Also die ganzen OB's, DB's usw. sind mir kaum vertraut und nicht will sie auch nicht verwenden sonst schreibe ich alles im SCL. Natürlich wollte ich viele meiner eigenen Bausteine aus dem Codesys verwenden (ging auch erstaunlich gut). Inzwischen haben wir schon eine ganz gute (interne) LIB für die Siemens S7. Mein EINZIGSTER OB ist immer noch der OB1. Alles andere wird ausprogrammiert. Somit bin ich als Entwickler für das Zeugs VÖLLIG daneben. Trotzdem funktionieren bereits 4 Anlagen PERFEKT! Ich werde das System wie ich es bisher gemacht habe auch so beibehalten. Ich habe auch bereits mit mehreren ORIGINAL-SIEMENS-Programmierern darüber gesprochen und die haben mir auch zu nichts anderem geraten.
Mit besten Dank
Mg
[gelöscht durch Administrator]
a) Ja STime
b) siehe Anhang
c) PWM_DC: Da gibt es viele Anwendungen dafür. In diesem Fall verwende ich es zum leistungsmäßigen Takten eines Befeuchterventilsventils für die Zusatzkühlungkühlung eines Tischkühlers (Außeneinheit). Aber auch die meisten Elektroheizungen werden so leistungsmäßig geregelt.
Die CLK_PRG Probleme gibt es nur bei der S7-315. Bei der 1500er funktioniert die erstaunlicherweise.
So nun noch was zu mir selbst, damit Du über meine Ahnungslosigkeit Bescheid weißt: ... ich bin mit der S7 zwangsbeglückt worden (bin eigentlich aus der Prozeßtechnik). Und ich machte bis vor 2 Jahren keine S7-Steuerungen. Aber alles ändert sich mal. Wir schreiben mit der S7 eigentlich NUR Prozeßkälteanlagen und neuerdings mache ich ein bischen Lüftung dazu (und M-Bus wurde auch schon entwickelt). Ich habe meine Software natürlich nun so aufgebaut wie ich das aus der Codesys-Welt kenne (Leider geht bei der S7 der CFC noch nicht ... da muß ich mich halt mit dem FUP abfinden, aber das geht auch, wenn auch die Übersichtlichkeit stark darunter leidet). Also die ganzen OB's, DB's usw. sind mir kaum vertraut und nicht will sie auch nicht verwenden sonst schreibe ich alles im SCL. Natürlich wollte ich viele meiner eigenen Bausteine aus dem Codesys verwenden (ging auch erstaunlich gut). Inzwischen haben wir schon eine ganz gute (interne) LIB für die Siemens S7. Mein EINZIGSTER OB ist immer noch der OB1. Alles andere wird ausprogrammiert. Somit bin ich als Entwickler für das Zeugs VÖLLIG daneben. Trotzdem funktionieren bereits 4 Anlagen PERFEKT! Ich werde das System wie ich es bisher gemacht habe auch so beibehalten. Ich habe auch bereits mit mehreren ORIGINAL-SIEMENS-Programmierern darüber gesprochen und die haben mir auch zu nichts anderem geraten.
Mit besten Dank
Mg
[gelöscht durch Administrator]
35
oscat.lib fuer Step 7 / Re: FT-PT1: Ãœberlauf (Funktion SPS)
« am: 28. September 2014, 06:49:04 »
Das weiß ich nicht. Ich verwende auch die Beckhoff/Wago Codesys aber da hatte ich bisher keine derartigen Probleme. Allerdings ist die sowieso etwas weiter entwickelt.
36
oscat.lib fuer Step 7 / Re: CLK_PRG: fehlerhafter Startwert
« am: 28. September 2014, 06:47:26 »
Hallo Psyche
Danke für Deine Antworten. Ich habe die Änderung deshalb so ausgeführt, weil ich irgendwie gemerkt habe, daß sich die CLK_PRG nach kurzer Zeit bei einer CPU315 verrechnet. Ich habe weiters erkannt, daß CLK_PRG einen ähnlichen Inhalt wie die S5_TIME hat. Erst hatte ich die CLK_PRG so verändern wollen, daß die Änderungen von der S5_TIME in die CLK_PRG einfließen aber das habe ich gleich mal den ganzen Betrieb stillgelegt. Dann habe ich mir die Teile von der S5_Time_V1.5 nochmals angeschaut (die funktioniert bei mir) und erkannt, daß ich die "neue" S5_Time_V1.5 als Funktion in die CLK_PRG einbinden kann. Leider ist es einmal zu dem obigen Effekt gekommen, daß die CLK_Prg nach einem erneuten Änderungsdownload (bin zumindest "nach 3 Monaten" der Meinung daß es nur ein Änderungsdownlaod war) zu einem Fehler der CLK_Prg kam. Deshalb setzte ich die Werte bei einem solchen Fehler einfach gleich. Ich verwende die CLK_PRG in Zusammenhang mit der PWM_DC. Ich weiß nicht wo die CLK_PRG sonst noch verwendet wird. Zumindest in diesem Zusammenhang funktioniert das Ganze mal bis jetzt. Leider taucht der Fehler NUR im Sommer auf. Im Winter braucht die Steuerung den PWM_DC nicht.
Ich bin über jeden Kommentar froh. DANKE !!!
Mg
Danke für Deine Antworten. Ich habe die Änderung deshalb so ausgeführt, weil ich irgendwie gemerkt habe, daß sich die CLK_PRG nach kurzer Zeit bei einer CPU315 verrechnet. Ich habe weiters erkannt, daß CLK_PRG einen ähnlichen Inhalt wie die S5_TIME hat. Erst hatte ich die CLK_PRG so verändern wollen, daß die Änderungen von der S5_TIME in die CLK_PRG einfließen aber das habe ich gleich mal den ganzen Betrieb stillgelegt. Dann habe ich mir die Teile von der S5_Time_V1.5 nochmals angeschaut (die funktioniert bei mir) und erkannt, daß ich die "neue" S5_Time_V1.5 als Funktion in die CLK_PRG einbinden kann. Leider ist es einmal zu dem obigen Effekt gekommen, daß die CLK_Prg nach einem erneuten Änderungsdownload (bin zumindest "nach 3 Monaten" der Meinung daß es nur ein Änderungsdownlaod war) zu einem Fehler der CLK_Prg kam. Deshalb setzte ich die Werte bei einem solchen Fehler einfach gleich. Ich verwende die CLK_PRG in Zusammenhang mit der PWM_DC. Ich weiß nicht wo die CLK_PRG sonst noch verwendet wird. Zumindest in diesem Zusammenhang funktioniert das Ganze mal bis jetzt. Leider taucht der Fehler NUR im Sommer auf. Im Winter braucht die Steuerung den PWM_DC nicht.
Ich bin über jeden Kommentar froh. DANKE !!!
Mg
37
oscat.lib fuer Step 7 / Re: FT-PT1: Ãœberlauf (Funktion SPS)
« am: 20. September 2014, 14:18:19 »
Funktioniert auch in der 1511 und 1513.
Grundsätzlich tauchen die Probleme irgendwann mal völlig unkontrolliert auf. DER BAUSTEIN MUSS UNBEDINGT DERART VERÄNDERT WERDEN.
Mg
Grundsätzlich tauchen die Probleme irgendwann mal völlig unkontrolliert auf. DER BAUSTEIN MUSS UNBEDINGT DERART VERÄNDERT WERDEN.
Mg
38
oscat.lib fuer Step 7 / Re: Die STime Misere
« am: 19. September 2014, 12:10:05 »
... zur STIME V1.6
Was hast Du geändert? (bin zu faul um es zu suchen)
Warum hast Du es geändert?
Ich verwende derzeit zu 100% die S7-1500 ... letztes Jahr hatte ich noch (die letzte) S7-300.
Alles mit TIA (dzt V13)
Mg
Was hast Du geändert? (bin zu faul um es zu suchen)
Warum hast Du es geändert?
Ich verwende derzeit zu 100% die S7-1500 ... letztes Jahr hatte ich noch (die letzte) S7-300.
Alles mit TIA (dzt V13)
Mg
39
oscat.lib fuer Step 7 / Re: Mischerregelung mit S7300
« am: 19. September 2014, 12:03:18 »
Ich glaube kaum. Hier geht es eher um Probleme, die explizit die SIEMENS-Oscat betrifft. Da gibt es sicher Lösungen von der Codesys-Oscat die Du 1:1 übernehmen kannst. (wenn Du die LIB erst mal bei einer Siemens grundsätzlich zum Laufen gebracht hast).
40
oscat.lib fuer Step 7 / Re: Die STime Misere
« am: 19. September 2014, 12:01:10 »
... muß mich auch noch einmischen ...
Bitte beachte auch die letzten paar Beiträge von mir.
Ich bin auch ein bischen verärgert, daß die Siemens-Anbindung kaum mehr gewartet wird. Aber was soll man machen, man kann auch alles selber schreiben, dann gibts halt noch mehr Fehler. Trotzdem würde es mich freuen, wenn es mit der dem S7-Oscat wieder mal weiter ginge.
Nun noch ein Kommentar zu deinen Antworten ... wenn man schon eine "kostenlose" LIB irgendeines dir sicher unbekannten Programmiers verwendet, kann man schon erwarten, daß man die Meldungen des letzten Jahres in dem Forum durchgehen (Gott sei Dank gibt es das!!!). Ich habe das auch gemacht! Das braucht grad mal 1-2h. Und noch was ... ich lege mit Programmierfehlern in meinen Anlagen ganz Werke still ... nicht nur ein paar Maschinen und trotzdem verwende ich die OSCAT.
ABER TROTZDEM HOFFE ICH DASS ICH HIER WIEDER MAL WAS VON DIR HÖRE. Wir brauchen Kommentare zur LIB. DAS HILFT ALLEN!!!
Danke
Mg
Bitte beachte auch die letzten paar Beiträge von mir.
Ich bin auch ein bischen verärgert, daß die Siemens-Anbindung kaum mehr gewartet wird. Aber was soll man machen, man kann auch alles selber schreiben, dann gibts halt noch mehr Fehler. Trotzdem würde es mich freuen, wenn es mit der dem S7-Oscat wieder mal weiter ginge.
Nun noch ein Kommentar zu deinen Antworten ... wenn man schon eine "kostenlose" LIB irgendeines dir sicher unbekannten Programmiers verwendet, kann man schon erwarten, daß man die Meldungen des letzten Jahres in dem Forum durchgehen (Gott sei Dank gibt es das!!!). Ich habe das auch gemacht! Das braucht grad mal 1-2h. Und noch was ... ich lege mit Programmierfehlern in meinen Anlagen ganz Werke still ... nicht nur ein paar Maschinen und trotzdem verwende ich die OSCAT.
ABER TROTZDEM HOFFE ICH DASS ICH HIER WIEDER MAL WAS VON DIR HÖRE. Wir brauchen Kommentare zur LIB. DAS HILFT ALLEN!!!
Danke
Mg
41
oscat.lib fuer Step 7 / Re: CLK_PRG: fehlerhafter Startwert
« am: 20. August 2014, 09:04:44 »
noch eine Änderung
Nach einem Download kann es sein, daß die Initialisierung nicht funktioniert .... deshalb folgende Änderung
Nach einem Download kann es sein, daß die Initialisierung nicht funktioniert .... deshalb folgende Änderung
Code: [Auswählen]
(* // START -------------------------------- DAS IST MEINER MEINUNG FALSCH (mg 5.8.2014) --------------------------------------------
(* read actual startup info *)
(* OB1_SCAN_1 BYTE - B#16#01: Abschluss des Neustarts (Warmstarts)
- B#16#02: Abschluss des Wiederanlaufs
- B#16#03: Abschluss des freien Zyklus
- B#16#04: Abschluss des Kaltstarts
- B#16#05: Erster OB 1-Zyklus der neuen Master-CPU nach
Master-Reserve-Umschaltung und STOP des
bisherigen Masters *)
#ERR := RD_SINFO (TOP_SI => #TOP_SI, START_UP_SI => #START_UP_SI);
(* read system time *)
#tx := DINT_TO_TIME(DWORD_TO_DINT("T_PLC_MS"()));
(* reset last_time on system startup *)
IF #TOP_SI.EV_NUM = 1 OR #TOP_SI.EV_NUM = 2 OR #TOP_SI.EV_NUM = 4 THEN
#init := false;
END_IF;
(* initialize on startup *)
IF NOT #init THEN
#init := TRUE;
#last := #tx - #PT;
END_IF;
*)
// ENDE -------------------------------- DAS IST MEINER MEINUNG FALSCH (mg 5.8.2014) --------------------------------------------
// und wird ersetzt durchf die folgenden 2 Zeilen *)
"IDB_STIME"();
#tx := "IDB_STIME".tx;
(* hier muss die korrektur für step7 stattfinden
plctime muss den vollen wertebereich von time ausnutzen:
wenn bei step7 time -24tage bis plus 24 tage ist dann muss der timer auch beim überlauf auf -24tage springen
und auf keinen fall auf 0 !!!!
für siemens muss ein weiterer fb im main eingebunden werden der sicherstellt das alle 32 bits durchgezählt werden.
es kann nur ein fb sein den er muss sich das oberste (32te) bit merken.
oder etwa spring s7 bei überlauf auf -24 tage????? dann wäre keine korrektur nötig.
*)
(* generate output pulse when next_pulse is reached *)
#Q := #tx - #last >= #PT;
IF #Q OR NOT "IDB_STIME".init THEN #last := #tx; END_IF;
(* revision hiostory
hm 25 feb 2007 rev 1.1
rewritten code for higher performance
pt can now be changed during runtime
hm 17. sep 2007 rev 1.2
replaced time() with t_plc_ms() for compatibility reasons
hm 25. oct. 2008 rev 1.3
optimized code
mg 5. aug. 2014 rev 1.4
problem with the internal-time variable after the overflow
mg 18. aug. 2014 rev 1.4a
INIT after download/restart
*)
42
oscat.lib fuer Step 7 / Re: CLK_PRG: fehlerhafter Startwert
« am: 06. August 2014, 04:39:32 »
Hallo Leute
... die Entwickler
(eigentlich traurig)
Ich habe das nun selber probiert. Aber ich habe leider keine Station zum Probieren zu hause (muß das immer bei einer in Betrieb befindlichen SPS über VPN machen und dabei stelle ich bei einem Fehler u.U. gleich einen ganzen Betrieb ab!!!)
Trotzdem konnte ich nicht mehr länger warten und testete mal an dem ganzen Zeugs rum. Im Endeffekt habe ich das folgendermaßen gemacht ...
Die folgende Änderung sollte meiner Meinung funktionieren aber das Ganze kann ich erst nach 18 weiteren Tagen sagen (dann kommt es zum nächsten Überlauf)
So lange ist das Zeugs noch ungetestet!
... die Entwickler
(eigentlich traurig)Ich habe das nun selber probiert. Aber ich habe leider keine Station zum Probieren zu hause (muß das immer bei einer in Betrieb befindlichen SPS über VPN machen und dabei stelle ich bei einem Fehler u.U. gleich einen ganzen Betrieb ab!!!)
Trotzdem konnte ich nicht mehr länger warten und testete mal an dem ganzen Zeugs rum. Im Endeffekt habe ich das folgendermaßen gemacht ...
Die folgende Änderung sollte meiner Meinung funktionieren aber das Ganze kann ich erst nach 18 weiteren Tagen sagen (dann kommt es zum nächsten Überlauf)
So lange ist das Zeugs noch ungetestet!
Code: [Auswählen]
(* // START -------------------------------- DAS IST MEINER MEINUNG FALSCH (mg 5.8.2014) --------------------------------------------
(* read actual startup info *)
(* OB1_SCAN_1 BYTE - B#16#01: Abschluss des Neustarts (Warmstarts)
- B#16#02: Abschluss des Wiederanlaufs
- B#16#03: Abschluss des freien Zyklus
- B#16#04: Abschluss des Kaltstarts
- B#16#05: Erster OB 1-Zyklus der neuen Master-CPU nach
Master-Reserve-Umschaltung und STOP des
bisherigen Masters *)
#ERR := RD_SINFO (TOP_SI => #TOP_SI, START_UP_SI => #START_UP_SI);
(* read system time *)
#tx := DINT_TO_TIME(DWORD_TO_DINT("T_PLC_MS"()));
(* reset last_time on system startup *)
IF #TOP_SI.EV_NUM = 1 OR #TOP_SI.EV_NUM = 2 OR #TOP_SI.EV_NUM = 4 THEN
#init := false;
END_IF;
(* initialize on startup *)
IF NOT #init THEN
#init := TRUE;
#last := #tx - #PT;
END_IF;
*)
// ENDE -------------------------------- DAS IST MEINER MEINUNG FALSCH (mg 5.8.2014) --------------------------------------------
// und wird ersetzt durchf die folgenden 2 Zeilen *)
"IDB_STIME"();
#tx := "IDB_STIME".tx;
(* hier muss die korrektur für step7 stattfinden
plctime muss den vollen wertebereich von time ausnutzen:
wenn bei step7 time -24tage bis plus 24 tage ist dann muss der timer auch beim überlauf auf -24tage springen
und auf keinen fall auf 0 !!!!
für siemens muss ein weiterer fb im main eingebunden werden der sicherstellt das alle 32 bits durchgezählt werden.
es kann nur ein fb sein den er muss sich das oberste (32te) bit merken.
oder etwa spring s7 bei überlauf auf -24 tage????? dann wäre keine korrektur nötig.
*)
(* generate output pulse when next_pulse is reached *)
#Q := #tx - #last >= #PT;
IF #Q THEN #last := #tx; END_IF;
(* revision hiostory
hm 25 feb 2007 rev 1.1
rewritten code for higher performance
pt can now be changed during runtime
hm 17. sep 2007 rev 1.2
replaced time() with t_plc_ms() for compatibility reasons
hm 25. oct. 2008 rev 1.3
optimized code
mg 5. aug. 2014 rev 1.4
problem with the internal-time variable after the overflow
*)
43
oscat.lib fuer Step 7 / Re: CLK_PRG: fehlerhafter Startwert
« am: 28. Juli 2014, 08:05:19 »
Naja ich habe schon was rausgefunden.
In der STIME_V1_5 wird ein ähnliches Verfahren verwendet. Das war anscheinend ein großes Problem dort.
ABER: ... da mir die Erklärung dieses Bausteins zu sparsam ist, kann ich den CLK_PRG zwar auf das selbe System ändern, aber was dort drinnen wirklich 100%tig passiert, ist mir noch nicht bis ins letzte Detail bekannt UND solange bleibt das für mich eine Problem.
Obs funktioniert weiß ich auch nicht, ... evtl weiß jemand wie ich das am besten testen soll!
Mario
HIER WÄRE EINE HILFE VON GKOBLER ODER DALBI HILFREICH.
In der STIME_V1_5 wird ein ähnliches Verfahren verwendet. Das war anscheinend ein großes Problem dort.
ABER: ... da mir die Erklärung dieses Bausteins zu sparsam ist, kann ich den CLK_PRG zwar auf das selbe System ändern, aber was dort drinnen wirklich 100%tig passiert, ist mir noch nicht bis ins letzte Detail bekannt UND solange bleibt das für mich eine Problem.
Obs funktioniert weiß ich auch nicht, ... evtl weiß jemand wie ich das am besten testen soll!
Mario
HIER WÄRE EINE HILFE VON GKOBLER ODER DALBI HILFREICH.
44
oscat.lib fuer Step 7 / Re: Heat_Temp Verständnisfrage
« am: 05. Juni 2014, 10:38:05 »
T_INT ist der Raumsollwert
wenn Du 22°C im Raum willst ist er halt 22°C
wenn Du lieber 28°C im Raum willst ist er 28°C
ABER: Das heißt nicht, daß Du 28°C im Raum bekommst.
Die Heizkurve berechnet aus einer Außentemperatur eine Vorlauftemperatur. Und wenn die Kurve korrekt eingestellt ist erhaltest Du mit dieser berechneten Vorlauftemperatur eine konstante Raumtemperatur und wenn Du nun T_INT um 1°C nach oben nimmst, wird deine tatsächliche Raumtemperatur um 1°C nach oben gehen.
ABER alles nur Theorie:
- keine Sonneneinstrahlung
- kein Wind
- keine Personen im Raum
- keine Küche in der gekocht wird
- keiner Lüftet
- keine Tür geht auf und zu.
uvm.
Das Ganze sollte UNGEFÄHR eine Vorlauftemperatur ergeben. Viele Parameter müssen geschätzt werden und die Einstellung braucht schon eine gewisse Erfahrung (da hilft einem auch der Installateur nicht weiter).
Viel Spass
PS: Es ist Sommer, HEAT_TEMP ... wofür???
wenn Du 22°C im Raum willst ist er halt 22°C
wenn Du lieber 28°C im Raum willst ist er 28°C
ABER: Das heißt nicht, daß Du 28°C im Raum bekommst.
Die Heizkurve berechnet aus einer Außentemperatur eine Vorlauftemperatur. Und wenn die Kurve korrekt eingestellt ist erhaltest Du mit dieser berechneten Vorlauftemperatur eine konstante Raumtemperatur und wenn Du nun T_INT um 1°C nach oben nimmst, wird deine tatsächliche Raumtemperatur um 1°C nach oben gehen.
ABER alles nur Theorie:
- keine Sonneneinstrahlung
- kein Wind
- keine Personen im Raum
- keine Küche in der gekocht wird
- keiner Lüftet
- keine Tür geht auf und zu.
uvm.
Das Ganze sollte UNGEFÄHR eine Vorlauftemperatur ergeben. Viele Parameter müssen geschätzt werden und die Einstellung braucht schon eine gewisse Erfahrung (da hilft einem auch der Installateur nicht weiter).
Viel Spass
PS: Es ist Sommer, HEAT_TEMP ... wofür???
45
oscat.lib fuer Step 7 / CLK_PRG: fehlerhafter Startwert
« am: 20. Mai 2014, 15:12:42 »
Hallo Leute
Programmiersystem: TIA12 SCL
Controller: CPU315
Baustein im Oscat: CLK_PRG
Nach einem Änderungsdownload wurden alle (od. viele, das kann ich im nachhinein nicht mehr sagen) Baugruppen gestoppt und neu gestartet.
Danach stand der Wert für "last" auf einem niedrigen negativen Wert (3-stellig), aber der Wert für "tx" irgendwo im x-stelligen negativen Bereich (-24Tage und noch ein bischen was).
Der PWM_DC rechnet aus der Differenz der beiden eine Zeit aus die dem Taktzyklus entsprechen sollte. Das würde heißen, daß der PWM_DC dieser Wert in meinem Fall erst in 24 Tagen korrekt funktioniert.
Die Initialisierung des CLK_PRG hat offensichtlich NICHT funktioniert.
Es wäre schön, wenn man in einem der folgenden Updates auch diesen Fehler mal eliminieren könnte.
Vielen Dank
Mario
Programmiersystem: TIA12 SCL
Controller: CPU315
Baustein im Oscat: CLK_PRG
Nach einem Änderungsdownload wurden alle (od. viele, das kann ich im nachhinein nicht mehr sagen) Baugruppen gestoppt und neu gestartet.
Danach stand der Wert für "last" auf einem niedrigen negativen Wert (3-stellig), aber der Wert für "tx" irgendwo im x-stelligen negativen Bereich (-24Tage und noch ein bischen was).
Der PWM_DC rechnet aus der Differenz der beiden eine Zeit aus die dem Taktzyklus entsprechen sollte. Das würde heißen, daß der PWM_DC dieser Wert in meinem Fall erst in 24 Tagen korrekt funktioniert.
Die Initialisierung des CLK_PRG hat offensichtlich NICHT funktioniert.
Es wäre schön, wenn man in einem der folgenden Updates auch diesen Fehler mal eliminieren könnte.
Vielen Dank
Mario