Hast du vielleicht eine gute Lektüre als Tipp für mich wo man entweder, typische Algorithmen für SPS oder Herangehensweise zum nachschlagen hat?
Nach meiner Meinung gibt es nicht DAS Nachschlagewerk ...
Wie sollte es auch aussehen und was sollte es alles beinhalten?
Und auf welche verschiedenen Typen von Interessenten/Lesern mit welchen Vorkenntnissen und Fähigkeiten soll/könnte "DAS Nachschlagewerk" zugeschnitten sein?
Ich sehe eine Bandbreite von Leuten mit extrem schlechtem Gedächtnis bis hin zu Leuten mit extrem gutem Gedächtnis.
Ich gehöre zu denen mit schlechtem Gedächtnis. Was ich nicht verstanden habe, kann ich mir nicht merken. Was ich verstanden habe, muss ich mir nicht merken - das ist für mich irgendwie selbstverständlich und zur Not kann ich es mir wieder herleiten.
Beneidet habe ich Leute mit gutem Gedächtnis durchaus, musste aber hin und wieder feststellen, dass ihnen manchmal das gute Gedächtnis bei ProblemLösungen nicht geholfen hat, weil sie gelegentlich hilflos waren, das Gelernte in die Praxis umzusetzen.
Selber [mit-]denken war für mich immer sehr wichtig. Auch, keine Scheu davor zu haben, das Rad (oder nur ein kleines, unbedeutendes Rädchen) mal neu zu erfinden, hat mir geholfen. Gelesenes zu hinterfragen und nicht einfach nur "abzunicken" ist auch nicht verkehrt.
Wenn man über eine fertige Lösung stolpert, auch mal überlegen, wie hätte ich das (Teil-)Problem angepackt/gelöst und dann mal vergleichen, welche Vor- und Nachteile sich da gegenüberstehen.
Logisch denken sollte man können und man muss erkennen und sich eingestehen, wenn man in zu grossen/groben Schritten (zu sprunghaft) denkt.
ComputerProgramme erfordern es, dass man die Anweisungen fein säuberlich Schrittchen für Schrittchen durchdenkt/aufbereitet.
Programme bzw. ProgrammStückchen testen. Verhält sich der verwendete Befehl oder die Funktion wirklich so, wie ich glaube, die Beschreibung verstanden zu haben?
Bei SPS-Programmen die zyklische Bearbeitung akzeptieren, verstehen und verinnerlichen. Verstehen, dass das gesamte zyklische Programm in einer "EndlosSchleife" vom BetriebsSystem aufgerufen, aber nicht als Schleife sichtbar wird.
Verstehen, dass die Aufteilung in verschiedene Tasks (GrundProgramm, Alarme/ZeitAlarme/WeckAlarme und wie sie noch so genannt werden) manchmal nötig und/oder hilfreich ist, aber oft zu weiteren "Problemchen" führt, spätestens wenn sie Einfluss auf die DatenKonsistenz oder die effektive ZyklusZeit hat.
Verstehen, dass viele Funktionalitäten (z.B. Datei öffnen, lesen/schreiben, schliessen oder "Streams", also DatenAustausch mit anderen Geräten) i.A. mehrere bis viele Zyklen benötigen, bis sie fertig und somit auswertbar oder wieder benutzbar sind.
Den Umgang mit Schrittketten verstehen. Sie dienen dazu, im Wesentlichen WarteZeiten auf Reaktionen zu "verbraten" und gelegentlich zur nächsten TeilAufgabe einer Aufgabe weiterzuschalten. Nutzlos Wartezeiten "verbraten" tun sie aber nicht, sie erlauben der CPU, sich während dieser Wartezeiten mit anderen Aufgaben zu beschäftigen.
Das Thema FlankenErkennung finde ich so wichtig, dass man sie m.E. zunächst "zu Fuss" programmieren sollte, bis man sie wirklich verstanden hat.
Oft hat man es mit FlankenErkennungen zu tun, die man nicht unbedingt als solche wahrnimmt, z.B. bei Timern, Zählern und auch anderen Bausteinen, die flankengetriggert reagieren.
Die korrekte Verarbeitung von sog. "A/B-Signalen" liegt mir auch sehr am Herzen. Es ist so simpel und trotzdem findet man erschreckend oft Beispiele (sogar in "guten" Büchern und Lehrgängen) dafür, wie man es keinesfalls machen sollte, wenn man sich nicht unnötige (weil leicht vermeidbare) Probleme einfangen will.
Das Rätsel der HexadezimalDarstellung von Zahlen. Wird überwiegend in der Dokumentation von seriellen Schnittstellen verwendet und führt immer wieder zu der Frage, "wie wandele ich denn Format x in hexadezimal bzw. umgekehrt?". Meistens lautet die Antwort "[am besten] gar nicht!". Erst, wenn es darum geht, eine in ASCII vorliegende oder zu erzeugende Zeichenfolge zu interpretieren oder bilden, wird es etwas aufwändiger.
Der eigentlich triviale Hinweis, dass die IF-Selektion nicht grundsätzlich überflüssig ist, oft aber doch ... und dann produziert sie Unübersichtlichkeit allein durch die überflüssige Menge an zu schreibendem Code. Z.B.:
Code:
IF MotorAn = TRUE THEN
MotorAktiv := TRUE ;
ELSE
MotorAktiv := FALSE ;
END_IF ;
Wie überflüssig dieser Aufwand ist, sieht man gut, wenn man die einfache Variante als Einzeiler gegenüberstellt:
Warum die beiden Alternativen auseinanderpfriemeln, um sie dann sofort wieder zusammenzuführen?
Übrigens sind die Vergleiche '= TRUE' oder '<> FALSE' oder 'NOT (...) = FALSE' immer überflüssig.
Sich an die Verwendung von Arrays heranwagen!
Zunächst bzw. bevorzugt erstmal auf 1-dimensionale Arrays beschränken.
Sucht man nach einem Array, das unterschiedliche DatenTypen enthält, besteht die Lösung nicht darin, eine oder mehrere Dimensionen hinzuzufügen!
Man verwendet dann ein 'Array Of Struct' und erhält damit eine (quasi "Excel"-)Tabelle.
Der Index des Array entspricht der ZeilenNr und alle Zeilen haben denselben, allerdings einen zusammengebastelten, "benutzerdefinierten" DatenTyp, in dem man für jede Spalte den jeweils benötigten DatenTyp festgelegt hat.
Benötigt man eine 2. oder auch 3. Dimension, um z.B. in den Daten das Abbild eines Regals mit seinen in Zeilen und Spalten angeordneten Fächern und dann noch mehrere Reihen solcher RegalWände zu schaffen, dann bleibt die Angelegenheit nachvollziehbar und durchschaubar.
Aber Vorsicht! Wenn man plötzlich feststellt, dass man zu wenig Platz im Array eingeplant hat, lässt man sich allzu leicht dazu verleiten, auf die Schnelle einfach eine weitere Dimension hinzuzufügen. Man sollte sich dann sehr gut überlegen, ob diese Massnahme wirklich den gewünschten Zweck erfüllt oder nur den benötigten SpeicherPlatz verschwendet oder "explodieren" lässt.
Weitere FingerÜbungen für Arrays bzw. Arrays Of Struct:
- Sortieren von Listen/Tabellen (für "Fortgeschrittene": Sortierung über einen Index, ohne die "eigentlichen" Daten(-Sätze) im Speicher umzuräumen; Sortierung nach verschiedenen Kriterien; mehrstufiges Sortieren).
- FIFOs und LIFOs.
Hierfür findet man meistens die verschiedensten vorgefertigten Lösungen. Aber das SichBeschäftigen mit eigenen Ansätzen und kleinen Experimenten kann nicht schaden.
Selbst, wenn die gesammelten Erfahrungen "nur" dazu dienen, aus den verschiedenen vorgefertigten Lösungen die geeigneteste herauszupicken.
Nicht zuletzt, wenn es um Arrays mit sehr vielen Elementen geht und die ZyklusZeit akut bedroht ist, kann eine massgeschneiderte (selbst realisierte) Lösung
schon mal in Betracht gezogen werden!
DANKE!
