Beiträge

Das sind globale Variablen, d.h. in einer GVL deklariert:

Code Auswählen Erweitern

(* COM2 - EMH Stromzähler *)
Com2InData AT %I* : PcComInData;
Com2OutData AT %Q* : PcComOutData;
RxBuffer_Com2 : ComBuffer;
TxBuffer_Com2 : ComBuffer;


In und OutData sind dann im Systemmanager mit den Prozessdaten der seriellen Schnittstelle verknüpft.

Im Beckhoff Information System ist die Einbindung der Schnittstelle ganz gut beschrieben: http://infosys.beckhoff.de/index.php?content=../content/1031/tcplclibserialcom/html/tcplclibsercom_common.htm&id=

Aber ich dachte, Du hast eine Wago-Steuerung? Dann funktioniert das reine Einlesen der Daten von der Schnittstelle ja eh anders, und mein Beispiel dürfte für Dich erst ab der Zeile

Code Auswählen Erweitern

IF fbReceiveData.DataReceived THEN
interessant werden. Oder?

Hallo Marc,

für die von dir genannten Beispiele gibt es die Bausteine BLIND_NIGHT (Laden runter bei Nacht) und BLIND_SHADE (dto. bei Sonnenschein). Da werden dann von dir definierte Positionen angefahren. Für allgemeine Szenarios kommt BLIND_SCENE in Frage. In der OSCAT-Doku und auch hier im Forum findest du Hinweise, wie die Bausteine zu verschalten sind.

Natürlich kannst du den Klapperatismus auch von Hand programmieren. Aber vor dem Hintergrund, dass du in der SPS-Programmierung noch unerfahren bist, empfehle ich, erstmal mit den bestehenden Bausteinen loszulegen und zu sehen, wie weit du kommst.

Grüße,
mattsches

Naja, ob dem iPhone-Kompass so zu trauen ist...? Kontrollieren kannst du auch über den Schattenwurf z. B. eines Fensterrahmens. Dazu musst du die Ausrichtung der Fassade natürlich kennen. Lässt sich per Satellitenbild auf Google Maps aber ganz einfach herausfinden. Das nur als Tipp.

Mir ist der absolute Sonnenstand allerdings egal. Ich beobachte, bei welchem Winkel die Jalousie nach meinem Empfinden herunterfahren sollte, weil die Sonne herinkommt. Dann lese ich SUN_HOR ab und trage das beim BLIND_SHADE ein.

Ich verstehe noch nicht ganz, was du machen möchtest. Wenn du IN=True setzt und den Wert an PI änderst, fährt der Laden natürlich dahin. Das ist ja der Zweck der beiden Eingänge IN und PI.

Das von dir beobachtete Verhalten

Das funktioniert auch, aber wenn ich erst z.B. 100 und dann 80 eintrage, fährt die Jalousie erst bis 100 und dann wieder zurück nach 80. Gibt es da eine elegantere Lösung?

ist damit völlig normal. Es sei denn, du änderst den Wert an PI noch während der Fahrt. Gibst du z. B. 100 vor, läuft der Laden los. Wenn du dann gleich auf 80 änderst, fährt er nicht erst auf 100, sondern direkt auf 80.

Oder habe ich dich missverstanden, und du meinst etwas anderes?

Zu 1. Du hast Recht, die Beschreibung des BLIND_SHADE_S ist hier nicht korrekt. Beim BLIND_SHADE ist es richtig beschrieben:

Mit der Setup Variable SHADE_DELAY wird festgelegt wie lange nachdem SUN auf FALSE geht die Beschattung aktiv bleibt.

Macht aber nix. Du kannst ja einfach an der Beschaltung von SUN einen TON-Baustein mit der gewünschten Verzögerung vorschalten.

Zu 2. Dazu musst du am BLIND_INPUT die Setup-Variable MASTER_MODE auf TRUE setzen. Sonst führt der Baustein seine Ausgänge PO und AO immer über den aktuellen Istwert mit. Wenn der Laden durch BLIND_SHADE also geschlossen wird, übernimmt BLIND_INPUT PO=0. Schaltet sich dann der BLIND_SHADE mangels Sonne ab, wird eben dieser Wert verwendet - und der Laden bleibt unten. Mit MASTER_MODE=TRUE lässt der BLIND_INPUT an seinen Ausgängen die zuletzt von Hand angefahrene Position stehen. Und dort fährt der Laden bei Schatten dann hin.

Nö, gestestet habe ich nicht, war ein Schnellschuss aus der Hüfte.

Deine Zykluszeit kann es m. E. nicht sein. Falls du die Flankenerkennung im Verdacht hast, die funktioniert auch bei 50 µs Zykluszeit. Ich glaube also nicht, dass dir die 30 ms was bringen.

Getestet hast du ja aber vermutlich deine veränderte Version des BLIND_NIGHT, oder? Dass meine Variante nicht so funktionieren wird, hatten wir ja schon "trocken" festgestellt.

Probier's mal mit

LATITUDE = 51.4681
LONGITUDE = 6.9174

Die Werte werden im Gleitkommaformat in Grad angegeben, du bist um Faktor 10000 zu groß. Kann schon sein, dass das zu Rechenfehlern führt. Richtige Berechnungsergebnisse können so nicht herauskommen.

Ja, genau so ist das mit dem horizontalen Winkel gedacht. 210 bis 330 ° klingen bei einer nach Westen (=270°) ausgerichteten Fassade grundsätzlich plausibel. Die genauen Werte hängen von den baulichen Gegebenheiten ab, z. B. könnte ein vorstehender Anbau neben einem Fenster eine Beschattung bewirken, so dass erst später der Laden herunter gelassen werden muss.

Das mit der hochstehenden Sonne stimmt nicht ganz. Ein über dem Fenster herausragender Balkon oder ein Dachvorsprung kann z. B. dazu führen, dass du bei einer hoch stehenden Sonne keine Beschattung brauchst, bei einer tiefer stehenden allerdings schon.

Jau, du hast Recht, das wird wohl (leider) nicht so gehen.

Die Flankenerkennung ist nicht das Problem, der Vergleich auf <>141 bleibt true, auch wenn sich der Status von z. B. 132 auf 131 ändert. In dem Fall wird also keine positive Flanke erkannt, BLIND_INPUT.IN bleibt false. Aber der Handeingriff über S1/S2 führt ja selbst bereits dazu, dass der Status <>141 wird. Damit verpufft der Wert an BLIND_INPUT.PI. Man muss wohl doch tiefer eingreifen...

@NightWatcher: Du hast Recht, so trivial ist das gar nicht. Und die Zeile im BLIND_NIGHT, auf die ich verwiesen hatte, sollte besser drin bleiben. Wenn man den Rollladen nachts manuell hoch fährt, geht es sonst wieder runter, sobald der MANUAL_TIMEOUT rum ist. Und das möchte man in dem Fall wahrscheinlich nicht.

Knackpunkt ist der BLIND_INPUT mit seinem MASTER_MODE = TRUE. Dadurch gibt er an seinem PO immer die manuell angefahrene Position aus (was in vielen Situationen genau hilfreich ist, ich verwende ihn auch so). Letztlich muss dem BLIND_INPUT also beibringen, dass er bei Abschalten des BLIND_NIGHT seinen PO auf den gewünschten Wert setzt (vermutlich 255). Das ginge durch Abgreifen des STATUS hinter dem BLIND_NIGHT, Vergleich auf <> 141, positive Flanke (R_TRIG) und Verschalten des Ergebnisses an BLIND_INPUT.IN. An BLIND_INPUT.PI muss dann nur noch die gewünschte Position (=255).

Verwirrend? So:



Sollte eigentlich funktionieren.

[gelöscht durch Administrator]

HORZ1 und HORZ2 geben den Bereich des horizontalen Sonnenwinkels an, bei dem eine Verschattung erfolgen soll. VERT den maximalen vertikalen Sonnenwinkel.

Ist in der Doku eigentlich ganz gut beschrieben, wie ich finde:

Der Baustein wird scharfgeschaltet, wenn UP = TRUE, DN = TRUE, ENABLE = TRUE und SUN (für mindestens SHADE_DELAY) = TRUE. Sind diese Bedingungen erfüllt, prüft der Baustein, ob aktuell der horizontale Sonnenwinkel im Bereich zwischen HORZ1 und HORZ2 liegt und der vertikale Sonnenwinkel niedriger als VERT ist. Liegt nun auch noch die aktuelle Uhrzeit zwischen Sonnenaufgang + SUNRISE_OFFSET und Sonnenuntergang â€" SUNSET_PRESET, dann wechselt der Baustein in den STATUS 151 (Beschattung) und stellt sicher, dass am Ausgang PO kein
größerer Wert als SHADE_POS ausgegeben wird (PO ist dann das Minimum aus PI und SHADE_POS).

Für die Winkel HORZ1 und HORZ2 gilt: 90° = Osten, 180° = Süden, 270° = Westen.

Wegen der verschiedenen Positionen beim Öffnen und Schließen: Das liegt an der unterschiedlichen Geschwindigkeit, mit der dein Laden fährt. Runter vermutlich schneller als rauf. Der BLIND_CONTROL kann das insofern nicht abbilden, als man nur eine Zeit T_UD für beide Richtungen angeben kann. Um das zu ändern, müsstest du den BLIND_CONTROL anpassen und den BLIND_ACTUATOR, der darin aufgerufen wird.

Gruß,
mattsches

Je nach gusto. Allerdings sind die Editoren für die "traditionellen" Siemens-Sprachen KOP, FUP und AWL in Codesys - naja - grottig. Daher greife ich dort lieber zu CFC. Wobei ich noch nie ein FUP-Fan war.

Beispiele für Programme findest du hier im Forum häufig in Form von Screenshots. Meist CFC.

Hallo Tobias,

eigenartig, bei mir wird auf die oscat_basic_333.lib verwiesen. Und die findet er auch, da sie im Bibliotheks-Verzeichnis von Codesys (bzw. TwinCAT) liegt.

Normalerweise kannst du den Fehler beim Öffnen aber quittieren und dann im Bibliotheksmanager ggf. die oscat_basic (rot markiert) rausnehmen und die bei Dir installierte dafür rein.

Grundsätzlich handhabe ich das bei allerdings tatsächlich so, dass ich veränderte Bausteine unter neuem Namen im lokalen Projekt speichere. Die Bibliothek lasse ich unberührt. Grund: Dann habe ich im Zweifel immer noch die Originalversion greifbar. Wenn du einfach BLIND_INPUT mittels global suchen/ersetzen durch BLIND_INPUT_S ersetzt, wird überall der neue Baustein verwendet.

Wegen des automatischen Hochfahrens: Schau dir mal den BLIND_NIGHT an und darin den Kommentar in der zweiten Zeile. Dann sollte schnell klar sein, wie du das Verhalten wie gewünscht abändern kannst.

So ein bisschen Pfadfinderehrgeiz muss ja sein.  ;)

Gruß,
Mattsches

Kunststück, F_ und R_TRIG verwechselt...   ::)

Probier's mal so:

Code Auswählen Erweitern

rev_pos_open_fp : R_TRIG;
rev_pos_closed_fp : R_TRIG;


Rest bleibt gleich.

Gruß,
mattsches

Ihr könnte es ja mal mit der angehängten Variante probieren. Hab's nicht getestet, sollte aber funktionieren.

Bei REV_POS_OPEN/CLOSED einfach die Grenzwerte eintragen, ab denen die Bewegungsrichtung für den nächsten Tastendruck entsprechend gesetzt werden soll (z. B. REV_POS_CLOSED = 5 führt dazu, dass der nächste Tastendruck ein Öffnen bewirkt, wenn der Laden zuvor im Automatimodus auf POS <= 5 gefahren wurde).

Viel Spaß!

[gelöscht durch Administrator]