SFC15-Problem

Reto

Well-known member
Beiträge
158
Punkte Reaktionen
0
Zuviel Werbung?
->Hier kostenlos registrieren
Hallo zusammen

Ich Sitze hier wieder mal an einem Problem. Folgende Situation:
414-2DP CPU, an welcher drei SEW MoviDrive A angeschlossen sind (via ProfiBus).

Diese erhalten je 6 Datenworte mittels SFC15. Beim ersten funktioniert das auch tadellos ... die beiden weiteren erhalten jedoch nur die Datenworte 1-3, 4-6 gehen irgend wo verloren. Sie werden nicht mit 0 geschrieben, die bleiben einfach auf dem letzten Stand.

Ich hab die Kommunikation wie folgt gelöst:
Code:
CALL "DPWR_DAT" (
           LADDR                    := #Addr,
           RECORD                   := #PA,
           RET_VAL                  := #Returncode_SFC15);

      L     #Returncode_SFC15; 
      L     0; 
      <>I   ; 
      SPB   M001; 
      BEA   ;
PA ist ein Struct aus total 6 Daten-Worten (16 BOOL + DINT + 2x INT)

Gibt's hier irgend einen Fehler?

Danke im Voraus


PS: Noch ein paar Daten: DP-Adressen (50, 51, 52), Anfangs E-Adresse (512, 524, 536), Anfangs A-Adresse (512, 524, 536) ... jeweils die erste geht, die mittlere und die letzte geht nicht.
CPU: 6ES7 414-2XG03-0AB0
 
Zuletzt bearbeitet:

Simatiker

Well-known member
Beiträge
176
Punkte Reaktionen
30
Hallo,

was steht denn als Rückgabewert der Funktion?
#Record sollte als AnyZeiger angelegt werden.
Wichtig ist die HW Konfig. Da die SFC14/15 da nachschauen ob die Adresse und die Länge zusammenpassen. Soll heißen deine Umrichter müssen je 6 PDW in/out deklariert sein, aber nicht 3x2 o.ä. sondern 6. Hatte mal das Problem bei SEW Movitracs, die konnte man zusammen fassen ala 4x6 PDW oder je 6 PDW, nur bei letzteren funktionierte dann auch die SFC 14/15.

Sehe gerade dein #PA sind aber nur 5 worte!!!

Ansonsten mal mit L PEW & T PAW probieren!

Ich noch mal,

schau mal das die Adressen außerhalb jeglicher PAE,PAA sind. Ist ja bei ner 400er viel möglich.
 
Zuletzt bearbeitet:

Paul

Well-known member
Beiträge
929
Punkte Reaktionen
239
Zuviel Werbung?
->Hier kostenlos registrieren
Hallo
CALL "DPWR_DAT" (
LADDR := #Addr,
RECORD := #PA,
RET_VAL := #Returncode_SFC15);

L #Returncode_SFC15;
L 0;
<>I ;
SPB M001;
BEA ;
Wenn dein #Returncode_SFC15 "Null" ist beendest du deinen Baustein mit "BEA".
Kann es sein das deshalb die nachfolgenden SFC 15 Aufrufe nicht mehr bearbeitet werden?

MfG
Paul
 
OP
Reto

Reto

Well-known member
Beiträge
158
Punkte Reaktionen
0
Hallo ;)
was steht denn als Rückgabewert der Funktion?
Rückgabewert ist immer 0 (null).
#Record sollte als AnyZeiger angelegt werden.
#Record zeigt auf einen Struct, was ja einem AnyZeiger relativ nahe kommt. Der Struct besteht aus den oben beschriebenen BOOLs, DINTs und INTs (nur dass es 3x INT ist^^)

Wichtig ist die HW Konfig. Da die SFC14/15 da nachschauen ob die Adresse und die Länge zusammenpassen. Soll heißen deine Umrichter müssen je 6 PDW in/out deklariert sein, aber nicht 3x2 o.ä. sondern 6. Hatte mal das Problem bei SEW Movitracs, die konnte man zusammen fassen ala 4x6 PDW oder je 6 PDW, nur bei letzteren funktionierte dann auch die SFC 14/15.
Ja, das kenn ich ... ist dann aber, wenn man die Geräte via SBus und DFP21 ansteuert. Hier ist aber die DFP direkt im MoviDrive drinnen und wird auch direkt verwendet. In der HW-Config steht auch 6PD.
Sehe gerade dein #PA sind aber nur 5 worte!!!
Es sind 3xINT (schreiben sollte man können)
Ansonsten mal mit L PEW & T PAW probieren!
PAW wäre dann das 536er wenn das die HW-Adresse des Gerätes ist?
Ich noch mal,
schau mal das die Adressen außerhalb jeglicher PAE,PAA sind. Ist ja bei ner 400er viel möglich.
Wo genau schaue ich, welche PAE, PAA belegt sind?

Danke schonmal
 
OP
Reto

Reto

Well-known member
Beiträge
158
Punkte Reaktionen
0
Hallo Paul
Wenn dein #Returncode_SFC15 "Null" ist beendest du deinen Baustein mit "BEA".
Kann es sein das deshalb die nachfolgenden SFC 15 Aufrufe nicht mehr bearbeitet werden?
Danach kommt nur noch die Fehlerauswertung und keine weiteren SFC15's mehr.
Das Ganze ist in einem FB, der aus einem FC aufgerufen wird ... mit BEA sollte doch der FB beendet und im FC weitergefahren werden ... oder hab ich da was falsch verstanden?
 

Simatiker

Well-known member
Beiträge
176
Punkte Reaktionen
30
Hallo,

die Größe des Prozeßabbildes kannst du in der HW Konfig unter CPU -> Eigenschaften -> Zyklus/Taktmerker nachschauen. Hier sollte nicht mehr als 512 stehen. Dann kannst du unter Objekteigenschaften des DP Slaves bei Adressen kontrollieren das bei Prozeßabbild "--" steht. (das Feld ist dann auch gegraut)
Wenn "0" als Rückgabewert steht, bedeutet das ja eigentlich das die Funktion korrekt ausgeführt wurde.
Du kannst die ganze Kommunikation auch ohne SFC's machen. Dann halt mit:
Code:
Umrichter1:
L PED 512
T...
L PED 516
T...
L PED 520
T...
.
.
.
L...
T PAD 512
L...
T PAD 516
L...
T PAD 520

Nur um zu schauen ob überhaupt etwas geschrieben wird.
Dann könntest du mal Versuchen die E/A's der Umrichter ganz woanders hinzulegen. Vielleicht wird irgendwo in deinem Programm der Ausgangsbereich beschrieben, mittels Pointer oder Blockmove oder irgendwas!? Was du dann in den Referenzdaten nicht sehen könntest.
 
OP
Reto

Reto

Well-known member
Beiträge
158
Punkte Reaktionen
0
Blöde Frage:
Wenn du einen FB aus einer FC startest, wo speicherst du dann die Daten des FBs? Multiinstanz geht doch so nicht.
Der FC wird direkt aus OB1 aufgerufen und verwendet intern Absolute Adressen. Zum FB gehört natürlich ein iDB, welcher fest beziffert wird.
 
OP
Reto

Reto

Well-known member
Beiträge
158
Punkte Reaktionen
0
Zuviel Werbung?
->Hier kostenlos registrieren
Hallo,
die Größe des Prozeßabbildes kannst du in der HW Konfig unter CPU -> Eigenschaften -> Zyklus/Taktmerker nachschauen. Hier sollte nicht mehr als 512 stehen.
Da steht je 512 drinnen; passt also.

Dann kannst du unter Objekteigenschaften des DP Slaves bei Adressen kontrollieren das bei Prozeßabbild "--" steht. (das Feld ist dann auch gegraut)
Steht beide male "---" und ist ausgegraut. Die Adresse steht je auf 536-547.

Wenn "0" als Rückgabewert steht, bedeutet das ja eigentlich das die Funktion korrekt ausgeführt wurde.
Das dachte ich eben auch ;)

Nur um zu schauen ob überhaupt etwas geschrieben wird.
Dann könntest du mal Versuchen die E/A's der Umrichter ganz woanders hinzulegen. Vielleicht wird irgendwo in deinem Programm der Ausgangsbereich beschrieben, mittels Pointer oder Blockmove oder irgendwas!? Was du dann in den Referenzdaten nicht sehen könntest.
Mein Programm besteht aktuell aus dem OB1, der den FC aufruft, der gerade nichts anderes macht, als meinen FB für's MoviDrive aufzurufen.
Alle andern OBs sind entweder von der CPU runter oder leer.

Ich komme leider erst am Freitag wieder an die Anlage drann, werde dann aber diese guten Hinweise testen.
Danke euch allen.
 

dtsclipper

Well-known member
Beiträge
945
Punkte Reaktionen
219
Noch 'ne Rückfage:

In der Variabe #PA stehe bei den Movidrives 2 und 3 die richtigen Daten drin ?

Werdebn deren Adressbereiche zufällig irgendwo in OB6x (Taktsynchronität) verwendet? dann spielt der 15er nicht mit...

Ansonsten rate ich zum Vorgehen a la Simatiker...
L ...
T ...
geht oft und man zuschauen was wohin transfriert wird.

Hatte mit einem MDX61B ähnliche Probleme, seitdem läuft er wie o.A.

... und läuft und läuft und läuft ...

viel glück wünscht dtsclipper
 
OP
Reto

Reto

Well-known member
Beiträge
158
Punkte Reaktionen
0
In der Variabe #PA stehe bei den Movidrives 2 und 3 die richtigen Daten drin ?
Ja, die stimmen (zumindest zeigt der Simatic-Manager was schlaues an ;)

Werdebn deren Adressbereiche zufällig irgendwo in OB6x (Taktsynchronität) verwendet? dann spielt der 15er nicht mit...
Wie oben geschrieben besteht das Programm atm aus dem OB1, dem aufrufenden FC und diesem FB ... es gibt keine andern OBs oder dergleichen, die irgend etwas verwursteln könnten.


Zur Variante von Simatiker:

Wenn ich dort mit T PAD536 (z.B.) arbeite ... dann muss ich ja die Adresse fest vergeben in etwa so:
Code:
// PA zurück zum MoviDrive schreiben

// Steuerwort 2
      L     LD    12
      T     PAD  536
// Zielposition
      L     LD    14
      T     PAD  538
      L     LD    16
      T     PAD  540

// Speed
      L     LD    18
      T     PAD  542

// Start-Rampe
      L     LD    20
      T     PAD  544

// Stop-Rampe
      L     LD    22
      T     PAD  546

Wie mach ich das nun, wenn ich die Start-Adresse (also das 536) in einer INPUT-INT-Variable übergeben möchte? Das müsste irgend wie mit einem Pointer gehen; nur bin ich mir da nie so sicher, wie das geht ;P

Danke im Voraus
 

Gebs

Well-known member
Beiträge
846
Punkte Reaktionen
245
Zuviel Werbung?
->Hier kostenlos registrieren
Hallo Reto,

ich hoffe ich hab' Dich richtig verstanden.
Dann würde ich das so lösen:
Code:
L #Start_Adresse    // Int z.b. 536
SLD 3                   // Pointer bilden
LAR1                    // Im Adressregister 1 ablegen

L LW 12               // Steuerwort2
T PAW[AR1,P#0.0]

L LD 14               // Zielposition
T PAD[AR1,P#2.0]

L LW 18              // Speed
T PAW[AR1,P#6.0]

L LW 20              // Startrampe
T PAW[AR1,P#8.0]

L LW 22              // Stoprampe
T PAW[AR1,P#10.0]
Grüße
Gebs
 
OP
Reto

Reto

Well-known member
Beiträge
158
Punkte Reaktionen
0
Hallo Gebs

Ja genau, du hast mich recht verstanden.
Warum genau machst du das SLD 3 ?

SLD ist doch das Schieben der Adresse also meine 536 um 3 Bit nach links ... daraus gäbe es dann also 4022 ???
 

dtsclipper

Well-known member
Beiträge
945
Punkte Reaktionen
219
Nee das ist schon richtig.

Die letzten drei Bits bei der Adressierung sind die BIT-Adresse.
Deswegen wird die INT-Zahl um 3 nach links geschoben, dann gibt das die Byte- Adresse.

Schau, nur Sicherheitshalber, mal in die CPU ( ONLINE-Bausteinordner ) vielleicht sind da noch andere Sachen drin als nur Deine ?!?
 
Zuletzt bearbeitet:

Gebs

Well-known member
Beiträge
846
Punkte Reaktionen
245
Zuviel Werbung?
->Hier kostenlos registrieren
Hallo Reto,

das SLD 3 mache ich, weil in einem Pointer die 3 Bits ganz rechts für die Adressierung von Bitadressen benötigt wird.

z.Bsp:
Code:
L 20    // Byteadresse
SLD3   // Byteadresse nach links schieben

L 1     // Bitadresse
OW    // Byteadresse und Bitadresse verküpfen
LAR1   // Ins Adressregister Hier steht jetzt P#20.1
Grüße
Gebs
 

Larry Laffer

Supermoderator
Teammitglied
Beiträge
13.092
Punkte Reaktionen
2.719
... was mir dazu noch so einfällt (aufgrund des Beitrages #11 von Reto) :
Kommen die Daten für die Perepherie (Kopplung der SEW's) aus dem Lokalbereich des FC's und landen die Rückmeldungen auch dort ? Wenn ja, wie ist da gemacht ? Ich vermute (gelinde gesagt) dort auch noch so ein oder zwei kleine Problemchen ...

@Reto:
Stellt doch mal den kompletten Baustein hier ein ...

Gruß
LL
 

tim_taylor

Active member
Beiträge
43
Punkte Reaktionen
6
Ld

Grüß Gott zusammen,

Stimmt das mit dem LD der Offset ist doch dann 4 wenn ich keine Datenüberschreitung möchte.

Code:
// PA zurück zum MoviDrive schreiben

// Steuerwort 2
      L     LD    12
      T     PAD  536
// Zielposition
      L     LD    14
      T     PAD  538
      L     LD    16
      T     PAD  540

// Speed
      L     LD    18
      T     PAD  542

// Start-Rampe
      L     LD    20
      T     PAD  544

// Stop-Rampe
      L     LD    22
      T     PAD  546
// PA zurück zum MoviDrive schreiben


Code:
// PA zurück zum MoviDrive schreiben

// Steuerwort 2
      L     LD    [COLOR=Red]12[/COLOR]
      T     PAD  [COLOR=Red]536[/COLOR]
// Zielposition
      L     LD    [COLOR=Red]16[/COLOR]
      T     PAD  [COLOR=Red]540[/COLOR]
      L     LD    [COLOR=Red]20[/COLOR]
      T     PAD  [COLOR=Red]544[/COLOR]

// Speed
      L     LD    [COLOR=Red]24[/COLOR]
      T     PAD  [COLOR=Red]548[/COLOR]

// Start-Rampe
      L     LD    [COLOR=Red]28[/COLOR]
      T     PAD  [COLOR=Red]562[/COLOR]

// Stop-Rampe
      L     LD    [COLOR=Red]32[/COLOR]
      T     PAD  [COLOR=Red]566[/COLOR]
Vielleicht liegt es daran.

Schönen Tag dann noch
 
Oben