TIA Flankenmerker aus DB-Baustein funktionieren nicht

Zuviel Werbung?
-> Hier kostenlos registrieren
In AWL musst du gut aufpassen was du tust wenn du mit Pointern arbeitest, Du bist alleine für Adressregister und Adressräume verantwortlich (Wann du welchen DB offen hast). Da nimmt dir SCL einiges an Arbeit ab.

mfG René

Also mit einem herkömmlichen Merker funktioniert alles einwandfrei!!!

Sobald ich diesen aber durch einen Merker aus einem DB ersetze geht die CPU auf Error ...


Also dann ist hier das Problem, dass beim Laden von Null mit dem Merker-DB weitergearbeitet wird?

Der ist nicht so lang wie der Melde-DB ... wie müsste das dann umgeschrieben werden, dass hier wieder der Melde-DB herangezogen wird?


- einfach wieder den Melde-DB aufmachen - ???
 
Zuletzt bearbeitet:
Ja du fügst einen Vollqualifizierten Zugriff ein. Dieser ist eigentlich ein
AUF "DBirgendwas"
FP AR1 irgendwas

Alles was danach kommt solange es kein weiterer vollqualifizierter Zugriff oder ein AUF DB ist. Greift auf DBirgendwas zu.

Du erinnerst dich, dass ich am anfang nach der Fehlermeldung der CPU gefragt habe? Das ist sowas typisches wenns mit DB nicht geht aber mit Merkern schon. Dann ist es oft das nächste, dass irgendwo ein Adressregister versaut wird.

mfG René
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ja du fügst einen Vollqualifizierten Zugriff ein. Dieser ist eigentlich ein
AUF "DBirgendwas"
FP AR1 irgendwas

Alles was danach kommt solange es kein weiterer vollqualifizierter Zugriff oder ein AUF DB ist. Greift auf DBirgendwas zu.

Du erinnerst dich, dass ich am anfang nach der Fehlermeldung der CPU gefragt habe? Das ist sowas typisches wenns mit DB nicht geht aber mit Merkern schon. Dann ist es oft das nächste, dass irgendwo ein Adressregister versaut wird.

mfG René

Hm, also das Einfügen eines Flankenoperanden hätte ich jetzt wirklich nicht als einen Befehl AUF "DBirgendwas" gedeutet!

Müsste ich dann am Ende - also vor dem Laden mit Null - wieder den Melde-DB aufschlagen? :confused:


PS: Ja ich erinnere mich nach der Eingangsfrage mit dem Fehler der CPU - da hatte sie aber noch keinen, weil ich diesen Merker noch nicht ersetzt hatte!
 
Zuletzt bearbeitet:
Hm, also das Einfügen eines Flankenoperanden hätte ich jetzt wirklich nicht als einen Befehl AUF "DBirgendwas" gedeutet!

Müsste ich dann am Ende - also vor dem Laden mit Null - wieder den Melde-DB aufschlagen? :confused:

Genau das. Vollqualifizierte Zugriffe machen nix anderes. Man kann auch das AR1 auch ins Temp retten und wiederherstellen. Machts aber IMHO unleserlich.

Hier wäre vielleicht Umstellen des Codes auch eine Alternative.
Oder das mit den Pointern gleich seinlassen (wäre mein Vorschlag).
Denn das was du da machst, geht auch vollqualifiziert, dann tauchts auch in der Referenz auf.

Man muss nicht alles Pointern. Im gegenteil.
Heute sollte das Hauptgewicht in der Lesbarkeit und in einer vollständigen Referenzliste liegen.

mfG René
 
Code:
      LAR1  P#0.0
      AUF   "DB_Meldung"
      L DBD [ AR1 , P#0.0 ]     [COLOR=#0000ff] //DB_Meldung.DBDx[/COLOR]
      L DBD [ AR1 , P#4.0 ]    [COLOR=#0000ff]  //DB_Meldung.DBDx+4[/COLOR]   
....
      U     "Anlage_Ein"
 [COLOR=#ff0000]     FP   "DB_Merker".M10[5][/COLOR]
      T DBD [ AR1 , P#0.0 ]     [COLOR=#0000ff] //DB_Merker.DBDy[/COLOR]

Du würdest deinen Code ja auch nicht so schreiben und erwarten dass er funktioniert, oder?
Code:
      LAR1  P#0.0
      AUF   "DB_Meldung"
      L DBD [ AR1 , P#0.0 ]      //DB_Meldung.DBDx 
....
      U     "Anlage_Ein"
 [COLOR=#ff0000]     FP  M10.0
[/COLOR]....[COLOR=#ff0000]
[/COLOR]      [COLOR=#0000ff]AUF   "DB_Merker"[/COLOR]
      T DBD [ AR1 , P#0.0 ]  [COLOR=#0000ff]    //Hier bekommst du dann auch den selben CPU-Fehler[/COLOR]
Für die Funktion der Flanke ist es irrelevant ob hier ein Merker oder DB-Verwendet wird.
Durch den DB baust du jedoch selbst einen Fehler in deine Adressregister-Zugriffe ein.

Also dann ist hier das Problem, dass beim Laden von Null mit dem Merker-DB weitergearbeitet wird?
- einfach wieder den Melde-DB aufmachen - ???
Ja. Gewöhn dir das generell an die AUF-Befehle so möglichst nah an die indirekten Zugriffe zu legen.
Gibt nichts schöneres als AWL-Code der über DB-Register zugreift welche vor 10 Seiten Code gesetzt wurden.... :)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Genau das. Vollqualifizierte Zugriffe machen nix anderes. Man kann auch das AR1 auch ins Temp retten und wiederherstellen. Machts aber IMHO unleserlich.

Hier wäre vielleicht Umstellen des Codes auch eine Alternative.
Oder das mit den Pointern gleich seinlassen (wäre mein Vorschlag).
Denn das was du da machst, geht auch vollqualifiziert, dann tauchts auch in der Referenz auf.

Man muss nicht alles Pointern. Im gegenteil.
Heute sollte das Hauptgewicht in der Lesbarkeit und in einer vollständigen Referenzliste liegen.

mfG René

Lieben Dank René,

jetzt muss ich "nur" noch klären, warum der Setzbefehl oder auch dieser Code mit einem Merker aus dem DB nicht funktioniert ...


Code:
//*** Referenzfahrt
      U     "Taste_StrgEin"
    [COLOR=#ff0000]  FP    "DB_Merker".M10[7][/COLOR]
      UN    "iDB85".HomingValid
      S     "iDB85".EnableDrive

      U     "iDB85".DriveEnabled
      UN    "OP_Modus_Einrichten"
      S     "iDB85".Stop

      U     "iDB85".Ready
      UN    "OP_Modus_Einrichten"
      S     "iDB85".Halt

      U     "iDB85".HaltNotActive
    [COLOR=#ff0000]  FP    "DB_Merker".M10[8][/COLOR]
      UN    "OP_Modus_Einrichten"
      S     "iDB85".StartHoming

      U     "iDB85".HomingValid
      UN    "OP_Modus_Einrichten"
      R     "iDB85".StartHoming
 
Lieben Dank René,

jetzt muss ich "nur" noch klären, warum der Setzbefehl oder auch dieser Code mit einem Merker aus dem DB nicht funktioniert ...

Dasselbe Programm? Den anderen Baustein korrigiert? Da überschreibst du ja DB_Merker komplett mit 0 über Bereichsgrenzen hinweg. Dann tut in diesem Baustein hier natürlich kein Flankenmerker mehr. Zumindest nicht so wie er sollte.
Das sind dann die Coolen Sachen. Man ändern in einem Baustein was und in einem anderen der schon funktioniert hat funktioniert auf einmal was anderes nichtmehr.
Hab ich schon erwähnt das ich ein Freund von in sich geschlossenen Instanzen bin?


mfG René
 
Dasselbe Programm? Den anderen Baustein korrigiert? Da überschreibst du ja DB_Merker komplett mit 0 über Bereichsgrenzen hinweg. Dann tut in diesem Baustein hier natürlich kein Flankenmerker mehr. Zumindest nicht so wie er sollte.
Das sind dann die Coolen Sachen. Man ändern in einem Baustein was und in einem anderen der schon funktioniert hat funktioniert auf einmal was anderes nichtmehr.
Hab ich schon erwähnt das ich ein Freund von in sich geschlossenen Instanzen bin?


mfG René

Ja, dasselbe Programm!

Allerdings funktioniert der dargestellte Code in Thread #26 nur sporadisch mit einem DB-Merker; auch, wenn ich in dem anderen Baustein (mit Pointern) einen herkömmlichen Merker verwende!

Will heißen, einmal wird die Referenzfahrt nach dem Einschalten ausgeführt und beim nächsten Mal nicht mehr ...


Aber ich suche mal, ob hier an anderer Stelle noch so ein ählich gelagertes Problem vorliegt.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@Spirit: Da muss klar irgendwas faul sein bei dir.
Mach uns doch ein abgespecktes Beispielprogramm (nur der Flanken-DB und ein Stückchen Code) das bei dir auf einer CPU nicht läuft und poste das mal hier.
Dann kommen wir dem Problem denke ich schneller auf die Spur.

Nebenbei...
Programmierst du das gerade einen FC der irgendeinen Antrieb steuern soll?
Wenn ich mir den Code (mit den direkten Zugriffen auf dein Steuer-IDB und die festen DB-Merker, welche keinen Deut besser sind als Standard-Merker) der nicht toll wiederverwendbar sein wird, anschaue... frage ich mich schon.

A) Darfst du keine FBs verwenden? (Instanz des Motion-Bausteins in den DB und auch die Flanken-Hilfswerte in FB rein....)
B) Welche Verbesserung erhoffst du dir vom Umbau von M10.0 auf DbMerker.M10[0]? :confused:
 
Zuletzt bearbeitet:
@Spirit: Da muss klar irgendwas faul sein bei dir.
Mach uns doch ein abgespecktes Beispielprogramm (nur der Flanken-DB und ein Stückchen Code) das bei dir auf einer CPU nicht läuft und poste das mal hier.
Dann kommen wir dem Problem denke ich schneller auf die Spur.

Nebenbei...
Programmierst du das gerade einen FC der irgendeinen Antrieb steuern soll?
Wenn ich mir den Code (mit den direkten Zugriffen auf dein Steuer-IDB und die festen DB-Merker, welche keinen Deut besser sind als Standard-Merker) der nicht toll wiederverwendbar sein wird, anschaue... frage ich mich schon.

A) Darfst du keine FBs verwenden? (Instanz des Motion-Bausteins in den DB und auch die Flanken-Hilfswerte in FB rein....)
B) Welche Verbesserung erhoffst du dir vom Umbau von M10.0 auf DbMerker.M10[0]? :confused:

ALSO, ich habe noch so eine Stelle gefunden, in der der Merkerbereich des DBs verunglimpflicht wurde ... jetzt funktioniert alles auch mit den DB-Merkern!

Ja RONIN, du hast Recht mit den FB's - aber der FC mit dem Antrieb ist nur ein "Probeaufbau" für ein späteres Projekt, um auszuloten, ob dieser in dieser Form eingesetzt werden kann. Normalerweise mache ich die Antriebe schon in einem FB.


Bezüglich deiner B) Frage:

Ich dachte, bzw. meine, mal irgendwo gelesen zu haben, dass die Verwendung von Merkern aus einem DB einen gewissen Geschwindigkeitsvorteil (bezüglich Zugriff) gegenüber Merkern aus der Standard-Variablentabelle haben; ist das Unsinn? :confused:
 
aber der FC mit dem Antrieb ist nur ein "Probeaufbau" für ein späteres Projekt, um auszuloten, ob dieser in dieser Form eingesetzt werden kann.
:confused:
Wieviel Sinn macht es denn, einen FC probeweise aufzubauen, den man später nicht verwenden kann, anstatt die gleiche Zeit in einen FB zu investieren und man ist mit dem Probeaufbau fertig, wenn's funktioniert?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
:confused:
Wieviel Sinn macht es denn, einen FC probeweise aufzubauen, den man später nicht verwenden kann, anstatt die gleiche Zeit in einen FB zu investieren und man ist mit dem Probeaufbau fertig, wenn's funktioniert?

Ok, ich sehe es ein und gelobe mich zu bessern! Großes Indianerinnenehrenwort! :p


Zum Abschluss: Bringen also Merker aus dem DB-Bereich bezüglich Zugriff gegenüber herkömmlichen Merkern Null Vorteile (Geschwindigkeit, usw.)? :confused:
 
Zum Abschluss: Bringen also Merker aus dem DB-Bereich bezüglich Zugriff gegenüber herkömmlichen Merkern Null Vorteile (Geschwindigkeit, usw.)? :confused:

Das weiss ich nicht. Aber sicher keinen Signifikanten. Ausserdem ist es in der heutigen Zeit so das schnellere Hardware fast immer günstiger ist als Manntage zu investieren bis das alles maximal schnell läuft aber auch nicht mehr lesbar ist. Das rächt sich später in der Wartung.

mfG René
 
Hi,

nur mal interessehalber:

Dein "DB_Merker".M10[5] ist auch ganz sicher ein Array?

Bzw. zeig mal deinen "DB_Merker".

Edit. Ok, Bilder sieht man nur wenn man sich einloggt...
 
Zuletzt bearbeitet:
Wenn das kein Array wäre. könnte man den Baustein nichtmal übersetzen, geschweigedenn runterladen.

Bei Symbolischer Adressierung wie hier kann man von vorhandenen Variablen ausgehen.

mfG René
 
Wahrscheinlich ist was mit den Adressregistern falsch gelaufen. Wenn die nicht wiederhergestellt werden, bevor auf statische Bits zugegriffen wird, dann gibt's Fehler.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wahrscheinlich ist was mit den Adressregistern falsch gelaufen. Wenn die nicht wiederhergestellt werden, bevor auf statische Bits zugegriffen wird, dann gibt's Fehler.
Der Grund der Programm-Fehlfunktion war, daß indirekte Adressierung über Adressregister programmiert wurde, aber zwischen dem Öffnen des Ziel-DB und dem teilqualifizierten Schreiben in den Ziel-DB durch das FP ein anderer DB geöffnet wurde, wodurch die Daten nicht im Ziel-DB ankamen, was als Fehlfunktion des FP fehlinterpretiert wurde.

PS: FC haben keine statischen Variablen und ein verbiegen der Adressregister stört nicht beim Zugriff auf die eigenen lokalen Variablen.

Harald
 
Zurück
Oben