TIA Bitweiser Zugriff auf Bytes über eine Konstante

TaHan

Level-2
Beiträge
128
Reaktionspunkte
11
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin zusammen,

weiß einer ob es in TIA die Möglichkeit gibt variablen Bitweise zu schreiben oder zu lesen, indem man Konstanten als Klartext hinter dem Byte/word etc. mit anfügt?

Code:
// Deklaration BitNummer als globale Konstante
BitNummer : USint := 5;

//Byte Bitweise beschreiben
ByteVariable.%X[BitNummer]:=TRUE;

Mein Gedanke ist, dass ich die Variablen mehrmals beschreiben muss. Sollte sich jedoch nun die Bitnummer ändern, dann ist die Wartung immens, wenn die Variable mehrmals verarbeitet wird. Ich weiß zumindest, dass es in Codesys möglich ist. Bin mir aber nicht sicher, ob TIA die Möglichkeit auch gibt.
Es kommt zumindest immer als Rückmeldung vom Compiler, dass der Datentyp falsch ist.
 
Moin zusammen,

weiß einer ob es in TIA die Möglichkeit gibt variablen Bitweise zu schreiben oder zu lesen, indem man Konstanten als Klartext hinter dem Byte/word etc. mit anfügt?

Code:
// Deklaration BitNummer als globale Konstante
BitNummer : USint := 5;

//Byte Bitweise beschreiben
ByteVariable.%X[BitNummer]:=TRUE;

Mein Gedanke ist, dass ich die Variablen mehrmals beschreiben muss. Sollte sich jedoch nun die Bitnummer ändern, dann ist die Wartung immens, wenn die Variable mehrmals verarbeitet wird. Ich weiß zumindest, dass es in Codesys möglich ist. Bin mir aber nicht sicher, ob TIA die Möglichkeit auch gibt.
Es kommt zumindest immer als Rückmeldung vom Compiler, dass der Datentyp falsch ist.

Nope, so zumindest nicht.
Was du suchst, ist die AT-Sicht.

 
Zuviel Werbung?
-> Hier kostenlos registrieren
Nope, so zumindest nicht.
Was du suchst, ist die AT-Sicht.
Das will ich zumindest vermeiden. Aber gut. Dann hab ich es mir bereits so gedacht.


So hatte ich das früher auch gemacht, aber das geht nur in nicht optimierten Bausteinen.
 
Ich hab dir einen Beitrag zur AT-Sicht verlinkt.

 
Ich hab dir einen Beitrag zur AT-Sicht verlinkt.

Danke, hab ich schon gesehen.
 
Laut Siemens sollte das auch bei optimierten Bausteinen klappen

ja, stimmt. Da geb' ich dir recht.

Dennoch ist es nicht das, was ich wirklich suche. Bei der Variante ist die Wartungsfreundlichkeit auch eher schlecht. Wenn nur ein Baustein entsprechend damit erstellt wird, ist das ja ok. Aber bei mir geht es in einem Projekt durch mehrere Bausteine, die dann auch je nach Zustand und Prozess unterschiedlich aufgerufen werden.
 
Die andere Alternative ist ein Dreher der Bits bei der Übergabe/Übernahme. Die Variablen werden ja nur an einer zentralen Stelle übergeben und da könnte man diese entsprechend dann drehen. Sollte dann auch schneller gehen. Nur ist das für einen zweiten, der mit dem Projekt nicht vertraut ist, oder für mich in einigen Jahren auch nicht wirklich nachvollziehbar. Auch wenn es an der zentralen Stelle gut kommentiert wurde. IN dem Baustein selbst wird das niemand nachvollziehen können.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hat dies mit bitadressierte Alarmmeldungen für die HMI zu tun ?
Ich frage, weil ich finde es schwierig eine andere Anwendung vorzustellen wo man einzelne Bits über eine Konstante addressieren muss.
Sollte sich jedoch nun die Bitnummer ändern, dann ist die Wartung immens, wenn die Variable mehrmals verarbeitet wird.
Warum sollte die Bitnummer sich ändern ?
Weil die HMI Alarmmeldungen verschoben werden ?

Wenn das zu dein Anwendung passt, dann übergebe die Offsetadressen für die Alarmmeldungen über das Bausteinschnittstelle.

Eine Warnung: Bits die in diese Weise addressiert werden können schwierig zu lokalisieren sein.
 
Zuletzt bearbeitet:
Hat dies mit bitadressierte Alarmmeldungen für die HMI zu tun ?
Ich frage, weil ich finde es schwierig eine andere Anwendung vorzustellen wo man einzelne Bits über eine Konstante addressieren muss.
Nein.

Warum sollte die Bitnummer sich ändern ?
Es geht um die Modernisierung einer Anlage. Die bestehende Steuerung soll durch eine S7-1500 ersetzt werden. Es gibt Bezeichnungen, die sich mir nicht ganz erschließen. Ich warte noch auf die Rückmeldung durch den Kunden. Solange können wir schlecht warten, da die Anlage in gut einem Monat fertig programmiert sein muss. Deswegen kann es passieren, dass sich noch die Bitnummern ändern. Es steht z.B. in der vorherigen Steuerung Eingangsbyte, wird jedoch ab Bit 8 geschrieben, bzw. gelesen, was ja zum Datentyp Byte nicht passen kann. Daher ist das nicht ganz klar.

Aber es ist natürlich auch für zukünftiges programmieren nicht verkehrt, so etwas zu wissen.
Ich versuche immer den Code so einfach wie nur möglich zu schreiben, so dass dieser leicht von jedem nachvollzogen werden kann und damit auch die Wartung auch für mich in z.B. 5 Jahren schneller geht.
 
Ich habe einige Retrofit Projekte gemacht, und kann nur sagen dass die alte Programme sollen man nur für Aufklärung verwenden, um auszufinden welche Funktionen in den alten Program gab. Unerklärlichen Programme oder schlechten Programmstil muss weck.
Das neue Programm wird gemacht mit die aktuellen Stand der Technik.

Adressierung von E/A über Offset ist ein Beispiel von was nicht wieder gemacht werden soll.

Programmiere die E/A Symbolisch, und mit BMK, nicht E/A Hardwareadresse.
Wenn eine BMK geändert werden muss, dann einfach das Symbol und/oder die dementsprechende Hardwareadresse aktualisieren.
Das schlägt in das Programm durch. Wenn einen BMK die Datentyp ändert, dann das Symbol dementsprechen ändern. Man wird dann gezwungen das Programm zu ändern für den geänderte Datentyp.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich versuche immer den Code so einfach wie nur möglich zu schreiben, so dass dieser leicht von jedem nachvollzogen werden kann und damit auch die Wartung auch für mich in z.B. 5 Jahren schneller geht.
Wie kommst du dann auf die Idée, E/A über konstanten zu Adressieren ?
 
Ich habe einige Retrofit Projekte gemacht, und kann nur sagen dass die alte Programme sollen man nur für Aufklärung verwenden, um auszufinden welche Funktionen in den alten Program gab. Unerklärlichen Programme oder schlechten Programmstil muss weck.
Das neue Programm wird gemacht mit die aktuellen Stand der Technik.

Adressierung von E/A über Offset ist ein Beispiel von was nicht wieder gemacht werden soll.

Programmiere die E/A Symbolisch, und mit BMK, nicht E/A Hardwareadresse.
Wenn eine BMK geändert werden muss, dann einfach das Symbol und/oder die dementsprechende Hardwareadresse aktualisieren.
Das schlägt in das Programm durch. Wenn einen BMK die Datentyp ändert, dann das Symbol dementsprechen ändern. Man wird dann gezwungen das Programm zu ändern für den geänderte Datentyp.
Das ist der Plan. Der Programmierstil ist extrem schwierig nachzuvollziehen, was da gemacht wird. Vor allem wird ständig mit while und goto gearbeitet. Viele Schleifen enden in einer Endlosschleife. Das ist auch das, was der Kunde uns berichtet hat, dass sie öfters die Steuerung neu starten mussten, weil die sich wieder aufgehängt hatte.

Ich versuche so gut es geht, das ganze so aktuell wie nur möglich zu halten und vor allem das ganze zu vereinfachen. Es werden viele Variablen mehrfach beschrieben, sodass es hin und wieder vorkommen kann, dass hier eine Doppelzuweisung auftritt.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wie kommst du auf E/A?
Von dies:
Es steht z.B. in der vorherigen Steuerung Eingangsbyte, wird jedoch ab Bit 8 geschrieben, bzw. gelesen, was ja zum Datentyp Byte nicht passen kann.

Die Bitnummer ist Konstant und hat eine symbolische Adresse.
Du meinst innerhalb von eine E/A Addresse willst du eine bestimmte Bitnummer adressieren.
Wenn 'nur' ein Bit innerhalb von ein Byte, und nicht die volle E/A Addresse, es ändert nicht dass ich keinen Grund finde warum man sowas machen wurde.
 
Wenn 'nur' ein Bit innerhalb von ein Byte, und nicht die volle E/A Addresse, es ändert nicht dass ich keinen Grund finde warum man sowas machen wurde.
Geht ja nicht nur um ein Bit, letzten Endes geht es um alle 8 von jeweils 9 E/A. Somit müsste ich unter umständen 72 Bits an unzähligen Stellen anpassen. Wenn es sich herausstellt, das die Schnittstelle Byteweise angesprochen wird, müssen die Bits der Eingangsvariable/Ausgangsvariable von 0-7 geschrieben werden. Wenn es jedoch Wortweise ist, dann eben von 8-15.

Letzten Endes benötige ich die Signalaustauschliste vom Kunden. Ohne die fische ich nur im trüben. Vor Ort an der Anlage wird das nur extrem stressig werden. Zudem die Zeit nicht da ist, um das ganze entsprechend anzupassen.
 
Nun glaube ich es handelt um Signalaustausch, vielleicht über Profibus oder Profinet ?
Ok, das ändert nichts zu dem Thema.
Geht ja nicht nur um ein Bit, letzten Endes geht es um alle 8 von jeweils 9 E/A. Somit müsste ich unter umständen 72 Bits an unzähligen Stellen anpassen.
Du richtest die Variabeln in die Symboltabelle ein. Das geht schnell. 72 Bits ist nicht viel. Kommt es zu Änderungen werden sie schnell eigeführt.
Viel schlimmer ist irgend schwierig zu folgen Addressierung wenn das Anlage läuft.

Kann auch sein die Daten kommen über ein DB. Dann konfigurierst du die DB dementsprechend.

Es kann auch vorteilhaft sein die Daten in eine oder mehrere Datentypen zu organisieren. Das geht bei E/A und auch über DBs.
Ich glaube aber es ist in diesen Fall vielleicht nicht notwendig.

Letzten Endes benötige ich die Signalaustauschliste vom Kunden. Ohne die fische ich nur im trüben. Vor Ort an der Anlage wird das nur extrem stressig werden.
Öhm, ja.
Zudem die Zeit nicht da ist, um das ganze entsprechend anzupassen.
Wenn du nur eine halbe Idée haben von wie das Schnittstelle aussieht, dann ist die Bit Adressen das kleinste Problem.
Wenn es nur handelt um die Bitadressen, dann ist es ganz unproblematisch die obengenannte symbolische Addressierung zu aktualisieren.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Du richtest die Variabeln in die Symboltabelle ein. Das geht schnell. 72 Bits ist nicht viel. Kommt es zu Änderungen werden sie schnell eigeführt.
Viel schlimmer ist irgend schwierig zu folgen Addressierung wenn das Anlage läuft.

Die Variablen sind bei mir ja auch in einem DB hinterlegt. Es wird symbolisch darauf zugegriffen. Das ist ja nicht das Problem.

Code:
 ByteVariable.%X[BitNummer]:=TRUE;

ByteVariable.% => symbolsicher Zugriff über DB
[BitNummer] => kann sich Ändern, je nachdem was das für ein Datentyp ist. Aus einer 0 kann eine 8 werden, aus einer 1 eine 9 usw.

Und genau um diese Bitnummerierung geht es. Das andere ist ja kein Problem. Ob es nun in der Variablentabelle oder halt im DB geändert wird, dann ändert sich global sofort der entsprechende Name. Auf die Bitnummer kannst du nicht einfach so ändern.
Hier an dieser Stelle würde ja die Konstante kommen (in Codesys gut umsetzbar). Denn so ein Bit kann sich doch schon mal ändern.
Ich gebe dir auch recht, dass es dann schwieriger zum Nachverfolgen wird, jedoch denke ich, dass es sich dann doch eher in Grenzen halten wird.

Nun glaube ich es handelt um Signalaustausch, vielleicht über Profibus oder Profinet ?
Geht um eine Profibus Anbindung.
Bei Profinet würde ich mir da keine Gedanken machen. über IO-Device ist das ganze schnell umgesetzt.
 
Bei Profinet würde ich mir da keine Gedanken machen. über IO-Device ist das ganze schnell umgesetzt.
Profibus und Profinet haben beide E/A Bereiche die man eventuell in ein DB hinterlegen kann.
Was ist es dass du in Profinet machen kann aber in Profibus nicht ?

Ist es vielleicht kein Profibus Master/Slave, sonder S7-Kommunikation über Profibus ?
In den Fall, die Daten kommen in ein DB, die definierst du Symbolisch und fertig.
Kommt es spähter zu Änderungen, z.b. die Daten verschiebt sich innerhalb von die DB, dann einfach die DB dementsprechend aktualisieren.
 
Zurück
Oben