Peripherie Eingänge auslesen

[Bertman]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

habe hier ein problem mit einer S7-400 Steuerung, die mit einem ABB AC600 Umrichter über Profibus kommuniziert.
Die Peripherie Ein- und Ausgänge (E/A >532) liegen oberhalb meines Prozessabildes (<= 256). Die Anlage läuft auch schon seit langem und kommuniziert auch mit dem Umrichter. Er wird über den Profibus gesteuert.
Nun brauch ich aber noch ein paar Werte die im Protokoll mit übertragen werden. Doch das Auslesen mit lade PEW xyz und tranferiere in DB x .DBW yz funktioniert nicht. ich bekommen keine Werte raus. Den Baustein in dem die Kommunikation mit dem Umrichter statt findet kann ich leider nicht öffnen , da er geschützt ist.

Was könnte ich tun bzw. was mach ich falsch ?

Habe bis jetzt nirgends dazu etwas gefunden.

Ist es möglich, das man die Peripherie Ein- und Ausgänge vor einem weiteren auslesen schützen kann ?

Gruß,
Bertman

 

[bike]

Bist du dir wegen der Adressen ganz sicher?
Wenn ja, würde ich einmal vor dem Aufruf des Kommunikationsbausteins ein laden versuchen.
Auch einmal die Adressen testen, die schon funktionieren, vielleicht stehen die zusätzlichen Daten nicht zur Verfügung?

bike

 

[Bertman]

Zuviel Werbung?
-> Hier kostenlos registrieren

Danke für die schnelle Antwort.

Mit der Adressvergabe bin ich mir recht sicher, da ich das (genau das) Programm vor drei Monaten in die Sps neu einspielen mußte.
Habe das laden der PEWs auch direkt im OB 1 probiert.
Irgendwas muss doch in den PEWs stehen. habe sie alle schon (probiert zu) (ge)laden (20bytes) - immer mit dem selben ergebnis -> 0.

Gruß,
Bertman

 

[bike]

Also ich vermute jetzt aus dem Stegreif, dass die Daten vielleicht nicht statisch sind?
Ich würde ein PEW prüfen ob es ungleich null ist und dann den Wert weg kopieren oder zum Test einfach einen Zähler hochzählen lassen, dann weisst du, dass sich etwas tut


bike

 

[Bertman]

Sind eigentlich statisch - sehe im instanzbaustein die Drehzahl die über den bus kommt. (falls du das meinst)

Hab eben festgestellt, das einen Sammelfehler an der SPS ausgelöst wird, wenn der Baustein aktiv ist hab nicht drauf geachtet. Weist also doch auf eine falsche adresse hin, was ja eigentlich nicht sein kann, da es das original programm ist und sich keiner weiter an der Software vergreift.

Hier nochmal der Fehler:
Ereignis ID 2942

Die gewünschten Daten konnten nicht von der Baugruppe gelesen werden:
· Die Baugruppe ist defekt, gezogen, oder der zugehörige Baugruppenträger ist ausgefallen

Behebung:
Baugruppe austauschen, stecken, oder zugehörigen Baugruppenträger in Betrieb nehmen.

· Die angegebene logische Adresse ist nicht korrekt, weil der Adresse keine Signalbaugruppe zugeordnet ist.
Behebung:
Die logische Adresse korrigieren

 

[Rainer Hönle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Vielleicht handelt es sich um ein Spezialprotokoll. D.h. es müssen erst Werte ausgegeben werden und der Umrichter antwortet dann da drauf. Eventuell auch mal (wenn die SPS in auch mal kurz Stop gesetzt werden darf) die Größe des Prozessabbildes in der Hardwarekonfig ändern.
Gibt es zu dem Umrichter keine Anleitung des Herstellers?

 

[Bertman]

Neuer Morgen, neues Glück...

Anleitung schon, aber werde aus ihr nicht schlau...

Habe es aber nun hinbekommen. Warum es so geht, versteh ich zwar nicht, aber Hauptsache die Werte sind da.

Hier mal der Code:

CALL SFC 14
LADDR :=W#16#214
RET_VAL:=DB70.DBW22
RECORD :=P#DB70.DBX0.0 BYTE 8

CALL SFC 14
LADDR :=W#16#21C
RET_VAL:=DB70.DBW22
RECORD :=P#DB70.DBX8.0 BYTE 12

Danke für die Denkanstöße...

 

[MarkusP210]

Warum es so geht, versteh ich zwar nicht

Wird daran gelegen haben, dass die Daten vom Umrichter konsistent (=zusammenhängend im gleichen Zyklus) gelesen werden müssen und das kann nur die SFC 14 bei Datenlängen von 3 oder >4 Byte.

 

[bike]

Zuviel Werbung?
-> Hier kostenlos registrieren

Neuer Morgen, neues Glück...

Anleitung schon, aber werde aus ihr nicht schlau...

Habe es aber nun hinbekommen. Warum es so geht, versteh ich zwar nicht, aber Hauptsache die Werte sind da.

Hier mal der Code:

CALL SFC 14
LADDR :=W#16#214
RET_VAL:=DB70.DBW22
RECORD :=P#DB70.DBX0.0 BYTE 8

CALL SFC 14
LADDR :=W#16#21C
RET_VAL:=DB70.DBW22
RECORD :=P#DB70.DBX8.0 BYTE 12

Danke für die Denkanstöße...

Also es wird 2 mal gelesen einmal von PEW 532 8 Byte die ab DB70.dbx0.0 abgelegt werden. Der 2. Auftrag liest von 540 12 Byte die in DB70.dbx8.0 abgelegt werden. Also sollte im DB 70 die Nahtstelle beschrieben sein.



bike


P.S: Aber, es gibt es gibt bei solchen Fragen, eine echte Wundertaste

 

[Panzerknacker]

Hallo,

Wird daran gelegen haben, dass die Daten vom Umrichter konsistent (=zusammenhängend im gleichen Zyklus) gelesen werden müssen und das kann nur die SFC 14 bei Datenlängen von 3 oder >4 Byte.

ich habe vor einigen Monaten einen ähnlichen Fehler beheben müssen.
Ging dabei um einen DP/DP-Koppler mit 20 Worten Konsistenz der zwischen einer neuen 414-2 und einer ca. 5 Jahre alten 416-2 hing.
Während in der 414-2 die Kommunikation mittels L PEW und T PAW funktionierte, geht es bei der alten 416-2 nur mit SFC14/15.

Gruß
Matthias