TIA AWL Probleme mit LD Zugriff in FC bei TIA V17

StallionP51

Level-2
Beiträge
5
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

ich habe ein Problem bei der Umsetzung eines FC aus Step7 V5.6 nach TIA V17/18. Es geht darum einen bestehenden AWL FC aus einem Step7 Programm in TIA zu übernehmen. Der FC steuert einen alten Micromaster 4 über Profibus an. Dazu wird im FC das PED des Micromasters gelesen und in eine temporären Variable des FC
geschrieben.

Die Tempvariable bzw. deren Struktur sieht in Step7 wie folgt aus:
1708934121534.png

Der zugehörige Code im FC sieht folgendermaßen aus:
1708934007485.png
Die Daten werden also vom Micromaster als doppelwort gelesen und dann in Temp29 und dessen Struktur gespeichert. Weiter unten kann man dann auf die einzelnen Bits bzw. Worte zugreifen. Das Ganze funktioniert auf dem bestehenden System (313C-2 DP) tadellos.

Jetzt zum Problem. Ich habe erwartet, dass bei der Umsetzung des Programmes auf TIA V17 das ebenfalls ohne Probleme geht. Pustekuchen! Der Zugriff auf Lokaldaten des FC'S muss sich geändert haben. Zuerst die Schnittstelle des FC. Wie man sehen kann hat sich gegenüber Step7 nichts geändert:
1708934880466.png

Die Ausgabe bei TIA sieht aber folgendermaßen aus:
1708934983322.png
Für mich stellt sich das so dar, dass in TIA AWL, der Befehl "LD" nicht mehr vorgesehen ist? Hier stehe ich auf dem Schlauch und habe auch nichts adequates im Netz gefunden. (Oder ich frage falsch oder bin zu dämlich). Vielleicht kennt jemand von Euch hier eine Lösung. Liegt vielleicht nur an der Schreibweise? Ich bin ratlos!

Viele Grüße
Thomas
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo DeltaMikeAir,

vielen Dank für die schnelle Reaktion. Gerne, sobald ich Zeit habe. Der MM4 fliegt irgendwann raus und die Anlage bekommt einen Retrofit auf Profinet mit neuen Antrieben. Bis dahin brauche ich sozusagen eine "Quick and dirty" Lösung. Den Rest der Anlage habe ich schon ins 21. Jahrhundert überführt. Mir rennt einfach die Zeit davon.
 
Das ist nur eine Warnung. Sollte funktionieren
Das wird angemekert da deine struct (temp30) bei adresse 8 nur 16 bit und nicht 32 bit breit ist.
 
Ich sehe das auch so wie Volker.
Das ganze Ding scheint sowieso ein AG-Abzug zu sein (wegen der durchgängigen Variablen-Benunng TEMP).
In diesem Fall wird das PEW des Umrichters gelesen und auf die Bits des Statusword geschrieben. Wieweit diese natürlich mit der aktuellen Bezeichnung sinnvoll nutzbar sind will ich mal dahingestellt sein lassen ...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Aber liegt nicht Temp29 an Adresse 8.0?
Bzw. welche der drei Variablen an Adresse 8.0 sieht der Compiler, wenn die Warnung ausgeworfen wird? Wir haben schließlich ein Bool dort (Temp31), ein Struct mit 16 Bool (Temp30) und ein Struct mit einem Struct aus 16 Bool und einem Word (Temp29)
 
das sind 2 struct unterhalb der ersten struct. daher haben 2 struct dieselbe anfangsadresse.
dem compiler ist hier völlig egal wie die var heisst. er verwendet gnadenlos die adresse.

er kann das aber auch so schreiben.

Code:
L     #iDP_IO_Adresse
      SLD   3
      LAR1
      L PEW [ AR1 , P#0.0 ]
      T     %LW8
      L PEW [ AR1 , P#2.0 ]
      T     %LW10
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Also offengestanden, wenn man jetzt mal formale und Stilkriterien außer acht lässt, sollte das auch in TIA nach wie vor so funktionieren.
Die Warnung ist nur eine Warnung, aus gutem Grund weil man hier auch ziemlichen Mist machen könnte.

Also wenn es ohnehin Quick and Dirty sein soll und darf: Scheiß drauf ...
 
er kann das aber auch so schreiben.

Code:
L     #iDP_IO_Adresse
      SLD   3
      LAR1
      L PEW [ AR1 , P#0.0 ]
      T     %LW8
      L PEW [ AR1 , P#2.0 ]
      T     %LW10
... sieht auch schöner aus ... ;)
... und erzeugt so die selbe Warnung bei LW8, weil an LW8 keine Word-Variable liegt. Bringt also gar nix.
Außerdem wissen wir nicht, of der PED-Zugriff einfach so auf 2 PEW-Zugriffe aufgeteilt werden darf (Konsistenz und so).

Wenn schon umschreiben, dann so, dass TIA nichts mehr zum Meckern findet:
Code:
LAR1 P##TEMP29 //AR1 auf die Anfangsadresse der 32-Bit-Struktur an #TEMP29 setzen
L PED [#TEMP9]
T D [AR1, P#0.0] //ein Doppelword auf die Struktur #TEMP29 (%LD8) schreiben

// T LD [AR1, P#0.0] geht auch
 
Zuletzt bearbeitet:
Hallo Zusammen,

vielen Dank für Eure Hinweise. In der Tat, PN/DP's Code funzt ohne das TIA was zu meckern hätte. Vielen Dank dafür. Ich werde das mal so übernehmen und ausprobieren. Am Ende muss ich ja die Daten noch auf den Ausgang schreiben. In Anlehnung an PN/DP's Code müsste das dann.... der Originalcode:
Code:
 L     LD     4
 T     PAD [#TEMP9]

.....so aussehen. (TEMP10 oder LD 4 beinhaltet die Ausgabeergebnisse)
Code:
  LAR1  P##TEMP10
  L D [ AR1 , P#0.0 ]
  T PAD [ #TEMP9]

jedenfalls meckert TIA auch hier nicht.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
jedenfalls meckert TIA auch hier nicht.
Ich frage mich halt immer noch, warum man hier Energie reinsteckt, den alten Code irgendwie hinzubekommen anstatt es einfach vernünftig zu machen.
Gerne, sobald ich Zeit habe.
Sei doch mal ehrlich, sobald dein AWL Konstrukt läuft machst du da eh nichts mehr.
 
Hallo DeltaMikeAir,

Ja, da hast Du vollkommen Recht. Sicher nicht für einen MM4 auf Profibus. Aber hier haben wir eine alte Rumpel, die bis zum Retrofit laufen soll. Die Originalsoftware hat entweder ein Genie oder ein Drogenabhängiger geschrieben. Bin mir noch nicht sicher. Das meiste ist bereits mit neuer Software ausgestattet und die gesamte Steuerung modular aufgebaut und ich kann einfach durch Austausch einzelner FB's auf neue Technik zugreifen. Insofern werde ich in der Tat keine Hand mehr an den "FC14" Micromaster legen.

Gruß Thomas
 
Am Ende des Tages ist der MM4 auch nur ein Profidrive Umrichter.
In diesem Sinne würde ich mich verhältnismäßig sicher behaupten trauen, dass ein Baustein der mit einem G120 funktioniert auch mit minimalsten (oder keinen) Anpassungen für den MM taugen sollte. Insbesondere wenn hier nur PPO3 (also 2 Worte hin und her) im Spiel ist.

Generell verstehe ich nachwievor nicht, weshalb du wg. einer Warnung hier so einen Aufwand betreibst ... erst recht wenn man eh nie vorhat das ganze wirklich vernünftig und zeitgemäß zu lösen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo MSB,

lass mal stecken. Unsere Maschinen arbeiten schon lange nicht mehr mit FU's. Hier handelt es sich um einen obsoleten Tellerantrieb. Wir verbauen da nur noch Servoantriebe. Das Thema ist zu komplex. Ich bin jemand der konsequent alten Code verwirft und neu aufbaut. Zumal meine Vorgänger hier Chaos hinterlassen haben. Bei dem Thema handelt es sich wirklich um ein Provisorium, dass einigermaßen laufen muss und das am besten Gestern. Dabei ist es mir lieber ohne Warnungen auszukommen. Hinter jedem kleinen Problem steckt ein großes, was gerne raus will. An der Stelle bin ich froh, auch wenn es funktionieren mag, wenn keine Warnung vom Compiler kommt. Stichwort konsistente Daten.
Die Tage bin ich schlauer, da muss das beim Kunden laufen.

Gruß Thomas
 
Zurück
Oben