Problem mit Lokaldaten

Carsten81

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

ich habe ein mir völlig unklares Problem. Da ich eher Amateur
bin probiere ich es so gut es geht zu beschreiben.

CPU 317-2DP mit STEP7 5.4

Es geht um das ansprechen eine Indramat DKC03.3.... via Profibus.

Vom Grundaufbau

SFC14 Slavedaten lesen und in DB schreiben
Lokales Wort initialisieren

Antrieb bekommt den Sollwert einer Zielposition und fährt diese an.
Nach erreichen des Ziels fährt er zurück in die Startposition.

Die Werte werden über die Lokaldaten (DINT) Zielposition in den DB geschrieben.

Steht der Antrieb und soll seine Position beibehalten wird die Positionsvorgabe zurück genommen.

In diesem Augenblick wird die Sollposition im DB mit Werten unbekannter
herkunft überschrieben.

Ich habe keine Überschneidungen oder ähnliches gefunden.
Vor allem habe ich X andere Bausteine nach dem gleichen Schema
wo diese Problem nicht auftritt. Es befinden sich 11 DKC Antriebe im Programm.

Wenn ich die Lokaldaten ändere ändern sich auch diese Werte !?

Ich hoffe man kann verstehen was ich meine.

Gruß Carsten
 
Ich hoffe man kann verstehen was ich meine.

NICHT MAL ANSATZWEISE

was hast du für einen Baustein? einen FC? einen FB?
wie sind die Lokaldaten deklariert?
wie äußert sich das Problem? (bitte in worten und/oder bildern, die man versteht!)

der Baustein wird mehrmals aufgerufen? dann bitte Aufrufumgebung und, wenn möglich, auch CODE bereitstellen...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Also bei der Fehlerbeschreibung muss man (fast) zwangsweise an das Wörtchen "Temp" erinnern.

Die "Fehlerbeschreibung" würde jedenfalls dazu passen.

Lokaldaten(Temps) sind nur 1 Zyklus gültig.

Mfg
Manuel
 
Wie gesagt ... Amateur.

Also,

es ist ein FC

Lokaldaten Schnittstell --> TEMP

Die "Sollposition" aus den Lokaldaten wird bein Positioniervorgabe in den DB des Antrieb umgeladen.

Nochmal kurz: Sollange ich eine Zielpsotion Vorgebe ist alles in i.O. Gebe ich keine vor ändert sich der Wert im DB von der letzen Zielposition in einen Wert unbekannter herkunft. Nur dieser FC greift auf diesen DB zu.
 
@vl
Fehlerbeschreibung war jetzt ein wenig hochtrabend ...

@carsten
Klartext:
Temp-Variable nicht zugewiesen = zufälliger Wert, kann auch 10 mal funktionieren, und beim 11.ten mal nicht mehr,
ist wie erwähnt "Zufall" oder technisch gesprochen "undefiniert".

Mfg
Manuel
 
Ich Frage mal anders:

Wie kann es sein, das ein Wert welchen man einen DB schreibt sich nach
wegnahme des Freigabeeingangs des Transferbefehls einfach ändert ?
 
Ich Frage mal anders:

Wie kann es sein, das ein Wert welchen man einen DB schreibt sich nach
wegnahme des Freigabeeingangs des Transferbefehls einfach ändert ?

Du solltest nun mal das Stück Code posten, sonst versteht hier keiner, was du meinst. Ein Transferbefehle hat keinen Freigabeeingang, jedenfalls nicht in AWL, er ist auch nicht VKE-abhängig, kann aber umsprungen (ergo nicht ausgeführt) werden, wenn man ihn nicht arbeiten lassen will. Bei einem Move in FUP sieht das etwas anders aus. Aber bitte, der Code zur Anschauung wäre sinnvoll. Ansonsten haben ja die meisten Vorschreiber schon vermutet, daß es wohl ein Problem mit der nicht mehr im Baustein beschriebenen und dann zufälligen Temp-Var sein könnte.

PS: Aber der MOVE in FUP macht genau das, ein Umspringen des Tarnsferbefehls in AWL!
 
Zuletzt bearbeitet:
Hier die wesentlichen Teile


CALL "DPRD_DAT"
LADDR :=W#16#148
RET_VAL:=#return_SFC14
RECORD :=P#DB95.DBX0.0 BYTE 28
NOP 0

L 0
T LW 2


U(
U(
O #Freigabe
)
SPBNB _018
L #SOLLGESCHWINDIGKEIT
T DB95.DBD 46
SET
SAVE
CLR
_018: U BIE
)
SPBNB _019
L #SOLLPOSITION
T DB95.DBD 42
_019: NOP 0


L LW 2
T DB95.DBW 40

CALL "DPWR_DAT"
LADDR :=W#16#148
RECORD :=P#DB95.DBX28.0 BYTE 28
RET_VAL:=#return_SFC15
NOP 0
 
Die Freigabe kommt im Endeffekt durch eine Schrittkette.

Es wird von Position A aus gestartet zu Position B.

Ist B erreicht wird der Schritt weitergeschalter und A wieder angefahren und die Schrittkette gelöscht.

Aber anstelle auf A stehen zu bleiben ändert sich plötzlich der Positionssollwert im DB obwohl keine "Freigabe" da ist.
 
und der baustein wird, wenn ich das richtig verstanden habe, mehrfach aufgerufen - ich hab keine fragen mehr!

entferne die absoluten zugriffe in der funktion und ersetze sie durch schnittstellen-parameter und/oder arbeite mit FBs
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Bist du sicher, daß nicht einer der anderen FC auch auf DB95.DBD42 und 46 schreibt? Könnte ein Schreibfehler sein. In dem Moment, wo du deinen Wert nicht mehr schreibst, also umspringst, macht das ein vorhergehender Baustein. Sind alle deine Aufrufe von DB-Datenwörtern qualifiziert, also mit Angabe der DB-Nummer?
 
Ich habe alle anderen Bausteine nochmal geprüft ob ich versehentlich
in den Flaschen DB schreibe. Nichts gefunden.

@VL: wie gesagt, es Arbeiten 10 weitere Antriebe nach diesem Schema und funktionieren ohne Probleme.

Wieso ändert sich mein Flascher Wert wenn ich in den TEMP Variablen
einen "Dummy" DINT hinzufüge ?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich habe alle anderen Bausteine nochmal geprüft ob ich versehentlich
in den Flaschen DB schreibe. Nichts gefunden.

@VL: wie gesagt, es Arbeiten 10 weitere Antriebe nach diesem Schema und funktionieren ohne Probleme.

Wieso ändert sich mein Flascher Wert wenn ich in den TEMP Variablen
einen "Dummy" DINT hinzufüge ?

Alle Bausteine nutzen den Temp-Bereich und überschreiben jeweils die Temp-Daten der anderen Bausteine. Daher ist eine Temp in einem Baustein nur gültig, wenn sie vor dem Lesen auch mit einem sinnvollen Wert beschrieben wird. Macht man das nicht, ist der Wert zufällig und hängt einfach davon ab ob und wenn ja was ein vorher oder nachher aufgerufener Baustein in diesen Bereich zu seinen Zwecken hineingeschrieben hat.
 
Da bin ich noch mal.

Habe alle NW´s aus dem Baustein geschmissen.

Es gibt nur noch:

TEMP Lokaldaten

CALL "DPRD_DAT"
LADDR :=W#16#148
RET_VAL:=#return_SFC14
RECORD :=P#DB95.DBX0.0 BYTE 28
NOP 0


U "Eins"

bzw.

U "Null"

L 300
T DB95.DBD42


CALL "DPWR_DAT"
LADDR :=W#16#148
RECORD :=P#DB95.DBX28.0 BYTE 28
RET_VAL:=#return_SFC15
NOP 0


Liegt "Eins" an entspricht der Wert im DB 300. Warum auch nicht !?

Liegt "Null" an kommt ein willkürlicher Wert welcher sich mit ändern
der Lokaldaten auch ändert.

DB mit verschiedenen DB_NR probiert --> das gleiche

Alle anderen Antriebe nach dem gleichen Schema laufen. Auch gerade
im Moment.
 
Zurück
Oben