TIA Datentyp HW_IO und Zugriff auf Subslot in S7-300/400 vs. 1500

Draco Malfoy

Level-1
Beiträge
1.168
Reaktionspunkte
82
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Forum!

Plage mich derzeit mit folgender Fragestellung. Es wurde zwar in dem anderen Thema kurz angerissen, aber ich machs mal hier ganz konkret:
Es wird ein Projekt von Classic nach TIA v13 mit 1500er migriert. In zwei Steps, also erst mal überhaupt TIA und dann die 1500er. Im Projekt werden SFB 53/54 RDREC und WRREC aktiv gebraucht.
Jetzt habe ich folgendes Problem:

- In der Classic-Welt wird lediglich eine INT-Zahl als E/A Adresse im Peripeherie-Bereich (oder auch Prozessabbild, is aber egal) angegeben, und, vorausgesetzt E=A dann kann man hier lustig mit verschiedenen Offsets rumspielen und weiß der Geier noch was machen.
- In der 1500er gibt es das alles nicht mehr, sondern jetzt gibt es nur eine Hardware-Kennung, die automatisch vergeben und fest eingetragen wird, und dazu einen zugehörigen Datentyp HW_IO. Ich kann da also nicht einfach so offsettiert auf meine Peripherie-Bereiche zugreifen und da irgendwelche Daten rausholen.

Jetzt wurde in dem Classic-Projekt aber ne Menge mit Offsets gemacht, das sah dann folgendermaßen aus (ausgelagert in nen separaten Baustein):
Code:
        (* berechnet die LOG. Adresse, um auf den jeweiligen Kanal zuzugreifen.
         * berechnet aus Slot- und Indexinformation die jeweile Adresse des Statuswortes
         *)
        #ADRESS:= WORD_TO_INT(DWORD_TO_WORD(#ID)) + #OFFSET;
 
        (* direkter Zugriff auf indizierten Adressbereich *)
        #INPUTS:= %EW(#ADRESS);
 
        (* Errorhandling *)
        #ERROR:= FALSE;
        #STATUS:=16#0;
Dieser #Inputs Parameter wurde an den RDREC weitergereicht, der dann auf den Peripherie-Adressbereich mit einem kanalabhängigen Offset zugreifen konnte.
Wenn ich es richtig sehe, kann ich diese Funktionalität jetzt aber komplett knicken oder ?? Ich müsste jetzt quasi alle Daten in einen DB mit entsprechender Struktur schreiben, um dort das rauszuholen, was ich brauche, oder ?
 
Zuletzt bearbeitet:
Wenn ich es richtig sehe, kann ich diese Funktionalität jetzt aber komplett knicken oder ?? Ich müsste jetzt quasi alle Daten in einen DB mit entsprechender Struktur schreiben, um dort das rauszuholen, was ich brauche, oder ?

Zumindest in der Form. Ich denke der Weg den Siemens gehen will ist über die Vollsymbolische Anbidung. Das heisst gibt der Hardwarekennung ein sinnvolles Symbol und mach die Adressierung damit.
Wie mann dann allerdings das Symbol dann in der Laufzeit zusammenbauen könnte ist mir noch Rätselhaft. Möglich sein müsste es ja da die Symbole ja auch auf der CPU landen.

Da wäre irgendwie ne Funktion String2Symbol was nettes.

Lange Antwort in kurz. Jap ich denke bei der 1500er kannst du deine bisherige Vorgehensweise knicken.

mfG René
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hm. Aber woher weiß ich, welche Hardware-ID mein Kanal denn überhaupt hat ?
Jetzt wird nur noch eine Modul-ID vergeben, aber jedes Modul hat 2 Kanäle. Früher wurde ja mit Offset darauf zugegriffen, aber jetzt muss man sich nen Offset raten oder wie ?
Selbst wenn ich diese HW_IO Kennung schon im Engineering-Prozess vergeben wollte...
 
GEO2LOG und LOG2GEO wären was für dich.

Damit könntest du deine alte Vorgehensweise wieder aufbauen.

mfG René
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
GEO2LOG und LOG2GEO wären was für dich.

Damit könntest du deine alte Vorgehensweise wieder aufbauen.

mfG René

Wenn schon, dann eher LOG2MOD ;-)
Aber trotzdem, danke für den wertvollen Hinweis. Habe jetzt die Seite 180 ff. im Berger Buch zu dem Thema entdeckt. Die Frage ist, schlicht und ergreifend, warum für meine abgesetzte Baugruppe keine separierte Hardware-Kennung mehr existiert, wenn ich dort 2 Submodule habe. Müssten ja eigentlich auch 2 separate HW-IDs in der Gerätesicht zu finden sein, aber es ist nur 1 und die sieht so aus: "2x_RS422_Kanäle_RFID_1[AI/AO]"
 
Zuletzt bearbeitet:
Wenn schon, dann eher LOG2MOD ;-)
wenn ich dort 2 Submodule habe. Müssten ja eigentlich auch 2 separate HW-IDs in der Gerätesicht zu finden sein, aber es ist nur 1 und die sieht so aus: "2x_RS422_Kanäle_RFID_1[AI/AO]"

Sie sind da ja auch. Bzw. so wie in Step7 wird nur der beginn angegeben.

bsp mit RD_LGADR holst du dir die EA Adresse.
Wie du die HW_ID zuvor herleitest ist dir ja überlassen.

Aber wenn du die EA Adresst hast. Arbeitest du wieder wie gewohnt.

Code:
[COLOR=#333333]        (* direkter Zugriff auf indizierten Adressbereich *)
[/COLOR][COLOR=#333333]        #INPUTS:= %EW(#ADRESS);[/COLOR]

Der zweite Eingang wäre dann:
#INPUTS:= %EW(#ADRESS + #OFFSET);
ggf noch mit INT_TO_word und umgekehrt experimentieren. da bin ich mir nicht sicher wie der index aufgebaut ist.

mfG REné
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Sie sind da ja auch. Bzw. so wie in Step7 wird nur der beginn angegeben.

bsp mit RD_LGADR holst du dir die EA Adresse.
Wie du die HW_ID zuvor herleitest ist dir ja überlassen.

Aber wenn du die EA Adresst hast. Arbeitest du wieder wie gewohnt.

Code:
[COLOR=#333333]        (* direkter Zugriff auf indizierten Adressbereich *)
[/COLOR][COLOR=#333333]        #INPUTS:= %EW(#ADRESS);[/COLOR]

Der zweite Eingang wäre dann:
#INPUTS:= %EW(#ADRESS + #OFFSET);
ggf noch mit INT_TO_word und umgekehrt experimentieren. da bin ich mir nicht sicher wie der index aufgebaut ist.

mfG REné

Ah ok, ich habs gerafft! Ich dachte, das alte Programm will am Ausgang durch die Migration ja wieder HW_IO haben, um damit SFB 53/54 zu füttern, aber wie es scheint tun die weiter im Code tatsächlich nur auf ein Eingangswort normal zugreifen, daher entwällt diese "Rückwandlung" nachdem ich den Offset addiert habe. Vielen Dank nochmal. So hat das jetzt ne Chance wieder zu funktionieren ;-)
 
Ich wüsste gerne wie du bei der 300er damals die #ID errechnet hast. Für mich sieht das so aus als hättest du da auch nur die Adresse eingegeben und einfach für den nächsten Eingang weitergezählt.
Das ist ja jetzt in der 1500 nicht anders die HW_ID ist was anderes als die IO_Adresse (welche auch in der 1500 noch von Hand vergeben werden kann)

mfG Renà
 
Glaube wir müssen erst mal die Begrifflichkeit definieren. Mit #ID meinst Du jetzt was genau ?
Die Classic Variante hat einfach ne logische Anfangsadresse gekriegt und über den Offset das nötige EW rausgesucht. Jetzt ist es aber so, daß der FB keine logische Adresse, sondern nur diese sch*** HW_IO bekommt, mit der er erst mal nichts anfangen kann und wo er die logische Adresse daraus extrahieren muss.

Bei dem obigen habe ich zunächst gedacht, daß er auch ne HW_IO wieder zurückgeben muss, aber ich habe mich geirrt.
SFB 53/54 bekommen ihre HW_IOs (früher: logische Anfangsadresse) woanders übergeben und da wird auch nichts offsettiert.

Sehe gerade nicht so ganz, wo das Problem liegt. Es ist halt so, daß es früher ein und dasselbe war, und jetzt irgendwie verschiedene Dinge die nichts miteinander zu tun haben.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Die Classic Variante hat einfach ne logische Anfangsadresse gekriegt und über den Offset das nötige EW rausgesucht.

Und an der Logischen Anfangsadresse hat sich ja mit der 1500er ja leider nichts geändert. E-Adresse im HW Manager

Jetzt ist es aber so, daß der FB keine logische Adresse, sondern nur diese sch*** HW_IO bekommt, mit der er erst mal nichts anfangen kann und wo er die logische Adresse daraus extrahieren muss.

Bei dem obigen habe ich zunächst gedacht, daß er auch ne HW_IO wieder zurückgeben muss, haben will, aber ich habe mich geirrt.
SFB 53/54 bekommen ihre HW_IOs woanders übergeben und da wird auch nichts offsettiert.

Auch das hat sich ja in der 1500er nicht geändert. Ich glaub im grunde genommen läuft immernoch alles so wie zuvor für dich. Ich hab dich einfach falls verstanden. Dachte du hättest bei der 300er direkt Slot im Programm adressiert und mit der im HW-Manager vergebenen IO Adresse garnix gemacht.

mfG René
 
René, Du verstehst mich falsch !

Niemand gibt meinem Programm jetzt irgendeine logische Adresse ! Sonst müsste ich ja zwei Eingangswerte definieren, HW_IO und Logische Anfangsadresse.
Es kriegt jetzt ganz einfach eine HW_IO und muss damit zurecht kommen.

Haupsächlich wird diese HW_IO gebraucht, um damit RDREC und WRREC zu füttern, aber an einigen Stellen greifen die da direkt auf ein %EW bzw. %AW zu, und das kann ich eben nicht mit HW_IO.
Ich will jetzt ein Programm von S7-300 classic auf S7-1500 im TIA portieren.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
René,

BITTE ich verstehe überhaupt nicht wo jetzt die Schwierigkeiten sind ?
Ich beschreibe meine Vorgehensweise step_by_step:

1. Programm migriert, und festgestellt, daß die RDREC und WRREC mit dem INT-Wert, den sie ürsprünglich über die Bausteinschnittstelle übergeben bekommen, und wo früher die LA ankam, nichts anfangen können.
2. Lösung - Datentyp von "INT" auf "HW_IO" umgestellt, fertig, läuft.
3. Nächstes Problemm - Bausteine "GETIOSUB" und "SETIOSUB" kotzen.
4. Also habe ich gedacht, daß die jetzt HW_IO bekommen und auch HW_IO mit irgendeinem mir unbekannten Versatz wieder herausgeben sollen !
5. Frage im Forum gepostet.
6. Festgestellt, daß entgegen meiner Vermutung von den GETIOSUB und SETIOSUB keinerlei HW_IO zurück erwartet wird, sondern lediglich direkt das %EW bzw. %AW.
7. Funktion gesucht, die mir HW_IO zu der LA wandelt, damit ich dann %EW (#ADRESS) zugreifen kann.
8. Problom gelöst, fertig.

Ich gebe zu, es ist teilweise sehr verworren, und ich bin schlecht in der Lage, mich exact verständlich zu artikulieren, gerade wenn ich noch im Denkprozess drin bin und die Sachen erst nacheinander begreife.
Bitte um Entschuldigung hierfür.

P.S: Der direkte Zugriff auf einen EW / AW scheint bei der 1500er nicht zu funktionieren. Nächstes Problem, hat aber mit dem Vorigen nichts zu tun.
 
Zuletzt bearbeitet:
Noch mal ein Nachtrag, falls es nicht verständlich rüberkommt: migriert werden jetzt in erster Linie nicht diese 3 Zeilen Code, die ich oben gepostet habe.
Migriert werden riesige Bausteine in SCL mit über 2000 Zeilen Code. Einige Funktionen, wie zum Beispiel die Ermittlung von Offsets sind dort aber (vorausschauenerweise ?) ausgelagert worden.
 
Erstmal vorweg. Es gibt überhaupt nix zu entschuldigen und von meiner Seite sollte auch keinerlei Vorwurf herauszuhören sein.

Das mit den Datentypen ist ein Problem. Da musste ich bisher auch am meisten rumschrauben beim Migrieren. Vieles habe ich für mich trotz einwandfreier Funktion nach der Migration markiert als überarbeitungsbedürftig.

P.S: Der direkte Zugriff auf einen EW / AW scheint bei der 1500er nicht zu funktionieren. Nächstes Problem, hat aber mit dem Vorigen nichts zu tun.

Ja da muss man wohl etwas umdenken.
Das läuft jetzt mit "Poke"

z.B. Für Ausgänge
Code:
POKE(area := 16#82,     
     dbNumber := 0,
     byteOffset := #HW_Adresse + #Offset,
     value := #Wert);
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Code:
POKE(area := 16#82,     
     dbNumber := 0,
     byteOffset := #HW_Adresse + #Offset,
     value := #Wert);
Ok, also wieder was dazu gelernt !
Muss man jetzt irgendwelche ansteckende Krankheiten befürchten, wenn ich mit Poken auf meinen Speicher zugfreie :D ?
Habe eben dieselbe Frage (%EW Zugriff) in dem Siemens-Chat gestellt, aber da wussten die so aus dem Stand erst mal auch keine Antwort.
 
Addendum:
PEEK/POKE wird recht ausführlich im Berger Buch abgehandelt. Da habe ich das ganze rausgeholt musste bei meinen Bausteinen eigentlich nur mit Notepad++ durch und Suchen ersetzen machen und alles war wieder happy.

mfG René
 
Zurück
Oben