TIA AS-Register für S7-1500 ????

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

irgendwie gibt's die Ansicht der AS-Register im TIA für 1500 nicht mehr???

Screenshot für TIA mit 300er:


Wie kann ich mir online die Adressregister oder DB Register für 1500er anschauen???

Gruß.

 

[PN/DP]

Kann man beim Beobachten von AWL-Code die entsprechenden Spalten einblenden?

Harald

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

nicht das ich wüsste wie .....

 

[HelleBarde]

Hallo ducati

1200 und 1500 verwenden ein anderes Modell wie 300 und 400. Nur bei AWL Bausteinen wird ein Registersatz angezeigt, weil für AWL die Welt der 300/400 simuliert wird.

Den ersten Generationen der 1200 konnte man noch unter den Rock schauen. Die haben deutlich mehr Register. Für mich hat sich das dargestellt als ob es jeweils über 32 Register für Bits, Bytes, Words und DWords gibt. Statt zwei DB und AR Register gibt es über 32 kombinierte Adressregister. Und für REAL gibt es nochmals mindestens 4 Register. Das macht mehr als 164 Register ... mindestens. Denn bei Bausteinaufrufen werden Parameter über einen weiteren Registersatz geschoben.

Ob es bei der 1500 auch so ist, weiß ich nicht. Die weigert sich bisher erfolgreich sich unter den Rock sehen zu lassen, so wie neuere 1200er auch. Aber ich gehe davon aus, dass es dort auch so ist. Ein DB Register gibt es nicht mehr, deswegen braucht es auch diese Ansicht nicht.

'n schön' Tach auch
HB

 

[ducati]

Hmm, ja hab ich mir auch schon so ähnlich gedacht... Nur fuer die FehlerSuche in nem 1500er AWL Programm wäre es hilfreich zu sehen, welchen Wert AR1 gerade hat, auch wenn's das nur im Quelltext gibt und nicht mehr im compilierten Programm...
Ist halt alles ne Kruecke irgendwie...

 

[miasma]

Zuviel Werbung?
-> Hier kostenlos registrieren

Es gibt noch die lokale Fehlerbehandlung mit dem Befehl Get_Error, was die allerdings bei AWL in Verbindung mit AR ausspuckt kann ich die nicht sagen.
Die Fehlerinformation dieser Anweisung gibt aber einiges an Informationen zurück.

 

[ducati]

Es gibt noch die lokale Fehlerbehandlung mit dem Befehl Get_Error, was die allerdings bei AWL in Verbindung mit AR ausspuckt kann ich die nicht sagen.
Die Fehlerinformation dieser Anweisung gibt aber einiges an Informationen zurück.

ja nee Es geht nicht um Errorhandling....

Es war früher in der 300er und Step7 Classic einfach komfortabel, wenn man in jeder Programmzeile online beobachten konnte, wo das Adressregister, DB-Register oder VKE usw. gerade stand...

Gruß.

 

[HelleBarde]

Hallo Ducati

früher, bei der AS400 hast du dem Prozessor der AS400 (Siemens ASIC, also Eigengewächs) direkt in die wenigen Register sehen können die dieser hatte.
Später, bei der AS300 war dem schon nicht mehr, denn die verschiedenen Prozessoren, die im Laufe der Zeit darin verbaut wurden, haben alle den Registersatz der AS400 simuliert. Ziemlich vollständig, aber doch keine 100%. Geht schon damit los, dass die 400 vier Akkus hat die 300 nur zwei.

Seit der 1200 ist es vorbei damit. Die 1200 hat kein AWL, also warum sollte S. dann den Registersatz simulieren lassen. Von der 1500 wissen wir es nicht. Auf einer Messe hat einer auf dem Vertrieb gesagt, dass die Hardware der 1516 und der 319 praktisch die Gleiche wäre. Dafür ist die 1516 aber deutlich schneller. Vermutung meinerseits, weil sie eben den Registersatz der 400 nicht mehr emuliert. Und die 1518 habe eine bessere Hardware und ist nochmals deutlich schneller.

Bisherige Konsequenz. Es gibt keine Haltepunkte mehr. Dafür gibt es den Trace. Wäre schon schön wenn die Haltepunkte endlich mal kämen. In SCL und KOP/FUP wäre das eine echte Bereicherung. AWL verwende ich nicht mehr. Nur noch um es auszumerzen. Wenn vielleicht in 5 Jahren doch mal Haltepunkte wieder kommen, dann würde es mich weder wundern, noch würde es mich stören, wenn man nicht in jeder Zeile einen Haltepunkt setzen kann.
Von der 1200 weiß ich, dass eine Addition in einem drei Address Befehl ausgeführt wird, der bereits das ENO mit bestimmt. Also nix mehr mit Lade lade +I Transfer, UN OV, SAVE, CLR, U BIE. Das ist nur noch ein Befehl. Da kann man also auch keinen Haltepunkt mehr mitten rein setzen. Wozu auch? Wenn ich die drei Speicherstellen sehen kann, dann weiß ich auch ohne Register was gerechnet wurde.

Wenn ein Zugriff auf ein Array mittels Index aus einer Variablen in AWL hingeschrieben werden kann, ohne, dass ich mehrere Zeilen AWL mit AR Gymnastik verbrate, dann danke ich dem Werkstudenten, der das bei S. eingebracht hat. Dem AR Register weine ich keine Träne nach. Das hat mir deutlich zuviele Monate Fehlersuche eingebracht. Was hätte ich alles mit meinem langen Berufsleben Inbetriebsetzen können, wenn myArray[#i] in AWL bereits mit Step7 V5.0 oder 4.0 gegangen wäre.

'n schön' Tach auch
HB

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Der Hintergrund ist dieser BUG:

Wenn ein PEW als Eingang an einem FC nicht erreichbar ist, wird FC nicht bearbeitet

und dieser Workarround:

//Im FC "MyFC":
//  IN: IN_POINTER : POINTER
// Temp: Adr_0 : WORD
// Temp: Adr_2 : DWORD

      L     P##IN_POINTER
      LAR1

      L W [ AR1 , P#0.0 ]
      T     #Adr_0
      L D [ AR1 , P#2.0 ]
      T     #Adr_2

      L     #Adr_0
      L     0
      ==I
      SPB   XXX1
      AUF DB [ #Adr_0]
XXX1: NOP 0

      L D [ AR1 , P#2.0 ]
      LAR1
      L W [ AR1 , P#0.0 ] // Lesen des Wortes, diese Anweisung löst ggf. den OB122 wegen Peripheriezugriffsfehler aus
      T MW100      // hier liegt der Wert vom eingelesenen Signal

Ansonsten bin ich auch kein Freund von Pointern, deshalb ist es für mich umso wichtiger ne Diagnosemöglichkeit zu haben, wenn ich trotzdem verwenden muss...

Aber Danke für die Antwort, also gibt es diese Anzeige der Register nicht mehr!!!

Gruß.

 

[HelleBarde]

Hallo Ducati

was du offenstichtlich brauchst, ist die Prüfung, ob hinter einer Adresse auch tatsächlich eine Baugruppe existiert. Auch dafür braucht man keine Pointer mehr.
Ich habe solche Stellen mit GET_ERROR ersetzt.

"dummy" := #para_in; // probeweiser Zugriff
#err := GET_ERRID(); // oder so ähnlich
if #err = 0 then
   // Baugruppe vorhanden
else
   // Baugruppe tot
end

Man sollte für "dummy" keine Variable aus TEMP verwenden. Da sie nicht verwendet wird, schmeißt der Compiler die Zuweisung raus. Und damit auch den Zugriff. S. behauptet das sein ganz toll optimiert. Auf der einen Seite haben sie recht auf der anderen Seite ist es ärgerlich. Es stört zwar nicht, dass ich nun für "dummy" ein Merkerbit, byte, word, ... je nach dem was #para_in für einen Typ hat. Aber was dann wieder nervt, dass ich diesen Baustein nicht in die Bibliothek stecken kann, da er einen Merkerzugriff enthält.

An die mitlesenenden S.-Mitarbeiter: Gebt uns dafür einen SFC.

'n schön' Tach auch
HB

 

[Thomas_v2.1]

Bei GET_ERRID() kommt der Geruch von Visual Basic durch, und ich mag diesen Geruch zumindest nicht.

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

@Helle
Wir haben einen Messwert-FC. In disem soll auch die GESAMTE Fehlerauswertung erfolgen... Zusaetzlich und Ausserhalb des FC kann ich natürlich viel machen, war und ist aber in unserem Anwendungsfall nicht gewünscht. Daher fanden wir bisher den Workaround mit dem Pointer am besten...
Gruß

 

[ducati]

Bei GET_ERRID() kommt der Geruch von Visual Basic durch, und ich mag diesen Geruch zumindest nicht.

Der gleiche Gedanke kam mir dabei auch...
So oder so bringt mir das aber auch nix, da in dem FC keine Zeile Code ausgefuehrt wird, wenn das am Eingang verschaltete "EWXXX" nicht erreichbar ist. Egal ob GET_ERR verwendet wird oder nicht...
Wie in dem anderen Thread erklärt, war die Uebergabe als Pointer an den FC fuer uns aktuell die beste Loesung...

 

[HelleBarde]

Hallo Ducati

du willst im FC prüfen ob der außerhalb des FC angeschlossene Wert existiert? Klingt verworren, ist es für mich auch.

Bei 1500 uns 1200 werden Werte einfacher Datentypen (BOOL bis LREAL) dem FC als Werte übergeben, erst Strings, Strukturen und noch größeres werden per Referenz übergeben. Wenn du also außerhalb einen Zugriffsfehler hast, dann gibt es nichts was übergeben werden kann. Klar wird dann in dem FC keine Zeile Code ausgeführt, weil der FC gar nicht aufgerufen wird.

Ja, für das was du machen willst, müsstest du einen Zeiger auf tag reinreichen. Hat S. aber nicht. Laut Norm wäre dann dein Parameter P : REF_TO WORD und innerhalb des FC könnte man mittels P^ den Zugriffsfehler provozieren.

Schon mal probiert, ob du den Parameter als P : VARIANT deklarierst von außen mit tag versorgst und innen mit unsäglichem wert:=VariantGet(INT,P); den Zugriffsfehler auslöst.

'n schön' Tach auch
HB

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

du willst im FC prüfen ob der außerhalb des FC angeschlossene Wert existiert? Klingt verworren, ist es für mich auch.

Nee, vielleicht hab ich es hier nur verworren beschrieben, in dem anderen Thread zum PEW ist doch verständlich erklärt, wo das Problem liegt...

Ich habe einem FC mit einem Eingang WORD. an dem Eingang ist ein PEW verschalten. Wenn der PEW nicht erreichbar ist (Netzwerkkabel zur ET200 kaputt) wird der gesamte FC nicht bearbeitet. In dem FC steht bei uns unter anderem aber die Fehlerauswertung zu diesem EINEN verschalteten PEW...

Die Lösung/Workarround von PN/DP und mir hier war, den Eingang des FC nicht als WORD zu deklarieren sondern als POINTER. Und dann das PEW dort anzulegen. somit wird der FC auch im Fehlerfall bearbeitet und unsere Fehlerauswertung in dem FC auch.

Nur muss ich dann in dem FC eben mit dem Pointer weiterarbeiten...

Die Geschichte mit dem VARIANT hat mir Siemens jetzt auch mal vorgeschlagen. Da wir aber momentan im Projektstress sind, kann ich das nicht auch noch ausprobieren...

Gruß.

 

[rostiger Nagel]

sag mal warum baust du dir nicht ein Prüfbaustein,
wo du deine genutzten PEW/PAW's anlegst, vor dem
Aufruf schaltetst du ein Bit auf False, im Baustein
lässt du es auf True setzen wenn alles in Ordnung ist.

So kannst du dir doch die ganze Pointerrei sparen.

 

[ducati]

sag mal warum baust du dir nicht ein Prüfbaustein,
wo du deine genutzten PEW/PAW's anlegst, vor dem
Aufruf schaltetst du ein Bit auf False, im Baustein
lässt du es auf True setzen wenn alles in Ordnung ist.

So kannst du dir doch die ganze Pointerrei sparen.

Ja, das wäre der einfachste Workarround. Vor dem Bausteinaufruf das PEW auf ne Temporäre Variable kopieren und diese dann am Baustein anschalten.

Aber erstens widerspricht das etwas unserem Programmierstil und zweitens verhindert das ja nicht, das irgendein Programmierer der die Bibliothek dann einsetzt nicht doch an dem Messwertbaustein nen PEW dranschreibt...

Gruß.

 

[rostiger Nagel]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn man sich das so recht überlegt, hat Siemens indirekt die
Alarm OBs teilweise auf Eis gelegt, dafür waren die doch mal gedacht.

 

[PN/DP]

sag mal warum baust du dir nicht ein Prüfbaustein,
wo du deine genutzten PEW/PAW's anlegst, [...]

Was nützt dieser zusätzliche Aufwand außerhalb seines FC? Dann weiß er zwar schon vor seinem FC-Aufruf, daß das PEW nicht erreichbar ist, doch deshalb wird sein FC trotzdem nicht aufgerufen, solange das PEW da auf normale Art verschaltet ist. Der einfachste Workaround außerhalb des FC ist, die PEW auf eine Speichervariable zu kopieren und diese Speichervariable zu verschalten - dafür muß aber jede PEW-Verwendungsstelle geändert werden. Dieses Kopieren darf natürlich nicht mit einem Baustein gemacht werden, es muß ein MOVE oder L+T sein. (nicht das womöglich die MOVE-Anweisung nach Siemens-Philosophie irgendwann auch nicht mehr ausgeführt wird ... )

Wir haben hier schon eine Anzahl Einsatzszenarien gefunden, wo die einfache Anschaltung von PEW (historisch) durchaus normal ist und wo niemand mit diesem nicht dokumentiert geändertem Verhalten gerechnet hat und nachgebessert werden muß, weil teilweise Gefahren für die Anlagen bestehen.

Wie ist das eigentlich, wenn man ein S7-300/400-classic-Programm nach TIA migriert: warnt da der Konverter, daß auf der S7-1500 der Baustein eventuell nicht mehr aufgerufen wird? Oder werden die PEW-Verwendungen automatisch auf Prozessabbild-Zugriffe umgeändert (und informiert/gewarnt)?

Harald

 

[ducati]

Wie ist das eigentlich, wenn man ein S7-300/400-classic-Programm nach TIA migriert: warnt da der Konverter, daß auf der S7-1500 der Baustein eventuell nicht mehr aufgerufen wird? Oder werden die PEW-Verwendungen automatisch auf Prozessabbild-Zugriffe umgeändert (und informiert/gewarnt)?

Harald

nee, bei der Migration keine Warnmeldung, vom Compiler keine Warnmeldung, im migrierten 1500er Programm bleibt die PEW Verschaltung bestehen...