gleicher Befehl mehrmals mit verschiedenen Variablen

egro

Level-1
Beiträge
211
Reaktionspunkte
24
Zuviel Werbung?
-> Hier kostenlos registrieren
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...
 
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
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...
 
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 ?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
Andere Ausdrucksweise aber die gleiche Sache...
Nun wird es langsam spannend über wieviele Variablen wir reden...

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
 
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
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.
 
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:
 
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
 
Zuletzt bearbeitet:
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.
:confused: 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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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?
 
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
 
Zuletzt bearbeitet:
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.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
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 ...
 
Zuletzt bearbeitet:
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...
 
Zurück
Oben