# gleicher Befehl mehrmals mit verschiedenen Variablen



## egro (7 Juni 2017)

Was muss ich machen um einen Befehl mit verschiedenen Variablen auszuführen?
Zur Erklärung, Folgende Situation:

Ich habe drei Variablen-Listen.
- a_Variablen (a_1, a_2, a_3, usw.)
- b_Variablen (b_1, b_2, b_3, usw.)
- c_Variablen (c_1, c_2, c_3, usw.)

Jetzt möchte ich immer 
wenn a_1 oder (OR) b_1 TRUE = c_1 TRUE
wenn a_2 oder (OR) b_2 TRUE = c_2 TRUE
wenn a_3 oder (OR) b_3 TRUE = c_3 TRUE
usw.

Das heisst, der Anfang des Variablennamens ist immer gleich (a_ , b_ , c_ ,...), nur der zweite Teil variiert ( 1, 2, 3, ...).

Es gibt doch sicher eine Möglichkeit, dass ich nicht alles einzeln eingeben muss?

Ich hoffe, ihr versteht, was ich genau meine...


----------



## Januar (7 Juni 2017)

For-Schleife, wenn du deine Listen dynamisch referenzieren kannst.

For i=1 to Ende 
    if a_ or b then c:=True;
next;

Wenn deine Sprache es zulässt, kannst du deine Listen auch zu jeweils einem Datum zusammenfassen und dann eine Word-Operation durchführen._


----------



## shrimps (7 Juni 2017)

Hi,
ich habe bisher leider noch nichts davon gehört, das es dynamische Variablennamen bei SPS´en gibt.
Ich kenne das nur aus Hochsprachen ausserhalb SPS.
Wird wohl Handarbeit werden.
Ob es einen Vorteil darstellt, wenn du alles temporär in ein Array packst und dann in einer Schleife veroderst wage ich zu bezewifeln.
Sehe zwar technisch schick aus, aber für ne Handvoll Vars oversized...

HtH
Shrimps


----------



## egro (7 Juni 2017)

So wie ich das verstehe funktioniert eine FOR-Schleife aus zwei Gründen nicht.
1. Müsste die Schleife immer laufen. Das kann gem. Handbuch zu Laufzeitfehlern führen.
2. Sind die Zahlen (a_*1*)nur als Beispiel gedacht. In Wirklichkeit haben die Variablen richtige Namen (a_Taster_xy, b_Taster_xy, ...)

Aber Danke trotzdem...


----------



## shrimps (7 Juni 2017)

Naja,
da hast du mich wohl falsch verstanden:
Wenn ich die Variablen in ein Array überführe und zwar so, das sich eine mathematische Anordnung der gewünschten Zusammenhänge ergibt, dann kann ich schon eine effiziente For-Schleife etablieren.
Diese kostet auch nicht mehr Zeit als alle Befehle hintereinander auszuführen.
For i:=Anfang to Ende step Paerchen
 if variable_ or variable[i+1] etc then
    merken...
end_if
end_for

So ähnlich meine ich das, ggf. rausspringen wenn schon gewollt...

Ggf. bietet sich eine AT-Sicht als Array an ?_


----------



## mirasoft (7 Juni 2017)

Liegen die Variablen hintereinander im Speicher? Z.B. weil Sie auf aufeinanderfolgende Register gemappt sind? Wenn ja, könntest du mit Pointern arbeiten oder zusätzlich ein Array auf die selbe Adresse mappen. 

Am schönsten wäre es vermutlich, wenn du ein Struct mit den Variablen a, b und c erstellst und dies in ein Array von 1 bis x packst.


----------



## shrimps (7 Juni 2017)

Andere Ausdrucksweise aber die gleiche Sache...
Nun wird es langsam spannend über wieviele Variablen wir reden...



mirasoft schrieb:


> Liegen die Variablen hintereinander im Speicher? Z.B. weil Sie auf aufeinanderfolgende Register gemappt sind? Wenn ja, könntest du mit Pointern arbeiten oder zusätzlich ein Array auf die selbe Adresse mappen.
> 
> Am schönsten wäre es vermutlich, wenn du ein Struct mit den Variablen a, b und c erstellst und dies in ein Array von 1 bis x packst.



HtH
Shrimps


----------



## egro (7 Juni 2017)

Wir reden von ca. 100 in jeder Liste.
Also 3x100...

Vielleicht hat mir jemand ein Beispiel, da ich mich mit Arrays nicht wirklich auskenne.

Die Variablen sind in der Liste an gleicher Position.
Als Beispiel:
Also die Variable a_Taster_xy ist in der Liste a_Variablen, an der 54. Stelle.
Die Variable b_Taster_xy ist in der Liste b_Variablen auch an der 54. Stelle.


----------



## PN/DP (7 Juni 2017)

shrimps schrieb:


> Wenn ich die Variablen in ein Array überführe und zwar so, das sich eine mathematische Anordnung der gewünschten Zusammenhänge ergibt, dann kann ich schon eine effiziente For-Schleife etablieren.
> Diese kostet auch nicht mehr Zeit als alle Befehle hintereinander auszuführen.


Das ist nicht richtig. Es entsteht zwar kürzerer Programmcode, die Ausführungszeit wird aber deutlich länger (ich schätze mal: verdoppeln oder mehr).
Oder hast Du mal Benchmark-Meßwerte die Deine Aussage belegen?

Harald


----------



## M-Ott (8 Juni 2017)

Wenn es tatsächlich um verodern von zwei Eingängen geht, könntest Du vielleicht alle Taster A in einen zusammenhängenden Adressbereich kopieren, alle Taster B in einen anderen und dann wort- oder doppelwortweise verodern. Vielleicht sind sie ja sogar schon in einem zusammenhängenden Adressbereich.


----------



## egro (8 Juni 2017)

Vielen Dank an Alle, die versucht haben, mir zu helfen.

Ich dachte irgendwie, dass es einfacher gehen muss, als alles von Hand eingeben.

So wie es aussieht, gibt es Möglichkeiten, aber die sind, für mich als Anfänger, zu kompliziert.

Ich mache jetzt von Hand...:sad:


----------



## Bitmanipulator (8 Juni 2017)

Das kann man machen, muss man aber nicht. Wenn Du Arrays und Pointer verstanden hast, wird vieles einfacher, schneller zu realisieren, erweiterbarer und verständlicher sein.


----------



## Heinileini (29 Juni 2017)

Hi egro!

Nachlese zum Thema "alles von Hand eingeben":
Ich habe immer wieder Kollegen bestaunt, wie wörtlich sie manchmal "alles von Hand eingeben" nehmen.
Nein, ich bin nicht faul (sondern nur im EnergieSparModus ;o), habe aber einen chronischen Horror vor unnötigen Tippfehlern.
Deshalb nutze ich gerne bis übermäßig die ZwischenAblage zum Kopieren/Einfügen.
In Deinem Beispiel mit der fortlaufenden Durchnumerierung der VariablenNamen, würde ich nicht zögern, Excel für mich arbeiten zu lassen und das Ergebnis (den ProgrammCode) komplett via ZwischenAblage in den ProgrammEditor zu übernehmen. Nur ärgerlich, wenn sich der Editor gegen solche Maßnahmen sträubt, aber es gibt vielleicht ImportFunktionen, die das zulassen?

Nachlese zum Thema "FeldVariablen bzw. Arrays":
Durch Deine Vorgabe mit der fortlaufenden Numerierung der Variablen(-Namen) und die Trennung in separate Bereiche (a, b, c), war ich schon so sehr auf die Lösung mit 3 Arrays oder einem zweidimensionalen Array fixiert, dass ich eigentlich keinen anderen Lösungsweg mehr in Betracht gezogen hätte. Da hat sich jemand anscheinend schon bei der Vergabe der VariablenNamen die entsprechenden Gedanken gemacht! Warst Du das selbst (wenn ja: großes Lob!) oder hat man Dir das so fertig vorgesetzt? 
In der Praxis habe ich leider immer wieder erlebt, dass von der HardwareTruppe  Eingangs- bzw. AusgangsBelegungen so unsinnig festgelegt werden, dass die SoftwareTruppe aktiv werden muss. Entweder bei der HardwareTruppe RamboZambo machen oder so umständlich und aufwendig programmieren, dass man sich fortan über den auswuchernden Code und die aufgeblähte ZyklusZeit ärgern muss.

Nachlese zum Thema "was das Programm eigentlich machen soll":
Erst jetzt fällt mir auf, dass ich nicht verstanden habe, was das Programm tun soll!
Was meinst Du mit:  "wenn a_1 oder (OR) b_1 TRUE = c_1 TRUE" ???

a) if a1=True or b1=True then c1=True ' was soll im Else-Fall passieren? nichts? 
oder
b) c1 = a1 or b1 ' eine schlichte OderVerknüpfung mit anschliessender, bedingungsloser Wertzuweisung
oder
 c) ... ?

In S7 wäre 
a)  bitweise    bzw.   wortweise
.... O    #A1 .... .... L   #Awort
        .... O    #B1 ....                      .... L   #Bwort
        .... S    #C1 .... .... OW
                                                     .... .... .... .... .... L   #Cwort
                                                     .... .... .... .... .... OW
                                                     .... .... .... .... .... T   #Cwort

b)  bitweise    bzw.   wortweise
        .... O    #A1 .... .... L   #Awort
        .... O    #B1 .... .... L   #Bwort
        .... =    #C1 .... .... OW
                                                     .... .... .... .... .... T   #Cwort

Ich bin ratlos. In welcher ProgrammierSprache musst(est) Du denn die Aufgabe lösen und vor allem WELCHE Aufgabe?
Ja, es ist leider so und war früher noch extremer so: die ProgrammierSprache entscheidet nicht selten darüber, welche der alternativen LösungsMöglichkeiten das Rennen macht und welche schon in der Vorrunde ausscheidet. Manchmal ist man sogar gezwungen, alles eigentlich Selbstverständliche und Naheliegende zu vergessen und sich einen absurd anmutenden Lösungsweg einfallen zu lassen.

Gruss, Heinileini


----------



## PN/DP (30 Juni 2017)

Heinileini schrieb:


> In der Praxis habe ich leider immer wieder erlebt, dass von der HardwareTruppe  Eingangs- bzw. AusgangsBelegungen so unsinnig festgelegt werden, dass die SoftwareTruppe aktiv werden muss. Entweder bei der HardwareTruppe RamboZambo machen oder so umständlich und aufwendig programmieren, dass man sich fortan über den auswuchernden Code und die aufgeblähte ZyklusZeit ärgern muss.


 Oh, hängt bei Dir die Programmgröße und der Programmieraufwand davon ab, wie sinnig oder unsinnig E/As belegt sind? Na, dann viel Spass, wenn mal ein Hardware-Eingang oder -Ausgang kaputt geht und im laufenden Betrieb auf die schnelle auf einen anderen E/A umverdrahtet werden soll...

Das Programm sollte unabhängig davon funktionieren, welche Hardware-Adressen real benutzt werden. Die meisten "Abkürzungen" für "sinnige" E/A-Belegungen halte ich für unsaubere Programmierung.

Harald


----------



## egro (30 Juni 2017)

Hallo Heinileini

a oder b True = c True
a und b False = c False

Einfach zwei Variablen parallel, auf eine Dritte.

Es ist keine Aufgabe für einen Kurs oder so. Es ist nur für mich und noch folgende Projekte...

Ein Beispiel für mein Vorhaben könnte folgendes sein:
Du hast x-Hardware-Variablen (Liste "a", also digitale Eingänge in der Steuerungskonfiguration). Da du diese nicht in einer Visu bedienen kannst, hast du unzählige "virtuelle" Variablen (Liste "b".
Jetzt wäre es doch super, wenn du im PRG nur mit der Liste "c" arbeiten könntest. Für das PRG wäre es dann egal, ob der echte Taster gedrückt wird, oder der in der Visu.
Klar kann ich einfach im PRG beide Variablen einfügen, aber ich dacht mir, dass es ev. einfacher geht.

Kannst du meinen Gedankengängen folgen?


----------



## Heinileini (1 Juli 2017)

Allerdings, Harald!
Es ging nämlich darum, eine Handvoll BCD-Codier-Schalter (vornehm auch "ThumbWheels" genannt) einzulesen und an ebenso viele 7SegmentAnzeigen auszugeben. Wenn man dann erst Bit für Bit so umsortieren muss, dass die wortweise Weiterverarbeitung ermöglicht wurde und das Ergebnis dann wieder Bit für Bit in die allzu willkürliche AusgangsBelegung umgesetzt werden musste ... das nervt ungemein.
Schliesslich mussten wir damals sparen, koste es, was es wolle. D.h. die PLC wurde nach dem Preis ausgesucht und nicht nach den technischen Erfordernissen. Der Rotstift regierte bei der Hardware und niemand hat einen Gedanken darauf verschwendet, wie sich das auf die SoftwareKosten auswirkt. Das ging so weit, dass ich manch einen SiemensStandardFB umschreiben musste, um seine Funktionalität mit weniger und/oder kürzeren Befehlen (z.B. L KH0 in L KB0 ändern) zu realisieren. Am effektivsten war das NeuProgrammieren der FBs für die DUAL-GRAY- und GRAY-DUAL-Umwandlung. Jeweils 2 DIN-A-Seiten AWL-Ausdruck konnte ich auf ca. eine ViertelSeite zusammenstauchen und meine Version war 16-Bit-tauglich, während die Siemens-Version maximal 15 Bit wandeln konnte.
 Du hast natürlich Recht: das Umverdrahten und Umschreiben vor Ort bei einem defekten Ein- oder Ausgang ist "normalerweise" ein wichtiger GesichtsPunkt und darf nicht an den exotischen Vorlieben eines Programmiers scheitern.
Auch hier: sorry vielstmals, dass meine Darstellung sich auf (zu) wenige Aspekte beschränkt hat - sollte keine Vorlesung werden, sondern eigentlich nur daran erinnern, zuerst das Gehirn einzuschalten, die Scheuklappen abzulegen und einen Blick über den Tellerrand zu riskieren.
Gruss, Heinrich


----------



## Heinileini (1 Juli 2017)

Hallo egro!
Den ersten Teil habe ich jetzt verstanden: 2 Variablen mit ODER verknüpfen und das Ergebnis einer dritten Variablen zuweisen.
Also der Fall, den ich als b) bezeichnet hatte - siehe "neulich".
Und die ganze Prozedur wirderholt sich immer wieder für ganz viele Bits (zu diesem Aspekt - wortweise statt bitweise bzw. mit ProgrammSchleifen zu arbeiten - hattest Du ja schon etliche Reaktionen von anderen erhalten). 
Den zweiten Teil habe ich vielleicht auch verstanden, bin mir aber nicht sicher.
Du hast einerseits eine "real-existierende" Tastatur, die Du an den Eingängen abfragen kannst und andererseits z.B. einen TouchScreen mit genau den gleichen "Tasten", die Dir in der SoftWare als Merker oder DatenBits oder irgendwas vorliegen. Beide BedienOberflächen sollen wahlweise (oder gleichzeitig) aktiv sein, aber Deiner Software ist egal, woher die TastenSignale wirklich kommen. Du willst sie mit demselben Stückchen Programm abhandeln. Ist es so?
Ich stelle mir z.B. vor, dass Deine "VisuTaster" alle "Schliesser" darstellen, aber die "real-existierenden" nicht nur "Schliesser", sondern auch "Öffner" sein können.
Haben wir es evtl. mit einem solchen Problemchen zu tun? Öffner mit Schliesser zu verknüpfen erfordet ein wenig Überlegung. Öffner mit Öffner ist zwar einfach (UND-Verküpfung!), aber eben nicht ODER. Ob es sinnvoll ist, alle Bits mit ODER zu verknüpfen, hängt davon ab, ob alle Schliesser sind.
Gruss, Heinileini
PS: Ich nerve Dich nochmal mit der Frage nach der Sprache, in der Du programmierst.


----------



## egro (1 Juli 2017)

Hallo Heinileini

Da ich mit Easy und Logo angefangen habe, programmiere ich fast alles in CFC.
Ich habe mal Elektriker gelernt, zu Zeiten von Schützensteuerungen, darum "sehe" ich gerne, was und wie "es passiert".
Ich weiss, dass Profis fast nur in ST programmieren, aber mir ist CFC einfach sympathischer.

Zu meinem Vorhaben:
Zum Beispiel habe ich ein Bürogebäude. In dem gibt es diverse Taster für Licht und Storen, die alle auf DI-Karten verdrahtet sind.
Zusätzlich gibt es eine Visualisierung, auf der alle realen Taster auch bedient werden können. Im PRG musst du nun den realen Taster (a_Buero1) mit dem Visu-Taster (b_Buero1) mit einer OR-Verknüpfung an ein Stromstoss-FB anschliessen.
Wenn du das hundert mal machen musst, wäre es doch einfacher, wenn du immer eine Variable (c_Buero1) anhängen könntest.

Das ist jetzt nur ein Beispiel (wie oben). Ich komme öfters an Programmier-Schritte, bei denen ich x-mal dasselbe machen muss.
Darum meine Idee, dass man das eventuell vereinfachen könnte.


----------



## Heinileini (1 Juli 2017)

Hallo egro!
Ja, mittlerweile habe ich verstanden. Mein Bohren nach der ProgrammierSprache sollte helfen, ein gemeinsame Basis zu finden, auf der wir uns verständigen können. EASY, LOGO, CFC und ST sind mir leider kein Begriff. Habe zwar vor Jahrenden auch in S7 programmiert, habe aber nichts hier, wo ich etwas nachschlagen könnte. 
Dein Anliegen, Wiederholungen zu vermeiden, möchte ich gerne unterstützen, nicht zuletzt, weil dadurch die BedienOberflächen vereinheitlicht werden und das Testen der Software auf das Wesentliche beschränkt werden kann. Zusätzlich noch TippFehler aufspüren zu müssen, die sich leider immer wieder einschleichen können, ist BeschäftigungsTherapie, die ich gerne vermeiden möchte.
Das Thema "StromstossFB" ist in Deinem Zusammenhang jetzt auch neu - Taster drücken schaltet also abwechselnd ein und aus?
Erübrigt sich damit meine Sorge, dass wir ausser Schliessern auch Öffner berücksichtigen müssen?
Müssen wir mit prellenden Kontakten der "real-existierenden" rechnen?
Werde jetzt erstmal suchen, was ich zum Thema CFC finden kann. Bin dabei auf http://www.wago.com/wagoweb/documentation/759/ger_manu/333/m07590333_00000000_1de.pdf
gestossen (CoDeSys) - bin ich da auf dem richtigem Dampfer oder ist das schon haarscharf am Ziel vorbei?

Alldieweil versuche ich mal etwas S5-AnweisungsListen-artiges und hoffe, dass ich Dich damit nicht verwirre ...

A    DB#StromStoss
L    EW#RealEingänge00-15
L    MW#VisuEingänge00-15
OW
L    DW#Flanken00-15
KEW  ' EinerKomplement bilden
TAK  ' Akku 1 und 2 tauschen
T    DW#Flanken00-15
UW
L    DW#Status00-15
XOW  ' Exklusiv-ODER
T    DW#Status00-15
T    AW#RealAusgänge00-15
T    MW#VisuAusgänge00-15

Kannst Du das verstehen, in "Deine Welt" umsetzen und testen? Statt der 2 DW reichen zum Testen sicher auch 2 freie MW ...


----------



## egro (1 Juli 2017)

Mit den Unterlagen von Codesys bist du schon auf dem richtigen Dampfer. Mir ist auch erst jetzt aufgefallen, dass ich das nirgends erwähnt habe.
Ich programmiere WAGO-Controller mit Codesys 2.3.

CFC, ST (ST=Strukturierter Test, CFC müsste ich jetzt suchen gehen...) und andere sind Programmiersprachen im Codesys.
FB ist ein Funktionsblock.
FB_Stromstoss schaltet bei einem True, abwechselnd ein und aus. Aus einem Taster (wir reden mal nur von Schliessern), wird ein Schalter.

Mit deinen "S5-AnweisungsListen-artigen" Texten, verstehe ich nur Bahnhof...


----------



## Heinileini (2 Juli 2017)

Hallo egro!
Habe den halben Nachmittag an einer Antwort an Dich herumgetippt und dann auf antworten geklickt.

Alles futsch!
	

		
			
		

		
	



Weiss nicht, wo ich im SPS-Forum-Fenster auf zurück klicken soll. Klicken auf zurück im Browser dreht die Zeit um einige Schritte zu weit zurück und futsch bleibt futsch.
Was habe ich denn falsch gemacht? Ich weiss gar nicht, wann und wodurch ich mich angemeldet haben soll - für mich war nicht mal zu erkennen, dass ich anscheinend zeitweise nicht mehr angemeldet war.
Gruss, Heinileini


----------



## PN/DP (2 Juli 2017)

Heinileini schrieb:


> Alles futsch!


Das ist ein schon sehr altes Problem der Forumssoftware, an dem auch schon laaange gefixt wird. Momentaner Stand der Fehlerbeseitigungsversuche ist, daß nun auch noch willkürlich die Umlaute ausgetauscht werden, falls der Beitragstext wider Erwarten mal nicht verschwunden sein sollte. 
Workaround:


PN/DP schrieb:


> Wenn Du den Beitrag geschrieben hast dann nicht sofort auf [Antworten] gehen, sondern erst mal den gesamten Beitragstext markieren und "Kopieren". Dann auf [Erweitert] bzw. [Vorschau] klicken. Dann mußt Du Dich vermutlich anmelden. Danach falls noch Text da ist, den komplett markieren und löschen - dann "Einfügen" (Deinen ursprünglichen originalen Beitragstext) - nochmal auf [Vorschau] - und wenn die Vorschau OK ist dann auf [Antworten]



PS: es soll wohl auch helfen, wenn man beim ersten Anmelden vor dem Betrag schreiben die Option "angemeldet bleiben" (oder so ähnlich) aktiviert.

Harald


----------



## Heinileini (2 Juli 2017)

Hallo Harald!
Ja, das Phänomen mit den Umlauten habe ich direkt bei meinen ersten Gehversuchen im SPS-Forum erlitten und das führte dann zu meiner ersten Nachbearbeitung eines - allerdings erfolgreich - abgeschickten Beitrags. Zum Glück konnte ich den ver-kuddel-muddel-ten Zustand sofort sehen.
Ich bin ja grundsätzlich so skeptisch eingestellt, dass ich (sonst!) immer zuerst den Kram in einen anderen Editor kopiere und dann erst abschicke.
Das hatte ich mir heute gespart und ... Bauchlandung.
Gruss, Heinileini


----------



## Heinileini (3 Juli 2017)

Hallo egro!
Habe jetzt einen Teil meiner gestern verschollenen "Botschaft" rekonstruiert:
A    DB#StromStoss
L    EW#RealEingänge00-15
L    MW#VisuEingänge00-15
OW
L    DW#Flanken00-15
KEW  ' EinerKomplement bilden
TAK  ' Akku 1 und 2 tauschen
T    DW#Flanken00-15
UW
L    DW#Status00-15
XOW  ' Exklusiv-ODER
T    DW#Status00-15
T    AW#RealAusgänge00-15
T    MW#VisuAusgänge00-15
Zu den verwendeten Befehlen:
L    EW  :  lädt EingangsWort rechtsbündig nach Akku1, vorher wird der Inhalt von Akku1 nach Akku2 verschoben
L    MW  :  lädt MerkerWort rechtsbündig nach Akku1, vorher wird der Inhalt von Akku1 nach Akku2 verschoben
L    DW  :  lädt DatenWort rechtsbündig nach Akku1, vorher wird der Inhalt von Akku1 nach Akku2 verschoben
T    AW  :  transferiert die rechten 16 Bit des Akku1 ins AusgangsWort
T    MW  :  transferiert die rechten 16 Bit des Akku1 ins MerkerWort
T    DW  :  transferiert die rechten 16 Bit des Akku1 ins DatenWort
A    DB  :  öffnet (aktiviert) den im Operanden angegeben DatenBaustein - die nachfolgenden L DW und T DW sprechen DW in diesem DB an
UW       :  verknüpft die rechten 16 Bit von Akku1 und Akku2 per UND - Ergebnis steht in Akku1, Akku2 wird nicht verändert
OW       :  verknüpft die rechten 16 Bit von Akku1 und Akku2 per ODER - Ergebnis steht in Akku1, Akku2 wird nicht verändert
XOW      :  verknüpft die rechten 16 Bit von Akku1 und Akku2 per exklusiv-ODER - Ergebnis steht in Akku1, Akku2 wird nicht verändert
KEW      :  negiert die rechten 16 Bit von Akku1 - Ergebnis steht in Akku1, Akku2 wird nicht verändert
TAK      :  tauscht die Inhalte von Akku1 und Akku2
"rechtsbündig" bzw. "die rechten 16 Bit" habe ich oben geschrieben, weil man sich fragen könnte bzw. sollte "was passiert mit den anderen Bits von AkkuX, wenn er z.B. 32 Bit breit ist?".
Die höherwertigen Bits (falls vorhanden) werden übrigens durch LadeBefehle (L EW, L MW, L DW) gelöscht.
Für die Operanden der Befehle hatte ich eine symbolische Schreibweise gewählt, aus der Du hoffentlich ersehen kannst, WAS gemeint ist. 
Für das tatsächliche Programm müsstest Du die verwendeten EW-, MW-, DW-, DB-Nummern festgelegen bzw. die vorgegebenen übernehmen.
Wie Deine Schnittstelle zum VisuBereich aussieht, weiss ich nicht, da habe ich willkürklich die Merker genommen.
Für die "StromstossFunktion" muss der Zustand des vorherigen PLC-Zyklus verfügbar sein 1. der realen und "visu"-Tasten" und 2. der Lampen oder was auch immer gesteuert werden soll.
Für diese hatte ich 2 DW in einem DB vorgesehen. Hätten auch MW sein können - ganz nach Belieben.
Ich bitte, meine ausgeprägte CFC-(Continuous Function Chart)-Ignoranz zu entschuldigen - vielleicht können wir uns trotzdem weiterhin verständigen ...
Kannst Du etwas dazu sagen, inwieweit ProgrammSchleifen in CFC möglich bzw. praktikabel sind?
Hast Du schonmal einen FB für die Verwendung in CFC selbst gestrickt oder könntest Du Dich dahingehend schonmal schlau machen?
Momentan stelle ich mir vor, dass wir einen FB basteln, der in einer ProgrammSchleife wortweise Deine unzähligen Bits verwurstet.
In Hinblick auf die ZyklusZeit wäre das schon eine gute Lösung.
Wie klappt es denn mit der Visualisierung der vielen Bits, wenn wir im Programm nur noch mit Worten arbeiten?
Gruss, Heinileini
PS: Diese SPS-Forums-Funktionalität hat wieder alle "überflüssigen" Leerzeichen und Leerzeilen "wegoptimiert" - ich hoffe Du kannst den Krempel trotzdem lesen ;o)


----------



## egro (3 Juli 2017)

Eh... Nein, ich verstehe immer noch nur Bahnhof!!!
Ich bin definitiv kein "erfahrener Benutzer"!

Ich habe schon selber FB's "gestrikt". Teilweise sogar in ST, da manches einfach viel einfacher geht.
Trotzdem komme ich nicht von CFC weg.

Ich bin dir echt dankbar, weil du das scheinbar Unmögliche versuchst.
Leider habe ich das Gefühl, dass es unter Codesys nicht machbar ist.
Vielleicht kann ein erfahrener Codesys-User etwas mit deinem Code anfangen und mich vom Gegenteil überzeugen?

Ich bin leider dazu nicht im Stande...


----------



## Heinileini (4 Juli 2017)

Hallo egro!
Wirf die Flinte nicht ins Korn - sie könnte geladen sein! 
Ja, Du hast sicherlich Recht, dass wir nicht die idealen Partner sind. 
Nicht weil wir unerfahrene Benutzer sind, aber weil wir auf (zu?) unterschiedlichen Gebieten unsere Erfahrungen gesammelt haben.
Man kann nicht alles können oder wissen. aber wir haben es hier schlicht und einfach mit Logik zu tun und nicht mit Zauberei. 
Hast Du ein System, auf dem Du Deine Software testen bzw. simulieren kannst?
Versuch doch bitte mal, mir zu erklären, wie in Deinem CFC ...
- die "real-existierenden" Taster erscheinen bzw. bezeichnet werden - sind es Eingänge? Merker? Wenn nein, was dann?
- die anzusteuernden Lampen erscheinen bzw. bezeichnet werden - sind es Ausgänge? Merker? Wenn nein, was dann?
- die "Visu-Taster" erscheinen bzw. bezeichnet werden - sind es Eingänge? Merker? Wenn nein, was dann?
- die "Visu-Lampen" erscheinen bzw. bezeichnet werden - sind es Ausgänge? Merker? Wenn nein, was dann?
Sagen Dir die Begriffe Eingang, Ausgang, Merker, DatenBaustein, Bit, Byte, Wort, Doppelwort, Akku etwas?
Die bitweisen Verknüpfungen mittels UND (AND) bzw. ODER (OR) kennst Du offensichtlich. Exklusiv-ODER (XOR) kennst Du auch?
Kannst Du Dir unter einer wortweisen Verknüpfung mittels UND, ODER bzw. exklusiv-ODER etwas vorstellen?
Nein, dies ist keine Prüfung. Du hast nur bisher konsequent vermieden zu sagen, an welcher Stelle Du Probleme hast, meinen Fragen/Vorschlägen zu folgen.
Wo hakt es aus? Das muss ich einfach besser einschätzen können, damit wir uns verständigen können.
Gruss, Heinileini


----------



## egro (4 Juli 2017)

In Codesys kannst du mehrere Variablen-Listen erstellen (Roter Kreis im Bild).
Es ist egal, ob du die dann als Eingänge, oder Ausgänge verwendest.
Du kannst die Variable in der Visu einem Taster zuweisen, oder in der Steuerungskonfiguration einer DI- oder DO-Karte.
Natürlich nicht beides, da sie sich selber überschreiben würden!!!
Für einen virtuellen Ausgang, machst du mit der Variable (z.B.) einen Farbwechsel.
Wenn du die Variabel nur im PRG verwendest und nirgends zuweist, ist es eigentlich wie ein Merker.



Mir geht es im Moment, um Variablen vom Typ BOOL.
Mit Bit, Byte und Word arbeite ich teilweise auch.
Doppelword kenne ich vom hören sagen...
Akku gibt es wohl in Codesys nicht... Habs noch nie angetroffen.

Die ganzen Verknüfungen (OR,XOR,AND,NAND, usw.) gibt's in Codesys natürlich auch.

Bei den Datenbausteinen bin ich nicht sicher. Sind das im Codesys die FB's (Funktionsblöcke / Bausteine)
Schau mal in deinem Codesys-PDF, ab Seite 363.

Einen Test-Controller habe ich (WAGO 750-881).

Grundsätzlich verstehe ich deine Auflistung nicht...
A    DB#StromStoss
 L    EW#RealEingänge00-15
 L    MW#VisuEingänge00-15
 OW
 L    DW#Flanken00-15
 KEW  ' EinerKomplement bilden
 TAK  ' Akku 1 und 2 tauschen
 T    DW#Flanken00-15
 UW
 L    DW#Status00-15
 XOW  ' Exklusiv-ODER
 T    DW#Status00-15
 T    AW#RealAusgänge00-15
 T    MW#VisuAusgänge00-15

Das ist eine Sprache, die ich nicht kenne.
ST (=strukturierter Text) sieht mehr so aus:
IF blablabla = True Then blablabla = False
Elsif blablabla...


----------



## Heinileini (5 Juli 2017)

Hallo egro!
Danke für Deine Infos!
Ich bastele gerade daran, das AWL-ProgrammStückchen in Excel zu simulieren ... und das funktioniert noch nicht so toll.
Bin schon am grübeln, ob meine AWL einen (oder mehrere) GedankenFehler enthält.
Wäre Excel eine Basis, auf der wir uns verständigen können?
Hast Du schonmal mit hp-TaschenRechnern mit UPN (umgekehrte polnische Notation) gearbeitet?
Ich weiss gar nicht, ob es so etwas überhaupt noch gibt. Sie haben einen "Stack" mit 4 Registern und das kommt einer CPU mit 4 (oder 2) Akkus sehr nahe. 
Es ist immer so schön, wenn man etwas erklären will und dabei auf Vertrautes zurückgreifen kann.
Deine Scheu, in AWL einzusteigen, kann ich sehr gut nachempfinden.
Mir geht es genauso mit CFC, zumal ich nur die PDF-Datei habe und sonst gar nix - kann nix nachvollziehen, ausprobieren, testen.
Gruss, Heinileini


----------



## egro (5 Juli 2017)

AWL ist kenne ich nicht wirklich.
Ich hatte das mal kurz in einem Kurs.
Ich fand das nicht praktisch... für meine Verwendungen.
Klar, auf einer SPS wird immer eine "Liste" abgearbeitet, aber wie schon erwähnt, ist mir das zu unübersichtlich.

Man könnte aber einen FB in AWL programmieren und dann im CFC einfügen.

Mein Problem ist, dass ich von den ganzen Abkürzungen keine Ahnung habe.
Ich habe aber in der Codesys-Doku gesehen, dass es ähnliche sind, wie in CFC.

Kannst du mal ein ganz einfaches Beispiel machen, mit Erklärung? Am Besten so, dass ich es dann auf dem Controller simulieren kann.


----------



## Heinileini (6 Juli 2017)

Hallo egro!
Beim FB-Stromstoss sehe ich die in Deinem Beispiel (noch?) unbeschalteten Eingänge
- xZenAUS
- xZenEIN
- bResetModus
Benötigen wir die evtl. noch? Wofür sind die? 
Ich kann mir zwar etwas darunter vorstellen, aber für mich klingen xZenAUS und bResetModus ziemlich gleichbedeutend?
Mit BOOL werden bei Dir anscheinend BitVariablen bezeichnet.
Ich kann verstehen, dass die Bit-Darstellung für Dich übersichtlicher ist. 
Aber bei Deiner Anwendung geht allein durch die Vielzahl der übersichtlichen Bit-Darstellungen die Übersichtlichkeit verloren - oder?
Du schreibst, dass Du mit DoppelWorten (32 Bit) wenig vertraut bist, aber mit Worten (16 Bit).
Das kommt meinen Vorstellungen sehr entgegen, weil ich leider keine Übersicht über die S7-Befehle habe, wohl aber über die S5-Befehle.
S5 kennt nicht so viele DoppelWortBefehle wie S7 und ich habe nicht im Kopf, wie die "neuen" Befehle in S7 alle heissen ;o(
Darum hatte ich schon beschlossen, dass wir uns auf die wortweise Programmierung beschränken.
Ich denke, für Dich ist es wichtig, dass Du den "GedankenSprung" von der bitweisen Welt in die Wort-Welt schaffst und erlebst, dass dieser Schritt ein ganz einfacher ist.
Vielleicht etwas gewöhnungsbedürftig, aber mehr (bzw. schlimmer) auch nicht!
Sooo, in Vorbereitung auf den Sprung von CFC-bitweise nach AWL-wortweise, machen wir jetzt erstmal den Schritt von CFC-bitweise nach AWL-bitweise.
Dazu wirst Du einige AWL-BitBefehle kennenlernen, die Dir erspart blieben, wenn wir unser Ziel auf direkten Wege anstreben würden.
Aber - ich bin sicher - das "verkraftest" Du!
Kannst Du mir eine AWL-Druckansicht von einem FB schicken?
Vielleicht von dem StromstossDingens oder irgendwas, wo ich sehen kann, was man alles deklarieren kann/muss und wie das auszusehen hat?
Ich werde auch mal suchen, 






ob bzw. was ich da finden kann. 
Gruss, Heinileini


----------



## Heinileini (7 Juli 2017)

Hallo egro! Ist das lesbar? Und von Dir in einen FB umsetzbar? Vorspann und Zuordnung zu realen Ein-/Ausgängen und Merkern, sowie Aufruf in CFC bleibt Dir überlassen.
Gruss, Heinileini


----------



## PN/DP (7 Juli 2017)

Ich schätze, auch dieses S5-AWL-Listing wird dem Fragesteller überhaupt nicht helfen ... :sad: Eine Übersetzung in Codesys CFC wird wohl nur Programmierern gelingen, die in S5 und Codesys viel Erfahrung haben.

Harald


----------



## Heinileini (7 Juli 2017)

Moin Harald!
Ja so ist das. Traurig, aber wahr. Zwei, die von tuten und blasen ganz viel NullAhnung haben, versuchen, sich gegenseitig etwas beizubringen ...
CFC sagt mir immer noch recht wenig, erinnert mich aber stark an FUP. In S7-AWL habe ich schon einiges programmiert, nicht sehr lange, aber schon lange her. S5-AWL ist zwar noch länger her, aber dennoch viel präsenter.
Nein, wir versuchen, für die Verwendung in CFC einen FB in AWL zu kreieren. Das InnenLeben des FB wollen wir nicht in CFC darstellen.
Sollten wir als Amateure das hinkriegen, überlegen wir uns noch, ob wir im FB eine ProgrammSchleife realisieren oder, ob wir im CFC den FB n-mal aufrufen (für ca. 100 Taster also rund 7-mal bei wortweiser Verarbeitung).
Wer unseren Versuch hier mitliest und davon nicht angeekelt ist, darf uns gerne helfend in die Seite springen!
Gruss, Heinileini


----------



## egro (7 Juli 2017)

Ihr habt ALLE recht!!!

Ich kann nicht für Heinileini sprechen, aber ich habe definitiv zu wenig Ahnung...

Lieber Heinileini, vielen Dank für deine Hilfe.
Das Ganze hier führt zu nichts. Das wäre dasselbe, als wenn du chinesisch sprichst und ich japanisch. Jetzt sollen wir beide thailändisch lernen, damit wir uns verstehen?
Das kann nicht klappen...
Trotzdem noch einmal Danke für deine Mühe. Ich hoffe, du bist jetzt nicht sauer.

Also, wenn irgendjemand einen Lösungsvorschlag im Codesys mit CFC (oder ST für Anfänger) hat, darf er sich gerne melden.
Ansonsten ist es auch nicht schlimm, da ich mich eigentlich damit abgefunden habe.

Bis bald und ein schönes Wochenende an alle.


----------



## Heinileini (8 Juli 2017)

Moin egro!
Nein, ich bin nicht sauer. Das HinUndHer auf diesem Wege scheint tatsächlich nicht der fruchtbarste Weg zu sein.
Da müsste man wohl gemeinsam vor Deinem Bildschirm hocken und experimentieren. Da könnten wir uns mit Händen und Füßen verständigen ;o)
Bin gespannt, ob jemand eine Lösung für Dich hat, die sich nicht zu weit von CFC und der Visualisierung entfernt.
Beim Thema Visualisierung würde ich die eigentlichen Probleme erwarten, die Deinem Bestreben im Wege stehen.
Die Verarbeitung Deiner vielen EinzelBits wortweise zu erschlagen und diese wiederholt in CFC aufzurufen, ob mit ProgrammSchleife (sofern überhaupt möglich?) oder durch mehrfachen Aufruf eines jeweils anders parametrierten FB ... das dürfte relativ leicht machbar sein, aber vermutlich die Möglichkeiten der Visulisierung überschreiten.
Wenn Du dann nur der Visualisierung wegen alles doch Bit für Bit programmieren bzw. eine eigene Realisierung der Visualisierung erfinden musst, das wäre auch nicht in Deinem Sinne.
Frohes und erfolgreiches Gelingen wünscht Dir Heinileini
PS: Hatte mal (zu S5-AWL-Zeiten) einen Chef, der sagte "Ein guter Ingenieur muss faul sein!"
Recht hatte er, in dem Sinne, dass Vereinfachen immer angesagt ist, sei es durch Standardisierung, ProgrammSchleifen oder was auch immer.


----------



## PN/DP (8 Juli 2017)

egro schrieb:


> Also, wenn irgendjemand einen Lösungsvorschlag im Codesys mit CFC (oder ST für Anfänger) hat, darf er sich gerne melden.


Vielleicht schreibst Du besser auch noch mal Deine Frage? Eventuell in einem neuen Thread?
Ich denke, Du solltest hilfsbereiten Usern das Helfen möglichst einfach machen. Wir haben jetzt hier 4 Seiten fruchtloses hin-und-her - also zumindest ich habe die Übersicht verloren, worum es überhaupt geht.

Harald


----------



## StructuredTrash (8 Juli 2017)

Die ursprüngliche Aufgabe war ja, 100 mal das Gleiche zu tun, nur halt jedesmal mit anderen Variablen. Dazu eignen sich Arrays, und die sind am Einfachsten in ST zu handhaben. Es ist deshalb sinnvoll, die Kenntnisse in dieser Sprache zu vertiefen.
Als erstes deklarierst Du nicht 3 x 100 einzelne Bool-Variablen, sondern 3 Arrays mit je 100 Bools, die von 1 bis 100 durchnumeriert sind:

```
VAR_GLOBAL
   HW_Taster_A,
   Visu_Taster_B,
   Verknuepfung_C:ARRAY[1..100] OF BOOL;
END_VAR
```
Auf die einzelnen Bools in den Arrays wird mit Hilfe ihrer Nummern zugegriffen, z. B. so:

```
Verknuepfung_C[54]:=HW_Taster_A[54] OR Visu_Taster_B[54];
```
Das Schöne bei den Arrays ist, dass die Indizes in den Eckklammern nicht nur Konstanten, sondern auch Variablen sein können. Das kann man sich mit einer FOR-Schleife zunutze machen, um alle Array-Elemente nacheinander zu bearbeiten.

```
VAR
   Index:USINT;
END_VAR

FOR Index:=1 TO 100 BY 1 DO
   Verknuepfung_C[Index]:=HW_Taster_A[Index] OR Visu_Taster_B[Index];
END_FOR
```
Die Schleife wird 100 mal durchlaufen, wobei Index nach jedem Durchlauf um 1 erhöht wird. Beim ersten Durchlauf ist Index=1, beim zweiten =2, beim dritten =3 usw.
Nach dem 100. Durchlauf wird Index=101, die Schleife wird verlassen und mit dem darunter stehenden Code weitergemacht.
Wenn die Schrittweite, um die der Schleifenzähler erhöht werden soll, =1 ist, kannst Du das "BY 1" auch weglassen.
Wie PN/DP schon angemerkt hat, dauert die Bearbeitung mit der Schleife länger als wenn Du die Verknüpfungen einzeln schreibst. Schliesslich muss nach jedem Durchlauf der Schleifenzähler erhöht und mit seinem Endwert verglichen werden. Bei dem bisschen, was in der Schleife gemacht wird, kommt die Einschätzung, dass es gut und gerne doppelt so lang dauernd wird, schon hin, aber auch damit sollte der Controller noch kein Problem haben.
Dafür wirst Du ein Problem bekommen, wenn Du das HW-Taster-Array mit HW-Eingängen verknüpfen willst. Wenn Du das so tust,

```
HW_Taster_A AT %IB0:ARRAY[1..100] OF BOOL;
```
legst Du das komplette Array auf Dein HW-Abbild. Der Datentyp BOOL wir aber von CodeSys als BYTE gespeichert, von dem nur das unterste Bit genutzt wird. Wenn Du bitweise auf das Array schaust, liegt also
Taster[1] auf Bit 0, Taster[2] auf Bit 8, Taster[3] auf Bit 16 usw. Du wirst aber wohl kaum 100 8-fach-Eingangsklemmen verbauen wollen, von denen Du nur den ersten Eingang nutzt. Also musst Du das Array mit Platzhalter deklarieren

```
HW_Taster_A AT %I*:ARRAY[1..100] OF BOOL;
```
und die 100 Bools einzeln mit Hilfe der VAR_CONFIG-Tabelle mit den HW-Eingängen verknüpfen. Ich weiss nicht, ob das überhaupt so ohne Weiteres möglich ist oder noch zusätzliche Trickserei erfordert. In jedem Fall verlagerst Du die Schreibarbeit nur vom Programm auf die VAR_CONFIG-Tabelle und hast eigentlich nichts gewonnen.
Eine einfachere Lösung ist nur möglich, wenn die 100 HW-Taster auf aufeinanderfolgenden Bits des HW-Abbildes liegen oder oder zumindest immer in zusammenhängenden Gruppen von 8,16 oder 32 Tastern.
Das musst Du erst mal klären.


----------



## Heinileini (8 Juli 2017)

Sehr sauber, Structured (den Rest Deines Namens lasse ich weg - der ist nicht gerechtfertigt)!!!
Das kann sogar ich verstehen und Dank den CodeBeispielen sollte egro mit der Anwendung Deiner Erläuterungen klar kommen.
Der Pferdefuß dürfte im Satz "Der Datentyp BOOL wird aber von CodeSys als BYTE gespeichert, von dem nur das unterste Bit genutzt wird" liegen, den Du auf das HW-Taster-Array beziehst. 
Das gilt dann sicherlich nicht nur für die HW-Eingänge, sondern gleichermaßen auch für die HW-Ausgänge (und sonstige BOOL-Variablen) ... und wahrscheinlich nicht nur bei Arrays vom Typ BOOL, sondern auch bei "normalen" BOOL-Variablen.
Ja, egro möchte auch ca. 100 Ausgänge (für Lampen) ansteuern und somit wiederholt sich das Spielchen mit der Schreibarbeit in der VAR_CONFIG-Tabelle.
Nicht nur das - muss ich mir jetzt Sorgen machen, dass das Adressieren einzelner Bits von Bytes oder Worten oder DoppelWorten zum Abenteuer wird? 
Eine simple "DoppelDefinition" desselben SpeicherBereichs, z.B. mal als Wort, mal als BitFeld oder EinzelBits (bzw. eine entsprechende DatenStruktur), dürfte konsequenterweise auch nicht zulässig sein? 
Hmmm, wer hat sich bloss dieses CoDeSys ausgedacht? 
Gruss, Heinileini


----------



## StructuredTrash (8 Juli 2017)

@Heinileini
Kannst den Namen ruhig ausschreiben, ich habe ihn mir ja selbst gegeben. Ohne Humor ist unser Beruf nicht zu ertragen, wir würden sonst Konstrukteure fressen.
Die Speicherung von Bools in Bytes ist wohl dem Umstand geschuldet, dass viele CoDeSys-Steuerungen mit ganz normalen Intel- oder ARM-CPUs arbeiten, die nicht für die Vearbeitung einzelner Bits optimiert sind. Trotzdem bietet CoDeSys aber auch einen einfachen Zugriff auf Bits in Integer-Variablen. Auch lassen sich einzelne Bool-Variablen ohne weiteres mit einem Bit des HW-Abbildes verknüpfen. Problematisch wird es nur, wenn ein Bool-Array oder eine Struktur, die Bools enthält, mit der Hardware verknüpft werden soll, denn im HW-Abbild sind die Bits gepackt. Ich hätte es auch besser gefunden, wenn man zwischen den Typen BOOL und BIT unterscheidet. Dann hätte man aber konsequenterweise den Typ BIT auch für die Anwendung im Programm unterstützen müssen, was wohl nicht gewollt war.
Um mit verschiedenen Datentypen auf den gleichen Speicherbereich zuzugreifen, muss man die Variablen von Hand auf die gleiche Adresse legen. Das geht, ist aber unüblich und an sich auch nicht gewollt. Wenn man das tut, ist man völlig auf sich allein gestellt, wenn es darum geht, die Übersicht über die verwendeten Adressen zu behalten. CoDeSys 3 hat mit den Unions eine bessere Lösung, was dem TE aber nichts nutzt, weil sein Controller nur mit CoDeSys 2 läuft.


----------



## Thomas_v2.1 (9 Juli 2017)

Der IEC-Standard sagt für den Datentyp BOOL ja nur "shall" 1 Bit, und nicht "must". Etwas unschön bei Codesys ist allerdings, dass die Bitanzahl eines BOOLs auf ein und demselben Controller mal 1 Bit und mal 8 Bit ist. Und das ist wirklich einmalig (unschön).


----------



## egro (9 Juli 2017)

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...


----------



## Heinileini (9 Juli 2017)

@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


----------



## Heinileini (9 Juli 2017)

@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


----------



## StructuredTrash (9 Juli 2017)

@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:

```
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.


----------



## bons (9 Juli 2017)

Instanz FB mehrmals aufrufen mit verschiedenen DB-Daten


----------



## StructuredTrash (9 Juli 2017)

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.


----------



## Heinileini (10 Juli 2017)

@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


----------



## Thomas_v2.1 (10 Juli 2017)

StructuredTrash schrieb:


> 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


----------



## StructuredTrash (10 Juli 2017)

Thomas_v2.1 schrieb:


> 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.


----------



## egro (16 Juli 2017)

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.


----------



## Blockmove (16 Juli 2017)

Thomas_v2.1 schrieb:


> 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


----------



## Heinileini (16 Juli 2017)

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


----------

