Ganz einfach erklärt warum es zeitkritisch ist ;-) Ich habe eine Sonnenstandsgeführte Lammelenwinkelverstellung programmiert. Meine Lamellenwinkelverstellung benötigt für die komplette Fahrt gerade mal 1100ms. Daher ist das ganze zeitkritisch.
Es sind 15 Jalousieen und 9 Rollläden. Sooo klein ist das Projekt also nicht. Desweiteren werden z.B. der Sonnenstand für meine GPS Position berechnet, Sonnenaufgang, Sonnenuntergang... Es gibt eine Nachtfunktion, eine Tagfunktion, eine Beschattungsfunktion, eine Scenenstellung, die ganzen Gruppen und Zentralfunktionen und selbstverständlich die ganzen Sicherheitsfunktionen (Wind, Regen, Feuer, Alarm..). Und das ganze hat selbstverständlich auch noch Handfunktionen

. Ein Großteil des Programms stammt aus der OSCAT Lib falls die einer kennt.
Das sollte somit jetzt auch das hier erklären
Ich fänds noch interessant wie man soviel Speicher und Zykluszeit für ne Rollosteuerung verbrät.
Nun würde ich gerne von dir wissen, du hast nur die Option optimierter Zugriff der DB's geändert und dadurch dann 10ms gewonnen, sonst hast du nichts am Programm geändert?
Das ist so korrekt^^ Wie gesagt, am schlimmsten war der Mischbetrieb wo ich darauf noch garnicht geachtet hatte. Und diesen enorm höheren Speicherverbrauch brauchten afair ausschließlich Bausteine mit reinem SCL Code dahinter!
@ Käse:
Vielen Dank für den Tip! Ich habe mir bisher auch mit Weckalarm OB´s beholfen. Noch eine Frage: Was hat das damit auf sich?
Setzt mal die Speicehrreserve bei den Datenbausteinen auf 0 Byte anstatt standardmäßig 100Byte pro Baustein (zu finden in den Bausteineigenschaften/ Laden ohne Reinitialisierung).
Also ich weiß wo und wie ich das einstelle. Nur weiß ich nicht wozu es gut ist und was es bewirkt.. So wie ich es verstehe, ist diese "Reserve" also ein leerer Bereich im Baustein der Platz reserviert nur dazu da, dass wenn ich nur wenige Bytes am DB ändere, dieser nicht komplett neu geschrieben werden muss und ich somit den DB auch nicht reinitialisieren muss, oder?
Leider sind bei mir alle Bausteine bereits ohne Speicherreserver :-/
@Lord_Anubis:
Edit: Dann dürfte doch aber die 1200er nicht schneller mit optimierten laufen
Also das verstehe ich aber dann auch nicht. Aber bei beiden CPU´s haben doch die optimierten Bausteine "nur" den Sinn das die Zykluszeit sinkt?
Danke schon mal an alle Beteiligten für die Infos

Langsam aber sicher kommt mehr Licht ins Dunkle :idea
EDIT: Huppalla ich habe jetzt nach der Antwort erst bemerkt das es ne 2. Seite gibt
Jo das mit dem Mischbetrieb war mir bereits bekannt, dass dieser durch die ständigen Umwandlungen extrem zeitintensiv ist. Das habe ich bereits in Siemens Dokumenten gelesen als ich schon versucht habe meine Zykluszeit zu minimieren.
@ RONIN:
Was bedeutet das? Das sagt mir leider garnix..
Naja, der größte Performanceverlust wird wohl durch das ständige Wandeln zwischen Big/Little-Endian anfallen.
Und warum müsste der Remanenzspeicherbedarf dann steigen? Das habe ich jetzt nicht bemerkt, aber wohl auch nicht beachtet, da ich mit dem noch keine Probleme habe. Und wie du schon geschrieben hast, gerade mit optimierten Bausteinen sollte man mit dem nicht schnell Probleme bekommen, da man ja jede Variable selbst entscheiden kann, ob diese remanent oder nicht remanent sein soll. Bei nicht optimierten ist daher der Verbrauch am höchsten weil du nur alles oder nichts machen kannst.
EDIT: Ach deine Aussage war ja eh genau so wie ich gerade geschrieben hab^^
Nur eins verstehe ich dann nicht:
Insofern müsste man dann doch mit nicht optimierten Bausteinen schneller voll werden weil die ja voll auf den Remanenzspeicher gehen.
Was hat der Arbeitsspeicher dann mit dem Remanenzspeicher zu tun? Das sind ja 2 völlig unterschiedliche und getrennte Speicher?? Oder meinst du nur den Remanenzspeicher der schneller voll werden müsste?
So ist mein derzeitiger Zustand der kompletten Steuerung:
