gleicher Befehl mehrmals mit verschiedenen Variablen

Zuviel Werbung?
-> Hier kostenlos registrieren
Danke, StructuredTrash.

Mit ein wenig nachschlagen, habe ich's verstanden.

Dein Beitrag hat mir gezeigt, dass meine Idee nur sehr bedingt etwas bringt, weil:
- Brems den Controller aus.
- Verlagert nur die Schreibarbeit.
- Die Taster (Variablen) können keine eindeutigen Namen mehr haben.

Solche Beiträge (von allen Beteiligten), sind der Grund, warum ich immer wieder gerne in dieses Forum komme.

Viele grosse Erfindungen, haben mit einer Schnaps-Idee begonnen.
Manchmal wird was daraus und manchmal nicht...
 
@StructeredTrash & @Thomas_v2.1
Wir haben also den Schuldigen gefunden: Intel!
Genau, das ist der Kampf zwischen den Praktikanten und den alten Hasen, der bereits in einem anderen Thread länglich aber amüsant abgehandelt wurde!
Die KriegsGeneration, die kein einziges Bit verschwenden will - verständlich bei einem Preis von ca. 15.000,00 DM für einen 8KB Kernspeicher (Stand 1976) - und die FlatRateGeneration, für die die kleinste adressierbare Einheit 1 Cluster ist - aber das stimmt in dieser schnelllebigen Zeit bestimmt auch schon längst nicht mehr.
Dass Intel es dann auch noch gewagt hat, HiByte und LoByte zu vertauschen - das konnte einfach nicht gut gehen.
Aber viel älter und mindestens genauso schlimm ist natürlich das Phänomen, dass die Bytes von links nach rechts durchnummeriert werden (kann mir noch jemand folgen?) und die Bits von rechts nach links - das hat schon die alten Hasen total verwirrt, als sie noch die Praktikanten waren (aber nicht trotzdem, sondern genau deswegen keine VerbesserungsVorschläge äußern durften).
Verschiedene Begriffe für dieselbe Sache benutzen? Dazu wird man erzogen, Stichwort "WiederholungsFehler" beim AufsatzSchreiben. Das führt lediglich dazu, dass man plötzlich eine Anleitung versteht, sobald man alle Ecken und Winkel und Nebenwirkungen mühsam ausgetestet hat.
Aber denselben Begriff (hier BOOL) für verschiedene Sachverhalte zu verwenden, das ist bösartig! George Boole hätte sich einen solchen Missbrauch seines Namens verbeten - hoffe ich. Wie soll man denn Logik mit Unlogik verknüpfen - oder gibt es schon den PERHAPS- bzw. MAYBE-Operator (für die Integration der Stochastik - nein ich will damit nicht behaupten, Stochastik sei Unlogik) und ich habe auch diese Neuerung verschlafen?
Dennoch müssen wir die Hoffnung also nicht aufgeben, die Aufgabe lösen zu können, aber egro wird es zur Verzweiflung treiben - fürchte ich.
Danke, dass Ihr so geduldig mit uns seid! Gruss, Heinileini
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@egro
Hurra, es hat Dich doch nicht zur Verzweiflung gebracht!
Sei froh, zu denen zu gehören, die überhaupt Ideen haben! Die Richtigkeit und Tragweite so mancher vermeintlicher SchnapsIdee wurde erst Generationen später erkannt und bestätigt! Deine Idee "es muss doch eine einfachere Lösung geben" gehört zwar nicht in diese Kategorie, sie ist aber zeitlos gut und immer aktuell.
Halte diese Idee wach und bleib ihr treu.
Ich hatte die Hoffnung, Dir den Rückzug ersparen zu können. Deshalb habe mich bisher auch nicht getraut, Dir einen KritikPunkt um die Ohren zu hauen, den ich jetzt in aller Pingeligkeit nachholen möchte.
Meine Kritik betrifft überhaupt nicht Deine Idee, sondern nur Deine Formulierung der Aufgabe.
"wenn a_1 oder (OR) b_1 TRUE = c_1 TRUE". Auf den ersten Blick glaubt man zu verstehen, was gemeint ist. Auf den zweiten Blick beginnt man, daran zu zweifeln. Und auf den dritten Blick denkt man "so ein krauses Zeug". Ein Bisschen IF-Abfrage (ohne THEN!) , vermischt mit ein Bisschen Wertzuweisung (oder einem Vergleich?), gewürzt mit einigen weiss-nicht-was.
Das sieht zwar aus wie eine ProgrammierSprache, lässt sich aber auch mit dem Schlagwort "FehlerToleranz" nicht entschuldigen.
Man sagt "umgangssprachlich" z.B. "wenn a oder b größer als x ist, dann ..." und meint "wenn a größer als x oder b größer als x ist, dann ...".
Und bei Wertzuweisungen steht die Variable, die den ausgerechneten Wert aufnehmen soll, immer links vom "=".
Bei Gleichungen sind zwar immer beide Seiten des "="-Zeichens gleichbedeutend (daher der Name "Gleichung" ;o).
Aber, was in einem Programm wie eine Gleichung aussieht, z.B. cquadrat = aquadrat + bquadrat, kann z.B. auch so aussehen: a = a + 1, weil es in Wirklichkeit eine Wertzuweisung ist.
Programmierer sind da (fast) genauso pingelig wie die Computer. Ich möchte einfach nicht, dass Deine Anfragen im Forum Dich aufgrund solcher oder ähnlicher Fehlgriffe von vorn herein als GesprächsPartner disqualifizieren.
In diesem Sinne: weiterhin Mut zu fragen und zu hinterfragen!!!
Gruss, Heinileini
 
@Heinileini
Nein, Intel ist hier sicher nicht der Schuldige. Ich komme aus der Beckhoff-Welt, wo von CoDeSys nur Entwicklungsumgebung und Compiler genutzt werden, während das Laufzeitsystem eine Beckhoff-Eigenentwicklung ist. Beckhoff setzt dabei konsequent auf Windows und damit weitgehend auch auf Intel-CPUs. Diese Kombination hat durchaus ihre Tücken, aber unterm Strich profitiert man von der hohen Entwicklungsgeschwindigkeit im PC-Bereich.

@egro
Die Forderung, dass die Taster individuelle Namen haben sollen, hatte ich unter den Tisch fallen lassen. Ich habe für solche Anwendungen Structs und genauso grosse Arrays deklariert und sie mit "AT %M" auf die selbe Speicheradresse gelegt. Mal so als kleiner Gedankenanstoss:
Code:
TYPE strZimmer :
STRUCT
   HW_Taster:BOOL; (* Byte 0 *)
   Visu_Taster:BOOL; (* Byte 1 *)
   Verknuepfung:BOOL; (* Byte 2 *)
   Dummy:ARRAY[3..127] OF BYTE; (* Byte 3..127 für Erweiterungen *) 
END_STRUCT
END_TYPE

VAR_GLOBAL
   Wohnzimmer AT %MB0:strZimmer;
   Schlafzimmer AT %MB128:strZimmer;
   Zimmer AT %MB0:ARRAY[1..2] OF strZimmer;
END_VAR

(* In den beiden folgenden Zeilen wird auf die selben Daten zugegriffen *)
Schlafzimmer.Verknuepfung:=Schlafzimmer.HW_Taster OR Schlafzimmer.Visu_Taster;
Zimmer[2].Verknuepfung:=Zimmer[2].HW_Taster OR Zimmer[2].Visu_Taster;
Wenn Du alles Weitere was noch dazugehört wie die Stromstoss-FBs und die Lampenausgänge auch in dem Struct unterbringst, kommst Du vielleicht in den Bereich, wo sich der Aufwand lohnt.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Einer der besten CoDeSys-Tipps, die ich bislang hier gelesen habe. Aber ich habe noch einen besseren:
Den Wago 750-881 bei Ebay verticken, stattdessen einen CoDeSys 3-fähigen kaufen. Dann beliebige FBs für die Zimmer schreiben, die alle das Interface "intf_Es_werde_Licht" haben. Beim Programmstart die FBs
mit Hilfe ihres Interfaces in einem Interface-Array registrieren und schon kann die fröhliche Schleifenbearbeitung losgehen.
So, und jetzt im Ernst: In der Gebäudeautomatisierung, wo vieles zentral gesteuert wird, sehe ich tatsächlich noch mehr Potenzial für die OOP als im Maschinenbau. CoDeSys 3 wäre durchaus eine Überlegung wert.
 
@StructeredTrash
Ich habe auch nie Konstrukteure gefressen ... will sagen, das mit Intel habe ich doch nicht sooo ernst gemeint. Intel kann schliesslich nix dafür, dass der 8086 das Rennen gegen den damals technisch überlegenen Motorola 68000 gemacht hat. Da haben IBM ("Immer Besser Manuell") und Bill Gates ("In a world without fences, who needs Gates?") kräftig mitgemauschelt.
Ach, Beckhoff! Dies- und jenseits des Konrad-Zuse-Wegs, da bin ich doch schon fast so oft vorbei gedüst, wie die A2 zwischen GT und Kreuz BI dicht war, 13km "as the crow flies" von meinem ZuHause entfernt. Ich hatte noch nicht erwähnt, dass ich ALGOL60 auf einer Zuse25 mit riesengroßem (Abmessungen, nicht etwa SpeicherKapazität!) TrommelSpeicher lernen durfte ... jetzt komme ich schon wieder von Höcksken auf Stöcksken.
Das egro-Projekt kommt ja jetzt richtig in Fahrt! Bons' Beitrag "Instanz FB mehrmals aufrufen mit verschiedenen DB-Daten" und Dein "Structs und genauso grosse Arrays deklariert und sie mit "AT %M" auf die selbe Speicheradresse gelegt" scheint mir so ziemlich das zu sein, was mir vorschwebte und ich mit leider unqualifzierten Formulierungen umschrieben habe ("... für die Verwendung in CFC einen FB in AWL zu kreieren. ... im CFC den FB n-mal aufrufen ..." bzw. ""DoppelDefinition" desselben SpeicherBereichs, z.B. mal als Wort, mal als BitFeld oder EinzelBits (bzw. eine entsprechende DatenStruktur)").
@egro
Bleib dran!
Gruss, Heinileini
 
Einer der besten CoDeSys-Tipps, die ich bislang hier gelesen habe. Aber ich habe noch einen besseren:
Den Wago 750-881 bei Ebay verticken, stattdessen einen CoDeSys 3-fähigen kaufen. Dann beliebige FBs für die Zimmer schreiben, die alle das Interface "intf_Es_werde_Licht" haben. Beim Programmstart die FBs
mit Hilfe ihres Interfaces in einem Interface-Array registrieren und schon kann die fröhliche Schleifenbearbeitung losgehen.
So, und jetzt im Ernst: In der Gebäudeautomatisierung, wo vieles zentral gesteuert wird, sehe ich tatsächlich noch mehr Potenzial für die OOP als im Maschinenbau. CoDeSys 3 wäre durchaus eine Überlegung wert.

Das lässt sich aber auch klassisch programmieren, z.B. mit einer Befehlsliste in der alle Geräte die einen Befehl abgeben ihr Signal eintragen (Taster xy, Zeitschaltuhr, Wetterzustand, etc.) und die Befehlsemfänger nur noch in diese Liste hineinschauen ob dort ein Befehl für sie ansteht und diesen dann ausführen.

Habe ich hier schonmal erwähnt:
https://www.sps-forum.de/simatic/54901-s7-1200-perfekte-rollosteuerung-2.html#post402155
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das lässt sich aber auch klassisch programmieren, z.B. mit einer Befehlsliste in der alle Geräte die einen Befehl abgeben ihr Signal eintragen (Taster xy, Zeitschaltuhr, Wetterzustand, etc.) und die Befehlsemfänger nur noch in diese Liste hineinschauen ob dort ein Befehl für sie ansteht und diesen dann ausführen.

Habe ich hier schonmal erwähnt:
https://www.sps-forum.de/simatic/54901-s7-1200-perfekte-rollosteuerung-2.html#post402155
Gute Idee! Man sollte für die Gebäudeautomation wohl öfter mal über den zyklischen Tellerrand schauen. Aber dafür habe ich mit diesem Bereich viel zu wenig am Hut.
 
Vielen Dank für eure Tipps...

Ich bin momentan mit anderen Projekten beschäftigt.
Sobald ich wieder Zeit habe, befasse ich mich wieder mit dem Problem.
 
Das lässt sich aber auch klassisch programmieren, z.B. mit einer Befehlsliste in der alle Geräte die einen Befehl abgeben ihr Signal eintragen (Taster xy, Zeitschaltuhr, Wetterzustand, etc.) und die Befehlsemfänger nur noch in diese Liste hineinschauen ob dort ein Befehl für sie ansteht und diesen dann ausführen.

Habe ich hier schonmal erwähnt:
https://www.sps-forum.de/simatic/54901-s7-1200-perfekte-rollosteuerung-2.html#post402155

Du wechselst damit sozusagen von der klassischen zyklischen Bearbeitung einer SPS zu einem Eventhandling.
Bei simplen Aufgaben ist dies tatsächlich oft der einfachere Weg.
Je komplexer die Anforderungen sind, umso schwieriger wird aber das Handling. Ein Thema ist z.B. die Priorisierung oder der Neustart.

Gruß
Blockmove
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin Blockmove!
Mir ist schon klar, was mit der AuftragsListe gemeint ist. Ich fürchte nur, dass egro sich langsam in diese Richtung "entwickeln" muss und z.Z. den dritten oder vierten Schritt vor dem ersten gehen würde, wenn er jetzt schon diesen Weg einschlägt. Rom wurde auch nicht an einem Tag von der Wölfin gesäugt ;o)
Wenn ich egro richtig verstanden habe, ist er dabei - etwas übertrieben formuliert - den Schritt vom Stromlaufplan zum Kontaktplan zu machen, also von der Hardware zur Software. Er muss zunächst mal das Gefühl haben, sicher in der neuen Umgebung klar zu kommen. Zu schnelle Fortschritte wären "auf-und-davon-Schritte", die ihm den Boden unter den Füßen wegziehen - könnte ich mir vorstellen. Ich bin sicher, er hat genügend Ideen (Phantasie), Lösungswege zu finden, wenn er erstmal an einfacheren Beispielen die SoftwareMöglichkeiten kennen- und anzuwenden gelernt hat.
Wenn ich mich im Forum so umsehe, mit was für "Problemen" ihr euch herumschlagt, dann bin ich froh, dass mein Einstieg mit S5 erfolgt ist. Man hatte einen überschaubaren Befehlssatz in einer überschaubaren - eher zu bescheidenen - Umgebung (128 EingansBytes, 128 AusgangsBytes, 256 MerkerBytes, 256 DatenBausteine mit jeweils 256 ohne Tricks adressierbaren DatenWorten, chronisch zu wenige Timer, fast überflüssige Zähler und InterruptSperren, die immer dann wirkungslos waren, wenn man sie am meisten gebraucht hätte) und konnte sofort losprogrammieren, ohne rätseln zu müssen, WIE man die Befehle schreiben muss, damit der Compiler - oder was auch immer - endlich versteht, was man eigentlich tun möchte.
Dieses "wie-muss-ich-denn-jetzt-den-Befehl-formulieren-Phänomen" habe ich erst viel später im Umgang mit VBA unter Excel kennengelernt. Das war verdammt nervend, insbesondere, als die sehr gut verständliche Hilfe zu den Befehlen plötzlich durch FachChinesisch ersetzt wurde.
Bereits unter S5 habe ich mir (vermutlich vergleichbare) AuftragsListen einfallen lassen, wenn es darum ging, diverse Aktivitäten jeweils durch einen "Engpass" zu schleusen, z.B. für WerkzeugVerwaltung, Werkstück- bzw. PalettenVerwaltung, TelegrammVerwaltung, sogar, um den DatenAustausch zwischen PLC und CNC abzuwickeln, weil die Anwendung der Siemens FB61 & FB62 ab der Sinumerik 850M immer wieder zu "Verstopfungen" der Schnittstelle führte.
Den Unterschied zwischen der zyklischen PLC-Programmierung und der nicht-zyklischen Programmierung - welcher Art auch immer - möchte ich nicht so hoch hängen.
Zu oft habe ich von Kollegen gehört "das kann man in einer PLC nicht programmieren, das ist doch keine Hochsprache" oder "das ist eine Hochsprache, da kann man nicht zyklisch programmieren". Die Denkweisen sind zwar etwas unterschiedlich und insbesondere das Umdenken fällt vielen schwer, aber ätschibätschi, man kann (fast immer)!
Genug philosophiert!
Ein schönes RestWochenende wünscht Heinileini
 
Zurück
Oben