Nachrichten

91

SPS-Hardware / Thermkon Gateway TCPIP <-> Enocean

« am: 22. Oktober 2010, 11:11:15 »

Hallo Leute

Hat jemand schon mal versucht dieses Gateway
http://www.thermokon.de/DE/easysens/stcethernet--gateway.html
zu verwenden.

Mir gefällt es. Es ist "bidirektional", es geht mit TCPIP ... nur ich füchte mich derzeit noch vor dem Programmieraufwand.
Die Kosten (OHNE RABATT) sind zwar etwas höher als bei der RS232 Version (aber die ewigen Timingprobleme mit der RS232 (zB Wago) sind hier nicht mehr vorhanden) und dafür brauche ich aber keinen RS232 Ausgang beim Controller  oder bei dem Original Wago Interface (ist nicht bidirektional).
Leider ist kein ModBus TCPIP drauf ... und ich täte das ERSTE Mal die Ethernet-Schnittstelle frei programmieren ... ich weiß noch nicht ob ich mir das antun soll.

Mario

92

oscat.lib fuer TwinCAT/CoDeSys / Re:FBH Steuerung mit ACTUATOR_2P

« am: 19. September 2010, 07:07:20 »

Du gehst mit Ist- und Sollwerteingang erst mal auf einen PID (Einstellung Verstärkung bei Ausgang 0-100% ca. 100%/2°C=50, Nachstellzeit und Vorhaltezeit am besten keine). Den Ausgang führst Du auf eine PulsWeitenModulation mit einigermaßen kurzen Pulsweite. (Zu kurz führt zu einem zu often Schalten des Relais (evtl TRIAC verwenden). Zu lange führt zu einem dauerenden Öffnen und Schließen des Ventils (die meisten THERMISCHEN Fbh-Ventile darf man nur 2x am Tag öffnen und schließen!) --- Normalerweise sollte das Ventil in einer Zwischenstellung gehalten werden. Ich empfehle ca. 30sec(Triac) bis 2min(Relais). Weiters ist wichtig, daß das Ventil zumindest 1x in der Woche in der Sommenzeit geöffnet wird, da die meisten Ventile mit einer Weichdichtung schließem und diese Dichtungen anfällig sind sich mit dem Ventilsitz zu verkleben. Eigentlich ist es aber ziemlich egal wie man die Fbh regelt (da gibt es mehrere Möglichkeiten und die funktionieren alle mehr oder weniger) ... siehe nächster Absatz ...

... eigentlich ist die Regelung der Fbh primitiv, da sich jede Fbh sich selbst schon mal ganz gut OHNE REGELVENTILE regelt, da der Temperaturunterschied zw. Raumtemp. und Vorlauftemp. gering sein sollte und die Energieabgabe nur auf dieser Differenz basiet. Wenn das nicht der Fall ist empfehle ich eine geeignete Vorregelung (mit Pumpe und Ventil) sonst wird das Ergebnis NIE zufriedenstellend werden. Weiters fehlt in deinem Beispiel das Zeitprogramm.

... wenn man einen Doktor daraus machen will empfehle ich die Fbh mit einer automatischen Einschaltoptimierung (mit Zeitprog.), das hat den Vorteil, daß man am Morgen wirklich die Temperatur im Raum hat, die man haben will (und nicht vorher und nicht zu spät). Ein Fbh reagiert mit einer Verzögerung je nach Auflage von ca. 1h pro cm Boden über dem Fbh-Rohr. Hier wäre aber das Überschwingen durch die große Totzeit unbedingt mitzuberücksichtigen. ... wenn Sie das vorhaben wirds aber ein MORDS Regelungsaufwand und eine geeignete Vorregelung ist dann unbedingt erforderlich.


Viel Spass

PS: ich habe den Actuator_2P noch nie verwendet ... soll aber wie ein PWM-Signal reagieren. Wenn Sie den verwenden wollen, dann müssen Sie eigentlich die Zuführung auf den Actuator_2P mit einem Regler ausführen zB.: PIDWL. (dann müssen sie sich erst mal auf einen für Sie logischen Ausgang für den Regler einigen (zB.: 0-100% oder 0-1 [ohne Einheit]) ... usw....

93

oscat.lib fuer Step 7 / Re:Actuator 3P bleibt stehen!!

« am: 29. Dezember 2009, 04:06:19 »

Hallo Hugo

Hmm ... neu machen ... das hat mich aufgeschreckt!

Ich war bisher auch nicht grad glücklich mit diesem Baustein (und habe ihn deshalb auch nicht mehr verwendet) ALLERDINGS IM CODESYS.

Bitte lasse folgende Punkte einfließen:

- Synchronisieren darf teilweise nur in eine Richtung erfolgen (auf 0% od. 100%). zB Dampfregister (NIEMALS auf AUF). Kondensatorventil Kältemaschine (NIEMALS auf ZU).
- Synchronisieren ohne Endschalter (die meisten Antriebe haben nur einen internen oder gar keinen Endschalter). zB.: 2 min auf "ZU" oder "AUF".
- Synchronisieren muß "automatisch erfolgen". Wenn ein Antrieb ohne Endschalter bei POS 0% steht muß die Steuerung DAUERND ein "ZU"-Signal geben oder bei POS 100% steht muß die Steuerung DAUERND ein "AUF"-Signal geben. DAUERND (bei internen Endschaltern) kann in diesem Fall auch nur EINE GEWISSE ZEIT (bei Rutschkupplung und Magnetkupplung) sein. Damit wird verhindert, daß die Rutschkupplung nicht übermäßig belastet wird und natürlich auch wegen des Energieverbrauchs. So erfolgt in der Endlage immer eine automatische Synchronisation, wenn die Laufzeit des Antriebs ein paar sec. länger eingegeben ist als sie tatsächlich ist. Das Ganze stört einen PI bzw PID Regler überhaupt nicht. Und wenn man das Ganz genau haben will kann man es ja auf die sec. genau eingeben.


siehe dazu auch LINK: http://www.oscat.de/community/index.php/topic,411.0.html ganz am Ende. Da habe ich mal diese Änderungen gößtenteils einfließen lassen. (allerdings ohne Option "Rutschkupplung")

Vielen Dank für Euer Verständnis.


PS: Weiters sollten viele Antriebe im Anlagenstillstand mal bewegt werden. (zB jede Woche einal ganz "auf" und "zu")

94

Bestehende Module / Existing Modules / OSCAT Versions history

« am: 17. Dezember 2009, 05:24:00 »

Hallo Oscat

Warum wird die OSCAT-Versions-history datei nicht mehr nachgeführt? Schaue alle 2 Tage seit der neuen Version mal rein, aber die bleibt bei 3.10 stehen. Für mich ist das sehr ineressant, damit ich weiß bei welchen Projekten ich Nachholbedarf habe.

Vielen Dank

95

Bestehende Module / Existing Modules / Re:OnTime PERSISTENT RETAIN

« am: 28. September 2009, 04:43:18 »

Hallo Hugo

... kann man da was in der nächsten Version einfließen lassen? Ich hatte bis vor einem halben Jahr immer einen selbstgebastelten ONTIME verwendet, will aber unbedingt komplett auf OSCAT umsteigen und so wenige selbstgeschriebene LIBs wie möglich verwenden. Leider komm ich nicht ganz umhin.

Danke

96

Bestehende Module / Existing Modules / Re:OnTime PERSISTENT RETAIN

« am: 22. September 2009, 06:20:29 »

Hallo hugo

Ja ich weiß, daß das so gehen sollte ...

... aber bei mir taucht folgendes Problem dazu auf: Da ich dieses Modul in einen Funkionsbaustein eingebunden habe und dieser Funktionsbaustein sollte grad NICHT persistent retain sein sollte. (Lt. Codesysbeschreibung kann ich nur ALLES in diesem Baustein persistent retain oder gar nix persistent retain machen). So wollte ich mir die beiden Variablen praktisch von "außerhalb" (in meinem Fall von den Globalen Variablen) holen.

Danke

97

Bestehende Module / Existing Modules / OnTime PERSISTENT RETAIN

« am: 21. September 2009, 08:41:38 »

Habe die SECONDS und die CYCLES mit einer PERSISTENT RETAIN beschalten. Aber das wird nach jedem Download neu mit "0" beschrieben.

Das Modul "OnTime" ist in einem NICHT "PERSISTENT RETAIN" Funktionsblock untergebracht. Die Variablen werden dorthin übergeben und sind global deklariert.
... ist schon etwas komisch. Müßte eigentlich gehen. (Bei allen anderen Variablen funktioniert auch)

Danke

PS: Habe das Problem eigentlich schon sehr lange, aber bisher keine Zeit zum Schreiben gefunden

98

Bestehende Module / Existing Modules / PIDWL mit negativem KP

« am: 18. September 2009, 12:11:56 »

kann es sein, daß de PIDWL in der Version 3.10 immer noch nicht auf negative KP reagiert? (War der Meinung, daß dieser Fehler korrigiert sein sollte)
Bei mir gings nicht. Habe dann aber auch nicht ewig rumgespielt und gleich den Eingang invertiert um ein korrektes Verhalten zu erreichen

99

Bestehende Module / Existing Modules / Re:Nochmal Actuator_3P

« am: 18. September 2009, 11:51:51 »

Ich hatte selbige Probleme und den Baustein inzwischen neu geschrieben. Damit habe ich beste Erfahrungen gemacht und verwende ihn inzwischen ständig auch für sehr kritische Anwendungen, außerdem wollte ich, daß die Synchronisation nur in eine Richtung erfolgt:

Trotzdem muß ich zugeben, daß der Baustein sicher nicht optimal geschrieben wurde (habe ich irgendwo mal auf der Baustelle schnell runtergetippt)

Wenns jemand haben will kann er's verwenden


FUNCTION_BLOCK ACTUATOR_3P_new
VAR_INPUT
   In_r:REAL;            (* Input in 0 - 100% *)
   max_runtime_t:TIME;   (* Stellzeit in t#..s *)
   Sync_x:BOOL;         (* Synchronisation *)
   Sync_dir_x:BOOL;      (* Sync 0 = Sync auf "0", Sync 1 = Sync auf "100" *)
   time_min_off_t:TIME;   (* Mindest-Ausschaltzeit Antrieb *)
   time_min_on_t:TIME;   (* Mindest-Laufzeit Antrieb *)
END_VAR
VAR_OUTPUT
   Mode_i: INT;      (*0=fully opened    1= open   2=stop      3=close   4=fully closed*)
   Y_3p_b:BYTE;      (*0=close, 1=stop, 2=open*)
   Y_open_x: BOOL;
   Y_close_x: BOOL;
   Pos_r:REAL;
END_VAR
VAR
   Nz: REAL;                  (* neutral zone *)
   Pos_open: REAL;
   Pos_close: REAL;
   InSy_r: REAL;               (* Input in 0 - 100% included Synchronisation*)
   acttime_new: DWORD;      (* actual time *)
   acttime_close: DWORD:=0;
   acttime_stop: DWORD:=0;
   acttime_open: DWORD:=0;
   Stop_close: BOOL;
   Stop_open: BOOL;
   diffacttime_time_close: DWORD;
   diffacttime_time_stop: DWORD;
   diffacttime_time_open: DWORD;
   Stop_close_del1cyc: BOOL;
   Stop_open_del1cyc: BOOL;
   max_runtime_r: REAL;
   Pos_old_r: REAL;
   SYNC_Imp:BOOL;
END_VAR

Nz:=100*TIME_TO_REAL(time_min_on_t)/TIME_TO_REAL(max_runtime_t)-0.001;
max_runtime_r:=TIME_TO_REAL(max_runtime_t);

IF Sync_x=TRUE
   THEN
   IF SYNC_Imp=TRUE
      THEN
      acttime_stop:=acttime_new;
      SYNC_IMP:=FALSE;
   END_IF;
   IF Sync_dir_x=FALSE
      THEN
      InSy_r:=0;      (* synchronisation CLOSE *)
      ELSE
      InSy_r:=100;   (* synchronisation OPEN *)
   END_IF;
   ELSE
   SYNC_Imp:=TRUE;
   InSy_r:=In_r;      (* no synchronisation *)
END_IF

IF InSy_r>0
   THEN
   Pos_close:=Pos_r-Nz;
   ELSE
   Pos_close:=Pos_r;
END_IF

IF InSy_r<100
   THEN
   Pos_open:=Pos_r+Nz;
   ELSE
   Pos_open:=Pos_r;
END_IF




acttime_new:=TIME_TO_DWORD(TIME());


diffacttime_time_stop:=acttime_new-acttime_stop;

IF diffacttime_time_stop>TIME_TO_DWORD(time_min_off_t)
   THEN
   IF Pos_r<=0
      THEN
      IF InSy_r=0
         THEN
         Mode_i:=0;
         Stop_close:=FALSE;
         ELSE
         Stop_close:=TRUE;
      END_IF;
      ELSE
      IF InSy_r<Pos_close AND Stop_open_del1cyc=TRUE
         THEN
         IF Mode_i<>1
            THEN
            acttime_close:=acttime_new;
         END_IF;
         Mode_i:=1;
         Stop_close:=FALSE;
         ELSE
         IF diffacttime_time_Close>TIME_TO_DWORD(time_min_on_t)
            THEN
            Stop_close:=TRUE;
         END_IF
      END_IF;
   END_IF;
   Stop_open_del1cyc:=Stop_open;

   IF Pos_r>=100
      THEN
      IF InSy_r=100
         THEN
         Mode_i:=4;
         Stop_open:=FALSE;
         ELSE
         Stop_open:=TRUE;
      END_IF;
      ELSE
      IF InSy_r>Pos_open AND Stop_close_del1cyc=TRUE
         THEN
         IF Mode_i<>3
            THEN
            acttime_open:=acttime_new;
         END_IF;
         Mode_i:=3;
         Stop_open:=FALSE;
         ELSE
         IF diffacttime_time_open>TIME_TO_DWORD(time_min_on_t)
            THEN
            Stop_open:=TRUE;
         END_IF
      END_IF;
   END_IF;
   Stop_close_del1cyc:=Stop_close;

   IF Stop_close=TRUE AND Stop_open=TRUE
      THEN
      IF Mode_i<>2
         THEN
         acttime_stop:=acttime_new;
      END_IF;
      Mode_i:=2;
   END_IF;
END_IF


diffacttime_time_close:=acttime_new-acttime_close;
diffacttime_time_open:=acttime_new-acttime_open;

(*0=fully closed   1=close   2=stop      3= open   4=fully opened*)
CASE Mode_i
   OF
   0:
   Y_close_x:=TRUE;
   Y_open_x:=FALSE;
   Y_3p_b:=0;
   Pos_r:=0;
   Pos_old_r:=Pos_r;

   1:
   Y_close_x:=TRUE;
   Y_open_x:=FALSE;
   Y_3p_b:=0;
   Pos_r:=Pos_old_r-100*DWORD_TO_REAL(diffacttime_time_close)/max_runtime_r;

   2:
   Y_close_x:=FALSE;
   Y_open_x:=FALSE;
   Y_3p_b:=1;
   Pos_old_r:=Pos_r;

   3:
   Y_close_x:=FALSE;
   Y_open_x:=TRUE;
   Y_3p_b:=2;
   Pos_r:=Pos_old_r+100*DWORD_TO_REAL(diffacttime_time_open)/max_runtime_r;

   4:
   Y_close_x:=FALSE;
   Y_open_x:=TRUE;
   Y_3p_b:=2;
   Pos_r:=100;
   Pos_old_r:=Pos_r;
END_CASE

100

Bestehende Module / Existing Modules / Re:OnTime

« am: 13. September 2009, 13:29:17 »

Danke für Deine Antwort.

Ich glaubs ja auch nicht, daß es wirklich so ist, daß die Steuerung jeden Scheiß auf das Flash schreibt. ABER ...

  leider weiß ich nicht genau wie die Steuerung das handhabt. ... Deshalb die obige Frage.

Natürlich ändert sich der Betriebsstundenzähler dauernd. Ich hoffe, daß mit PERSISTANT RETAIN das Verhalten so ist wie von dir beschrieben.   Theoretisch könnte es aber auch anders sein und die Steuerung schreibt sich "deppert".

Hoffen wir mal daß das nicht so ist.

Vielen Dank

PS: Bei irgendwelchen Applikationen hab ich das Problem nicht, da hab ich es ja selbst im Griff. Aber bei jedem "Automatismus" ... Hmmm ... wer weiß es?

PPS: Und grad beim Betriebsstundenzähler wären die 100000 sehr schnell erreicht -> Bei 100ms Zykluszeit in Grad mal 2,7h. Wenn das Gerät dann noch irgend eine Fehlerauswertung hat dann halt noch etwas länger, aber dann wird der Speicher halt sukzessive kleiner

101

Bestehende Module / Existing Modules / OnTime

« am: 13. September 2009, 06:09:48 »

... nochmals eine Frage zum Betriebsstundenzähler

So wie ich das sehe muß ONTIME im PERSISTANT RETAIN Bereich abgelegt sein. Sonst ist er logischerweise bei jedem Spannungsunterbruch oder bei jeder Softwareänderung wieder "0":

Das Problem für mich ist, daß ich gelesen habe, daß nach einer gewissen Anzahl vom Schreibzyklusen auf den Flash-Speicher defekt wird. Trifft das auch bei dieser Art von Wertspeicherung zu? Oder kann ich das irgendwie umgehen ... oder mache ich was falsch?

PS: Ich verwende das Gerät WAGO 750-841

 

102

oscat.lib fuer TwinCAT/CoDeSys / Re: Fehlermeldungen oscat304.lib beim Implementieren

« am: 19. Juni 2009, 15:11:07 »

... kaum macht man es richtig funktionierts auch schon.

DANKE !!!

103

oscat.lib fuer TwinCAT/CoDeSys / Re: Fehlermeldungen oscat304.lib beim Implementieren

« am: 19. Juni 2009, 13:56:01 »

Ich habe das selbe Problem. Natürlich kann ich die die ich nicht brauche ausschließen. Damit fallen fiele weg und wahrscheinlich alle die was zufälligerweise einen Fehler haben auch: ABER wenn ich sie nun brauche ... HMMM ... (ist leider bei mir der Fall)
Das Problem taucht mit der Oscat 3.04 und dem NEUESTEN Update von Codesys auf. V2.3.9.13
Hier wurde einiges an der Codesys-Software geändert. Dh. alle meine alten Projekte laufen nicht mehr. Gravierend is der Umstand, daß zB

(* TEST1 (* TEST2*) TEST3 *)
... wurde früher einwandfrei akzeptiert wurde. NEU wird mit dem ERSTEN *) der komplette Hilfetext geschlossen.
==> TEST3 wird als Variable erkannt, ist aber ein Hilfstext. Vielleicht hat die neue Oscat die selben Leichen drin wie ich.

zB: CRC_GEN
(* align crc checksum to right side of dword *)
CRC_GEN := SHR(data,32 - p_length +1);
*)


Vielleicht habe ich nicht Recht und mache einen mir unbekannten Fehler ... Bitte um INFO.
PS: Ich kann auf private Nachrichten nicht antwoirten ... Ich bekomme immer einen "Datenbankfehler"

104

Bestehende Module / Existing Modules / Re: Widerstandsmessung Wago

« am: 12. Juni 2009, 08:38:52 »

ModBus-RTU Busfähige Temperaturfühler zB.: von http://www.eap-electric.at/uploads/tx_lxeap/Anleitung_Raumbusgeraet_Modbus_RTU__Data_Mode.pdf
Es beschäftigen sich auch div. andere Hersteller mit diesem Bus. Ist aber alles erst im werden UND natürlich auch eine Preisfrage. Wäre aber ne interessante Alternative. Je nach Modbus-Treiber sind zw 32 und 128 Geräte anschließbar.

105

Modulentwicklung / Module Development / Re: Danfoss RS485

« am: 12. Juni 2009, 08:33:41 »

Anwendungsbeispiel haben die bei WAGO. Du brauchst wie gesagt eine 750-65x/* Karte. Rs485 beim Danfoss - was ich weiß. Du kannst ja mal beim Support nachfragen, die helfen Dir gerne. Ich habe noch kein Danfoss-Gerät damit aufgeschalten aber schon ein paar andere mit Modbus RS485. Es geht. Die Lösung/Lib von Wago ist ein bischen chaotisch. Deswegen und auch aus anderen Gründen hätte ich gerne eine OpenSource-Lib für das Ganze. Aber das sieht eher so aus, daß es keiner hergibt. Und/Oder es wirklich noch niemand außer die Steuerungshersteller selbst geschreiben haben.

PS: Mit "Hugo" habe ich nicht Wu Fu gemeint sondern einen der Administratoren des Forums