Die Frage ist doch, ob es so sinnvoll ist Code von einem "ProgrammZauberer" dem Kunden unterzujubeln.
Generell: nein.
Das technisch mögliche ausreizen ist ja schön und recht aber ob man da dem Endkunden einen Gefallen mit macht.....
Manchmal kann es aber sogar vom Kunden gewünscht sein, der PLC etwas abzuverlangen, für das sie eigentlich nicht geschaffen wurde.
Dabei denke ich aber an Erfahrungen, die ich mit S5 gesammelt habe und ausdrücklich nicht an die LOGO!.
Nicht alles, was man in einer PLC programmiert, muss für den Kunden oder seinen Reparateur leicht verständlich sein.
Nutzt man z.B. Bausteine aus Biblioteken, so hat man es nicht selten mit Bausteinen zu tun, in die man nicht hineinsehen kann, bei denen man sich aber überwinden kann, blind auf ihr korrektes Funktionieren zu vertrauen.
Warum soll das bei selbstgestrickten Bausteinen nicht auch möglich sein? Ist es zuviel verlangt, einen solchen Baustein so gut zu durchdenken und so gründlich zu testen, dass man sich auf sein einwandfreies Funktionieren verlassen kann?
Die Lesbarkeit ist grundsätzlich ein wesentliches Kriterium, sich für den einen oder anderen LösungsWeg zu entscheiden, kann aber nicht immer das wichtigste zu berücksichtigende Kriterium sein. Gelegentlich können andere Kriterien ausnahmsweise den Vorrang haben.
... k.A. warum Du unbedingt 3 Eingänge auf einen Muxx bringen musstest?! ...
Das musste ich nicht ungedingt. Es hat sich einfach so ergeben.
Die Grundidee war ja, die Zählerei mit einem VA zu erledigen. Das Problem bei diesem LösungsWeg ist, dass schon bei 3 EingangsBits das Maximum erreicht ist und die AufgabenStellung in diesem Thread stolze 20 EingangsBits verzeichnet.
Die zweite Idee war, bei diesen VAn die 2 ErgebnisBits nicht als 2 separate boolesche Ergebnisse zu interpretieren, sondern als 1 vorzeichenlose 2-Bit Ganzzahl, die dann direkt und ganz konventionell addiert werden kann.
Die Nutzung des AnalogMuxes war naheliegend, um die 2 ErgebnisBits in eine Zahl umzusetzen.
Hätte ich mich von der "fixen" Idee gelöst, VA zu "missbrauchen", dann wäre die Einführung der AnalogMuxe in den LösungsWeg natürlich der optimale ZeitPunkt gewesen, endlich über einen Verzicht auf die VA zu nachzudenken, da der VA ja lediglich die 3 EingangsBits zu 2 Bits einer GanzZahl "komprimiert".
PS:
Ich bin nicht der Meinung, dass die LOGO! für nichts zu gebrauchen ist. Ich bin aber der Meinung, dass die bei der LOGO! erforderliche Denkweise so anders ist als bei den "normalen" PLCs, dass sich die LOGO! nicht als EinstiegsModell für das Erlernen der PLC-Programmierung eignet.
Vielleicht wird sich bei den "normalen" PLCs in der Zukunft etwas tun und sie passen sich der LOGO!-Denkweise an?
Ich glaube kaum, denn die "MengenGerüste", die die verschiedenen AufgabenStellungen mit sich bringen, sind zu breit gefächert.
