Blind_Shade_S Eingang CX beschalten

Begonnen von goifalracer, 12. Dezember 2016, 12:04:50

Vorheriges Thema - Nächstes Thema

0 Mitglieder und 2 Gäste betrachten dieses Thema.

goifalracer

Hallo Zusammen,

ich habe ein paar Schwierigkeiten mit dem Baustein Blind_Shade_S.
Und zwar weiß ich nicht wie ich den Eingang CX (Kalender,Datum und Zeit) beschalten soll.

Ich arbeite  mit Codesys 2.3 unter Wago.

Welcher Datentyp ist das eigentlich? Ich meine den sollte ich unter definierte Typen finden?
Oder brauche ich da zuerst noch einen Baustein der mit die Daten von der RTC abgreift.


Würde mich um Unterstützung freuen.

Vielen Dank.



mattsches

Mal stichpunktartig:


  • globale Variable vom Typ CALENDAR (hier beispielhaft "CalendarData" genannt)
  • CalendarData.Longitude und CalendarData.Latitude mit den (möglichst genauen) GPS-Koordinaten deines Hauses beschreiben; reicht einmalig bei der Initialisierung der Variable
  • Uhrzeit in Lokalzeit oder UTC (je nach Ausführung) von der Wetterstation holen
  • Uhrzeit falls nicht schon in UTC vorliegend dahin konvertieren (LTIME_TO_UTC) (
  • Uhrzeit in UTC nach CalendarData.UTC schreiben
  • Instanz des FBs CALENDAR_CALC aufrufen, SPE := TRUE setzen und die "CalendarData"-Variable übergeben

Der CALENDAR_CALC berechnet dann einmal am Tag die Sonnenauf- und -untergangseiten und zyklisch die aktuelle Sonnenposition und schreibt sie nach CalendarData. Beschrieben ist das Ganze in der Doku der OSCAT_BASIC, Kap. 12.2.

goifalracer

Vielen Dank,

werde mich da mal einarbeiten.

goifalracer

#3
Hi Mattsches,

sorry das ich wieder nerve, aber ich kriegs nicht gebacken.
Hab mal Screenshots angehängt, wies bei mir ausschaut.

Es scheitert an HOLIDAY_DATA. Hab mir in der Basic Lib mal die Datentypen angeschaut und muss sagen das ich das nicht ganz verstehe wie ich dieses Array ausserhalb definieren soll.

Im externen Array HOLIDAYS können bis zu 30 Feiertage defniert werden.
Beispiele hierfür fnden Sie bei der Beschreibung des Datentyps
HOLIDAY_DATA. Dieses ARRAY of HOLIDAY_DATA muss außerhalb des Bausteins
defniert werden und als Variable mit den Feiertagsdaten vorbelegt
werden.



Ich bekomme nämlich einen Fehlermeldung (siehe Screenshot) die mit dem Holiday zusammenhängt.

Die UTC hole ich mir von der SPS nicht von der Elsner, sollt eja auch gehen.


Was mache ich da noch falsch???

Danke für deine Geduld.




[gelöscht durch Administrator]

mattsches

#4
Hi,

ganz einfach:


Globale Variablenliste:


* OSCAT Kalenderdaten *)
cxCalendar : CALENDAR := (
Longitude := 1.23456,
Latitude := 7.891234);

(* Kalenderdaten gemäß OSCAT.lib inkl. Sonnenposition *)
HOLIDAY_DE : ARRAY[0..29] OF HOLIDAY_DATA := (name := 'Neujahr', day := 1, month := 1, use := 1),
(name := 'Heilig Drei Könige', day := 6, month := 1, use := 1),
(name := 'Karfreitag', day := -2, month := 0, use := 1),
(name := 'Ostersonntag', day := 0, month := 0, use := 1),
(name := 'Ostermontag', day := 1, month := 0, use := 1),
(name := 'Tag der Arbeit', day := 1, month := 5, use := 1),
(name := 'Christi Himmelfahrt', day := 39, month := 0, use := 1),
(name := 'Pfingstsonntag', day := 49, month := 0, use := 1),
(name := 'Pfingstmontag', day := 50, month := 0, use := 1),
(name := 'Fronleichnam', day := 60, month := 0, use := 1),
(name := 'Augsburger Friedensfest', day := 8, month := 8, use := 0),
(name := 'Maria Himmelfahrt', day := 15, month := 8, use := 1),
(name := 'Tag der Deutschen Einheit', day := 3, month := 10, use := 1),
(name := 'Reformationstag', day := 31, month := 10, use := 0),
(name := 'Allerheiligen', day := 1, month := 11, use := 1),
(name := 'Buss und Bettag', day := 23, month := 11, use := 0),
(name := '1. Weihnachtstag', day := 25, month := 12, use := 1),
(name := '2. Weihnachtstag', day := 26, month := 12, use := 1);


Ein solches Beispiel steht aber auch in der Doku für HOLIDAY_DATA.

An den CALENDAR_CALC übergibst du dann das ganze Array HOLIDAY_DE. Die Zyklische Zuweisung der GPS-Koordinaten ist nicht falsch, mit der obigen Deklaration inkl. Initialisierung (musst natürlich deine Koordinaten einsetzen) aber unnötig.

Kleiner Tipp: Ich würde die Koordinaten im Screenshot unkenntlich machen. Zumindest wenn du nicht jedem deinen Wohnort verraten willst.

UTC kannst du natürlich auch von der SPS nehmen, klar. Ich nehme die Info von der Elsner, weil die immer genau ist (GPS-Information). Die SPS-Uhr stelle ich einmal am Tag; dann läuft sie mir auch über längere Zeit hinweg nicht davon.

Gruß,
mattsches

goifalracer

Hi mattsches,

danke, hat geklappt. Den Längen und Breitengrad habe ich mal weg gelassen weil ich den eh über CX reinbekomme.

Aber ich habe ein Problem festgestellt und zwar stimmen bei mir die Werte für Sunset und sunrise nicht. Längen und Breitengrad stimmen aber.
Was kann das sein?

Ich habe im Anhang Screenshots, ahe ich da noch was falsch beschaltetet?
Möchte nämlcih die Nachtschaltung und die Beschattung testen.

Danke.

[gelöscht durch Administrator]

mattsches

Also wenn du den Screenshot gerade erst gemacht hast, dann arbeitet deine SPS (wenig überraschend) mit Lokalzeit und nicht UTC. Sonst müsste Kalender_Global.UTC = DT#2016-12-16-13:44:58 sein. Das kann an anderer Stelle zu Problemen führen. Du solltest also unbedingt von Lokalzeit auf UTC wandeln und dann erst in Kalender_Global.UTC schreiben.

Dann verstehe ich deine Aussage nicht ganz:

Zitat von: goifalracer in 16. Dezember 2016, 14:51:59
Den Längen und Breitengrad habe ich mal weg gelassen weil ich den eh über CX reinbekomme.

Was heißt das? Werden Kalender_Global.Latitude und .Longitude nun mit den korrekten Werten initialisiert oder (was unnötig wäre) zyklisch beschrieben oder hast du das weggelassen?

Sonnenauf- und -untergang werden übrigens soweit ich mich erinnere nur einmal am Tag berechnet. Schau mal in die Doku zum CALENDAR_CALC, da müsste das beschrieben sein. Hierdurch kann es sein, dass du nach einer Änderung (z. B. der Koordinaten) erst am nächsten Tag korrekte Zeiten hast.

goifalracer

Ja ich hatte UTC +1 eingestellt und gestern schon auf UTC aumgestellt dann aber wieder zurückgestellt.
Jetzt ist UTC drin und hab aktuell 1 Stund minus MEZ.
In der doku habe ich nichts gefunden aber meine das mal im Forum gelesen zu haben.

Die Längen und Breitengrade Werte habe ich Online auch in XCAL, deswegen habe ich Sie weggelassen in der Structure von Holiday. Kann die aber wieder hinschreiben, dann habe ich das falsch verstanden.

Dann muss ich die Test SPS mal laufen lassen ob dann am nächsten TAG der sunset und sunrise stimmt, da fehlt es jetzt um fast zwei Stunden.

Verständnissfrage:
Zum testen habe ich an einem Fenster das im Süden liegt am Blind_Shade den Horiz 1 mit 150 angegeben und den Horiz 2 mit 200. dann sollte der Rollo ab Sonne 150 nach unten fahren so weit ich definiere und bei 200 komplett hochfahren. Habe ich das richtig verstanden.??

Danke.


mattsches

Längen- und Breitengrad haben mit der Kalender-Struktur auch nichts zu tun. In meinem Beispiel oben wird eine CALENDAR-Variable deklariert und Längen- und Breitengrad darin initialisiert. Wenn die Werte in der SPS passen, dann kann das ja nicht der Fehler sein. Die Initialisierung oder die Zuweisung im Programm sind jedoch wichtig, damit auch nach einem Neustart der Steuerung die Werte noch stimmen.

Wenn du mit "Sonne 150" den horizontalen Sonnenwinkel meinst, dann stimmt deine Aussage zum Hoch- und Runterfahren.

goifalracer

#9
Hallo Mattsches,

hab das ganze denke ich verstanden. Die Rollos verschatten und gehen wieder nach oben.
Nur das mit dem Zeitversatz von 2 Stunden bringe ich nicht hin. Sunset und Sunrise weichen um 2 Stunden  ab, die RTC der Wago habe ich schon auf UTC gestellt.

Du hast gesagt das Sunrise und Sunset nur einmal am Tag aktualisiert wird. Die SPS ist bei mir eine Teststation die läuft nur ein paar Studen wenn ich bastele, aber wenn ich die SPS neustarte müssten sich doch die neuen Zeiten initialieseren oder?

Oder ich habe im XCAL noch nen bock drin.

Ich habe nochmal die relevanten Screenshots angehängt weil ich komm einfach nicht drauf.

Würde mich freuen wenn du mir noch nen Tipp geben könntest.

Vielen Dank.


[gelöscht durch Administrator]

mattsches

Soweit ich das erkenne, werden die Zeiten auch nach dem Einschalten berechnet, da auch in dieser Situation ein Tageswechsel erkannt wird.

Für mich sieht es so aus, als wären die Koordinaten schlichtweg falsch. Denn die Zeiten sind ja nicht in eine Richtung verschoben, so dass man auf UTC vs. LTC schließen könnte. Sondern der Tag wird ja viel zu lang berechnet (zu früher Sonnenauf- und zu später -untergang).

Bist du dir bzgl. Latitude und Longitude sicher?

goifalracer

#11
Hallo,

erstmal frohe Weihnachten.

Die Geo Daten sind richtig. Habe zum testen mal die Geodaten von Moskau eingegeben, bei sunrise und sunset gabs nach bootprojekt erzeugen und Kaltstart der SPS auch keine Änderung.
Was mir noch aufgefallen ist, dass die Lokalueit in XCAL auch nicht stimmt die ist wie die UTC, ich glaube da stimmt von vorn herien was nicht.
Aus der SPS übergebe ich definitiv UTC und die Kordinaten stimmen.

Entweder muss die SPS mal 24 h durchlaufen oder es liegt an meinem Code.
Ich werde die SPS die nächsten Tage mal durchlaufen lassen, ausser dir fällt noch was ein?

Es ist komisch weil die anderen Daten von XCAL stimmen alle und Übersetzungsfehler kommen auch keine.

Danke.

goifalracer

Hi,

also soweit ich das beurteilen kann funktioniert das ganze.
LTOD war falsch weil ich den Zeit Offset mit 0min beschalten habe, aktuell sind jetzt 60min drin.
Die Sunrise und Sunset Zeiten wurden erst bei Tagwechsel berechnet, SPS musst mal durchlaufen.

Alles in allem fahren die Rollos über Blind_Shade_S runter und wiede rauf und bei Blind_Night runter und auch wieder hoch.

Da ganze wird jetzt bei nem Kumpel mit Sonnensensoren programmiert und bei meinen Neubau dann mit ner Elsner, aber soweit ich das jetzt beurteilen kann, funktioniert das genial.

Danke für die große Unterstützung, wenn ich nochmal Probs habe melde ich mich hier im Forum nochmal.

Guten Rutsch.