gleicher Befehl mehrmals mit verschiedenen Variablen

Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo egro!
Habe den halben Nachmittag an einer Antwort an Dich herumgetippt und dann auf antworten geklickt.

Alles futsch!SMS-Forum2017-07-02.jpg
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
 
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:
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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
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)
 
Zuletzt bearbeitet:
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...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
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.
Unbenannt_4.JPG

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...
 
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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
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,
sigpic6747_1.gif


ob bzw. was ich da finden kann.
Gruss, Heinileini
 
Zuletzt bearbeitet:
Sim-2017-07-06.jpg

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