TIA Direkter Zugriff auf einzelne Komponenten von DT

[Chris1803]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
Ich suche einen Weg direkt auf den Wochentag im Datentyp DT im TIA V16 zuzugreifen.

Dieser Wert liegt laut TIA Information in den 4LSB von Byte 7 im BCD-Format vor.

Kennt einer von euch einen Weg diesen Wert mit optimierten Bausteinzugriff "auszulesen"? Ich möchte weder konvertieren noch DTL nutzen. Ich denke da an einfache Wege wie Pointer auf das letzte Byte, maskieren und fertig....

Ich hoffe ihr versteht was ich meine...

Schonmal danke im Vorraus.

 

[PN/DP]

Welche CPU hast Du?
"Pointer" auf optimierten Speicher gibt es nicht. Du könntest einen Baustein-Eingangsparameter mit einem Byte-Array oder einer Struktur überlagern mit AT und dann auf das entsprechende Byte zugreifen und die relevanten Bits ausmaskieren.

Harald

 

[LNy]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die CPU muss eine 1500er sein.
DT gibt es nur bei 300er und 1500er, aber 300er können keine optimierten Bausteine.

Ich verstehe nur nicht warum der Datentyp nicht konvertiert werden darf, denn das ist immer noch die einfachste Lösung.
Schreib einen FC mit DT Input, intern konvertieren zu DTL und Output Wochentag.
Damit ist das Problem in 2 Minuten erledigt und man muss nicht Stundenlang über eine Lösung nachdenken.

 

[kafiphai]

 

[Chris1803]

Danke für die Antworten.
@PN/DP die CPU ist eine 1500er. Was meinst du mit "AT"?

@LNy die Vorgabe/Bitte keine Konvertierung zu nutzen kam von meinem Elektroingenieur. Der achtet auf jedes Byte. Und da das DT ja nur 8 Byte anstelle von 12 Byte des DTL hat kam halt die Frage auf.
Man müsste doch einfach nur den Speicherinhalt von DT(Byte7) in ein anderes Byte kopieren....
Gut man könnte jetzt auch einfach eine TEMP Variable nutzen, das war aber so nicht das Ziel

@kafiphai die Frage bezog darauf es ohne Konvertierung zu machen. Der Weg ist mir bekannt, trotzdem danke dir.

 

[JesperMP]

Zuviel Werbung?
-> Hier kostenlos registrieren

die Vorgabe/Bitte keine Konvertierung zu nutzen kam von meinem Elektroingenieur. Der achtet auf jedes Byte. Und da das DT ja nur 8 Byte anstelle von 12 Byte des DTL hat kam halt die Frage auf.

Die S7-1500 CPUs haben Megabytes von Datenspeicher. Es lohnt sich nicht wenige Bytes zu sparen.
Wichtiger ist dass das Program einfach zu warten ist.

Und warum soll der Elektroingenieur dich erzählen wie du als Programmierer das Programm erstellen will ?
Es lautet als eine ältere Kollege ist der für 20 Jahren her ein S5 programmiert hat.

 

[LNy]

Vielleicht solltest dem Ingenieur mal vor das Schienbein treten
Wenn die 12 Byte ein Problem sind dann wird da noch ne Menge Sch*** auf dich zukommen.

Pack die Konvertierung in einen FC, dann benötigst du nur etwas RAM und etwas Zykluszeit für die eine Konvertierung pro Zyklus.

 

[NBerger]

So einen Sch... Sorry macht man doch heute nicht mehr.

Mit Zeigern hantieren und irgendwo herumpointern ist mittlerweile ganz schlecht...

 

[Chris1803]

Zuviel Werbung?
-> Hier kostenlos registrieren

Und warum soll der Elektroingenieur dich erzählen wie du als Programmierer das Programm erstellen will ?
Es lautet als eine ältere Kollege ist der für 20 Jahren her ein S5 programmiert hat.

Weil dieser Herr der Meinung ist er wäre Chef der Abteilung....

Und ja der Herr ist aus S5-Zeiten und wünscht sich nichts mehr als die alten STEP-7 Zeiten zurück. Alles was TIA betrifft und gerade der optimierte Bausteinzugriff ist seiner Ansicht nach Mist.
Aber als Denkaufgabe fand ich das echt gut, denn dieses Byte liegt ja im Speicher warum also nicht direkt auslesen....

 

[Chris1803]

Vielleicht solltest dem Ingenieur mal vor das Schienbein treten
Wenn die 12 Byte ein Problem sind dann wird da noch ne Menge Sch*** auf dich zukommen.

Pack die Konvertierung in einen FC, dann benötigst du nur etwas RAM und etwas Zykluszeit für die eine Konvertierung pro Zyklus.

Hahaha Zykluszeit da triffst du genau den Punkt.... dem ist schon 1nsek zu viel.... aber als Denksportaufgabe gar nicht schlecht eigentlich...

So einen Sch... Sorry macht man doch heute nicht mehr.

Mit Zeigern hantieren und irgendwo herumpointern ist mittlerweile ganz schlecht...

Du würdest dich wundern mit was für Ideen der um die Ecke kommt.

Alles getreu dem Motto:"Das haben wir immer schon so gemacht, und ich will das so wie das immer war....."

 

[JesperMP]

Als Denkaufgabe, kannst du wie PN/DP verschlägt das AT-Sicht verwenden.
Dann ist die Zugang in Prinzip Code-Frei und kostet kein Speicher und kein Zykluszeit. Sehr elegant, wenn man es verwenden kann.
Wie das Name andeutet, ist das AT-Sicht ein Verfahren womit man dieselbe Daten mehrmals betrachtet, je mit unterschiedlicher Deklaration.
Die Randbedingungen:
Muss STAT in ein FB sein.
Die FB/IDB muss entweder nicht-optimiert sein, oder die Remanenz für AT-Variable muss als 'In IDB setzen' gewählt werden.

Hier ein Video:

Um diese Inhalte anzuzeigen, benötigen wir die Zustimmung zum Setzen von Drittanbieter-Cookies.
Für weitere Informationen siehe die Seite Verwendung von Cookies.

Drittanbieter-Cookies akzeptieren

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich bin gerade auf der Autobahn Richtung Forumstreffen...
Gibt es LWORD? Kann man DT in LWORD konvertieren oder kopieren? Geht Slice-Zugriff auf Byte in LWORD? Wenn nicht, dann den DT auf ein Byte-Array kopieren (z. B. in Temp) oder wie ich schon oben schrieb, den DT per AT mit einem Byte oder einer Struktur überlagern.
Erklärt doch mal jemand dem TE was AT ist, er findet es anscheinend nicht in der TIA-Hilfe?

Harald

 

[funkey]

So?

 

[JesperMP]

Das musste gehen.

 

[NBerger]

Zuviel Werbung?
-> Hier kostenlos registrieren

@ Chris1803: Dein Ingeniör hat nicht zufällig den Spitznamen "FF" ?

 

[PN/DP]

AT-Lösung noch etwas besser lesbar mit Struct:

FUNCTION "DT_Weekday" : USInt
{ S7_Optimized_Access := 'FALSE' }
VERSION : 0.1
   VAR_INPUT
      "DT" : Date_And_Time;
      DTstruct AT "DT" : Struct
         YEAR   : Byte;
         MONTH  : Byte;
         DAY    : Byte;
         HOUR   : Byte;
         MINUTE : Byte;
         SECOND : Byte;
         MSEC12 : Byte;
         MSEC3WEEKDAY : Byte;
      END_STRUCT;
   END_VAR

BEGIN
  //Wochentag aus DATE_AND_TIME
  #DT_Weekday := #DTstruct.MSEC3WEEKDAY AND 16#0F;

END_FUNCTION

Harald

 

[funkey]

So habe ich es für meine S7-1200er gemacht um den Data_And_Time nachzubauen.

 

[escride1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Zykluszeit da triffst du genau den Punkt.... dem ist schon 1nsek zu viel

Nicht optimierte Bausteine werden langsamer abgearbeitet. Sehr viel langsamer, so Faktor 3 oder so. Daher sollte man nur noch mit optimierten Bausteinen arbeiten.

Es stellt sich mir die Frage ob Euer Ingenieur überhaupt ne Ahnung von dem hat was er da verlangt oder ob ihm vielleicht mal jemand erklären sollte das er keine Vorgaben macht wenn er die Auswirkungen nicht kennt.

 

[PN/DP]

Nicht optimierte Bausteine werden langsamer abgearbeitet. Sehr viel langsamer, so Faktor 3 oder so.

Hast Du das selber gemessen/verglichen oder ist das nur Wiedergabe der Marketing-Sprüche?

Außerdem: nur Variablenspeicher kann "optimiert" sein, nicht der Programmcode. Wenn das Programm kaum Daten verarbeitet sondern z.B. nur E/A, dann wird da auch kein nennenswerter Laufzeit-Unterschied zu messen sein.

Harald

 

[JesperMP]

Hast Du das selber gemessen/verglichen oder ist das nur Wiedergabe der Marketing-Sprüche?

Ich habe es gemessen, es stimmt tatsächlich - bis auf 10 mal schneller. Die Frage ist aber ob die absolut kleinste Zykluszeit wichtig ist. Die heutige CPUs sind auch mit nicht-optimierten DBs schneller als S7-300/400.

Man muss auch verstehen dass nur die Code der optimierte und nicht-optimierte DBs anfasst, mit nicht-optimerte Zeiten bearbeitet wird.
Das ganze Programm läuft nicht langsahm wenn nur ein kleinen Bruchteil von die DBs nicht-optimiert sind.