Großes WORD selber machen

[wonderfulworld]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

mal ne Frage, in Codesys V3 gibt es ja den Datentyp LWORD (64Bit großes Word). Gibt es eine Möglichkeit ein eigenes WORD zu erzeugen, dass größer als 64Bit ist, sich aber genauso Verunden und verodern lässt, wie BOOL, BYTE, WORD; DWORD und LWORD?

Gruß wonderfulworld

 

[Matze001]

Was ist an

WORD1 AND WORD2 AND WORD3 ...

oder

WORD1 OR WORD2 OR WORD3 ...

so schlimm?

Grüße

Marcel

 

[wonderfulworld]

Zuviel Werbung?
-> Hier kostenlos registrieren

Daran ist garnichts schlimm. Aber was hat das jetzt mit meiner Frage zu tun? Ich brauche für einen konkreten Anwendungsfall so ein großes Word.(Das warum ist mir gerade ein bisschen zu kompliziert hier zu erleutern) und wollte wissen ob es bei Codesys V3 die Möglichkeit gibt, sich so ein WORD zu basteln. Dass man das auch anders lösen kann, ist mir auch klar. Aber in diesen einen Fall, wäre ein großes WORD halt die elegantere Lösung. Wenn das nicht geht, ist das auch OK. Aber ich dachte, frag mal lieber. Codesys V3 hat soviel Möglichkeiten, da weiß man nie, was es alles gibt.
Gruß wonderfulworld

 

[PN/DP]

Da vermutlich noch keine SPS ein WORD > 64 Bit nativ unterstützt, müßtest Du diesen Datentyp selber der SPS beibringen. Ist aber eigentlich nicht schwer. Du mußt halt nur alle Operationen, welche Du anwenden willst, selber als Functions schreiben und die Variablen dieses Datentyps als STRUCT oder ARRAY OF BYTE (oder irgendwas) oder als STRING übergeben.

Allerdings sehe ich wie Marcel keinen dringenden Grund, einen solchen Datentyp zu erfinden. Das was Du vorhast läßt sich doch bestimmt auch mit LWORD erledigen. Oder mit einem ARRAY. Erzähl doch mal mehr ...

Harald

 

[JesperMP]

Wofür brauchst du ein Zahlenwert das nicht innerhalb von −(2[SUP]63[/SUP]) und 2[SUP]63[/SUP] − 1 liegen kann ?

Nur als interesse.

 

[wonderfulworld]

Zuviel Werbung?
-> Hier kostenlos registrieren

Bei unserem Schieberegister haben wir bisher für jede Spur einen Bit in einem BYTE als Gut/Schlechtmeldung genutzt. Um dieses Schieberegister drumherum haben wir jetzt auch eine relativ große Bibliothek von Bausteinen und Funktionen geschrieben. Jetzt gibt es aber bei uns immer wieder Maschinen mit mehr als 32 Einträge pro Schiebetakt. Das heißt jetzt nicht, dass wir eine 32-Spurige Maschine bauen, sondern dass Trays in der Maschine gibt, die mehr als 32 Produkte beinhalten. (32 war bei Codesys V2 die Grenze, aber so wie ich unsere Konstruktion kenne, werden die die Grenze von 64 auch bald sprengen. ). Deshalb haben wir gerade bei uns die Diskussion, ob wir nicht auf ein anderes Schieberegister umsteigen. Mit der Konsequenz, viel gut geteste Bausteine wegzuwerfen bzw. umzuschreiben. Deshalb hier die Frage. Wie ihr seht, ist auch neue UND und ODER Funktionen zu schreiben, nicht die Lösung.
Gruß
wonderfulworld

 

[MasterOhh]

Da wird euch wohl nichts anderes Übrig bleiben als etwas neues zu programmieren. Wenn ihr euer Schieberegister mit einem Array umsetzt, dann seit ihr in Zukunft fast nach oben offen was die Länge betrifft.

 

[JesperMP]

Jepp, einfach mit ARRAYs arbeiten.
Das wird auch sauberer denke ich.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hätte man das Bit-Schieberegister mit einem ARRAY OF BOOL realisiert, dann würde sich das wahrscheinlich leicht auf 100 Bits vergrößern lassen. Allerdings hätte man das dann ohne die Word-"Schweinereien" sauber programmieren müssen... naja, hinterher ist man immer schlauer.

Harald

 

[wonderfulworld]

Das Array hat halt den Nachteil, dass es nicht so schön zum Debuggen ist. Deshalb sind wir eigentlich schon Fans vom WORD : )

 

[JesperMP]

Das Array hat halt den Nachteil, dass es nicht so schön zum Debuggen ist. Deshalb sind wir eigentlich schon Fans vom WORD : )

??
Das musst Du tiefer erklären.

 

[MasterOhh]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich denke er meint, dass man es in der Online Ansicht aufklappen und scrollen muss ........

 

[wonderfulworld]

Genau, dass hab ich gemeint. Das macht echt einen Unterschied. Beim Word sehe ich auf einen Blick was Sache ist. Beim Array darf ich aufklappen.:-( Das Beschreiben von einer ganzen Spur als schlecht oder gut, ist auch ganz einfach Gutmeldung := 65 535 und fertig. Beim Array muss ich dass entweder über eine Schleife machen (beim Monitoring auch wieder nicht sehr schön), oder jedes einzelne Element des Arrays beschreiben. Also, dass sind jetzt mal die Vorteil vom Word, die mir einfallen.

Gruß wonderfullworld

 

[wonderfulworld]

Achso ein weiterer Vorteil ist noch, dass es ressourcenschonender ist. Ein Word verbraucht deutlich weniger Speicher, als ein Array of BOOL. Bei dem jeder Eintrag ins Schieberegister mindestens ein BOOL (sprich 32 Bit, soweit ich das jetzt weiß) kostet.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das Beschreiben von einer ganzen Spur als schlecht oder gut, ist auch ganz einfach Gutmeldung := 65 535 und fertig. Beim Array muss ich dass entweder über eine Schleife machen (beim Monitoring auch wieder nicht sehr schön), oder jedes einzelne Element des Arrays beschreiben.

Tja, man muß sich entscheiden, ob man unsauberen quick'n'dirty-Code oder saubere Hochsprache schreiben will. Quick'n'dirty geht meistens nur für eine ganz begrenzte Aufgabe und ist später kaum noch wartbar und erweiterbar.

Harald

 

[Ottmar]

Hi!

Also ich sehe da jetzt das konkrete Problem nicht ganz.
Du kannst doch einen FC oder FB schreiben, der einfach mehrere deiner "Standard-Word-Schiebefunktionen" aneinander kettet.
(Wenn das letzte Bit "true" ist und ein Takt kommt, wird das folgende Schieberegister mit "true" gefüllt - eigentlich ganz simpel)
Oder alternativ intern die anderen Vorschläge (Array of Bool) nutzen (mein Favorit, da siehe folgende Variante).

Für die Diagnose könntest du dann von diesem FC/FB einen String (101010111001001010101010...) ausgeben lassen.
Das geht dann in der Regel bis zu 254 Zeichen. (Sollte ja erstmal reichen *g*)
Für die Variante mit geketteten Schiebefuntionen kannst du für die "Gutmeldung" einen Parameter an "IN" vorsehen, mit dem intern alle Teil-Schieberegister mit "65535" beschrieben werden.
Für die Variante mit dem "Array of Bool" nutzt du einen Schleife für das Setzen der "Gutmeldung".

1. Vorteil: Du kannst den FC/FB so schreiben, dass er deine bisher verwendeten Schieberegister ersetzt.
2. Vorteil: Die Visualisierung kann den Diagnose-String ganz einfach in einem Textfeld(Ausgabe) darstellen.

Das Handling mit intern verwendetem Array ist natürlich für die Ausgabe des Diagnose-String deutlich eleganter, daher würde ich die "Schieberegister-Kacke" verwerfen...


Gruß,

Ottmar

 

[wonderfulworld]

Tja, man muß sich entscheiden, ob man unsauberen quick'n'dirty-Code oder saubere Hochsprache schreiben will. Quick'n'dirty geht meistens nur für eine ganz begrenzte Aufgabe und ist später kaum noch wartbar und erweiterbar.

Harald

Nein, ich würde nicht sagen, dass das einunsauberen quick'n'dirty-Code ist. Natürlich ist das akademisch korrekter und am Schreibtisch auch viel schöner, wenn man ein Array of BOOL nimmt. Aber wenn man bedenkt wie kurz die Programmerstellung (wenige Wochen) bei uns im Haus ist und wie lange die Inbetriebnahmezeiten (mehrere Monate bis sehr wenige Jahre), dann versucht man doch alles so zu programmieren, dass es für den Inbetriebnehmer leichter wird, auch wenn es manchmal auf Kosten der Wartbarkeit und Erweiterbarkeit geht. Kennt ihr dieses Dilema nicht? Ich verzichte aus diesem Grund auch häufig auf Schleifen und mache umständlich einen furchtbaren Code, bei dem x-mal hintereinander immer dasselbe macht, weil ich es dann nachher an der Maschine leichter habe. (Bei Dingen, die während der Inbetriebnahme selten angefasst werden, mach ich das natürlich nicht so. )

Hi!

Also ich sehe da jetzt das konkrete Problem nicht ganz.
Du kannst doch einen FC oder FB schreiben, der einfach mehrere deiner "Standard-Word-Schiebefunktionen" aneinander kettet.
(Wenn das letzte Bit "true" ist und ein Takt kommt, wird das folgende Schieberegister mit "true" gefüllt - eigentlich ganz simpel)
Oder alternativ intern die anderen Vorschläge (Array of Bool) nutzen (mein Favorit, da siehe folgende Variante).

Für die Diagnose könntest du dann von diesem FC/FB einen String (101010111001001010101010...) ausgeben lassen.
Das geht dann in der Regel bis zu 254 Zeichen. (Sollte ja erstmal reichen *g*)
Für die Variante mit geketteten Schiebefuntionen kannst du für die "Gutmeldung" einen Parameter an "IN" vorsehen, mit dem intern alle Teil-Schieberegister mit "65535" beschrieben werden.
Für die Variante mit dem "Array of Bool" nutzt du einen Schleife für das Setzen der "Gutmeldung".

1. Vorteil: Du kannst den FC/FB so schreiben, dass er deine bisher verwendeten Schieberegister ersetzt.
2. Vorteil: Die Visualisierung kann den Diagnose-String ganz einfach in einem Textfeld(Ausgabe) darstellen.

Das Handling mit intern verwendetem Array ist natürlich für die Ausgabe des Diagnose-String deutlich eleganter, daher würde ich die "Schieberegister-Kacke" verwerfen...


Gruß,

Ottmar

Hi Ottmar,

vielen Dank für die alternativen Lösungsvorschläge. Du hast natürlich recht, da gibt es kein Problem Alternativen zu finden. Mir ging es aber eigentlich darum, ob es eine Möglichkeit gibt, so weiter zu machen wie bisher. Deshalb hatte ich auch am Anfang garnicht erklärt warum ich so ein großes Word brauche. Ich wollte einfach nur wissen ob man irgendwie noch ein größeres Word selbermachen kann. Was ja soweit ich das jetzt verstanden habe nicht geht. Damit müssen wir wahrscheinlich was neues machen und da kann man auch gerne deine Variante in Betracht ziehen.

Vielen Dank nochmal für eure Beteiligung

wonderfulworld

 

[Werner29]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo wonderfulword,

du hast dir die Antwort zwar schon selber gegeben aber ich kann es nochmal offiziell verkünden:
es geht nicht.
Das scheitert schon daran, dass es keine Möglichkeit gibt, Literalwerte > 2^64 zu verwenden, und man kann auch keine
Operatoren überladen. Also du kannst auf einem selbstdefinierten Datentyp kein + oder SHL oder so definieren.

Also ohne Änderung gehts nicht. Du musst halt schauen dass du möglichst systematisch die bisherigen Operatoren
durch Funktionen (besser noch: Methoden eines Funktionsblocks) ersetzt.

Ich bin im übrigen ganz auf deiner Seite: nichts spricht gegen ein Bitfeld! Das ist viel schneller und verbraucht kaum Speicher.
Wichtige Eigenschaften, und wenn es der Inbetriebnehmer besser interpretieren kann, das ist doch auch ein Kriterium.
Dass sich irgendwann die Anforderungen an ein Programm soweit ändern, dass man ein Rework braucht, das passiert doch jeden Tag!