# Todes-Schleife...



## Hawkster (31 März 2009)

Hallo allesamt...

ich bin mit meinem Latein am Ende.
Hab hier ne Anlage mit ner CPU 317 und einer derzeitigen Durchschnittszykluszeit von 45ms (schon viel, kommt auch schon bald die 319 :s6

So... da ist das Prachtstück...


```
L     0
      T     #LK_Temp.Zaehler

LP01: NOP   0
//==> Aktion Start


//==> Aktion Ende

      L     #LK_Temp.Zaehler
      L     1
      +I    
      T     #LK_Temp.Zaehler

      U(    
      L     100
      L     #LK_Temp.Zaehler
      <=I   
      )     
      SPB   LE01
      SPA   LP01

LE01: NOP   0
//FERTIG :D
```

Ich kann diese Schleife Online Problemlos anschauen. Zykluszeit schwankt bei den Normalen +/- 1 MS.

So, Schleife vorgefertigt, dem Kollegen gegeben (genauso wie oben), er testet und was passiert beim Klick auf die tolle Brille -> PIFF, CPU-Stop, Kunde schreit... 
Ok... ich leicht irritiert frag warum er die CPU stoppt er Achselzuckend "Ich wars net"... 

Zum seinem Rechner, geschaut... schleife so wie vorher. Auf ein neues.... Beobachen beendet, ins Run geschaltet und alles Super... dann der Klick auf die Brille und PIFF, CPU-Stop, Kunde schreit schon lauter...

Ok... SPS Welt kurz vorm Zusammenbrechen hab ich mich daran festgehalten das einfach seine Software ne Macke hat...

Zum 2. Kollegen -> Brille angeklickt -> PIFF, CPU-Stop, Kunde schreit !"§$%&/()=

Zum 3. Kollegen ->  Brille angeklickt -> PIFF, CPU-Stop, Kunde schreit (kann man nicht mal mehr in Sonderzeichen fassen)

Zum 4. Kollegen ->  Brille angeklickt -> Jaa... genau das gleiche wie bei denen davor...

Ok... mein Rechner... Online gegangen... läuft, Zykluszeit normal... SPS-Welt schon so ziemlich am Boden zerstört....

Nun eine Frage... könntet Ihr diese Schleife (statt der Temp könnt ihr auch nen MW nehmen (haben wir auch schon getestet, hilft au nix) bei euch mal testen wie sich die Zykluszeit vor dem Beobachten und nach dem Beobachten verhalten hat (also die Max-Werte)...

Soo... ich geh jetzt mit Pipi in den Augen zu Bett.

Mit freundlichen Grüßen,
Hawkster


----------



## crash (31 März 2009)

Warum geht die CPU in STOP?
Was steht im Diagnosepuffer der CPU?


----------



## Ralle (31 März 2009)

Ich habe hier schon einmal irgendwo gelesen, daß, wenn man mit dem Cursor in einer Schleife steht und auf beobachten geht, die Zykluszeit enorm ansteigen kann.


----------



## Kai (31 März 2009)

Läuf die CPU im Test- oder im Prozessbetrieb? 



> *Unterschied zwischen Test- und Prozessbetrieb (Auszug aus der Online-Hilfe von STEP 7)*
> 
> Im *Prozessbetrieb* werden die Testfunktionen wie Programmstatus oder Variable beobachten/steuern so eingeschränkt, dass die eingestellte zulässige Zykluszeiterhöhung nicht überschritten wird. Das Testen mit Haltepunkten und die schrittweise Programmausführung können nicht ausgeführt werden.
> 
> Im *Testbetrieb* sind alle Testfunktionen über PG/PC ohne Einschränkung nutzbar, die auch größere Verlängerungen der Zykluszeit bewirken können. Wenn sich die CPU im Testbetrieb befindet, müssen Sie dafür sorgen, dass die CPU bzw. der Prozess große Zykluszeitverlängerungen "vertragen" kann. In diesem Modus können Verlängerungen der CPU-Zykluszeiten auftreten, da z. B. der Status von Anweisungen in programmierten Schleifen bei jedem Durchlauf ermittelt wird.


 
ID22727341 Warum soll nach der Inbetriebnahme des STEP 7 Programms die Betriebsart der CPU von Test- auf Prozessbetrieb umgeschaltet werden?

Gruß Kai


----------



## talentfrei (31 März 2009)

Hi!

Hast du schon mal überprüft wie deine Einstellungen sind bezüglich Prozessbetrieb und Testbetrieb!?

Gruß talentfrei

edit: Ah, zu langsam! Kai war schneller!


----------



## Imudo (31 März 2009)

Hi,

kann es sein dass die Schleife ab 100 eine Endlosschleife ist bzw. die Sprungmarken vertauscht sind ?

Gruß Imudo


----------



## Hawkster (31 März 2009)

Diagnosepuffer -> Zykluszeitüberschreitung

CPU ist im Testbetrieb.

Schön und gut, wieso gehts bei mir, und bei keinem anderen?


----------



## talentfrei (31 März 2009)

Hm, ich weis nicht ob die Schnittstellen da auch mit reinspielen können?!


----------



## Hawkster (31 März 2009)

Also wir verbinden via TCP/IP (bedingt durch die Anzahl der Steuerungen)... haben aber auch schon mit einem Baugleichen Laptop versucht ob es anders ist... der bekommt auch den CPU-Stop hin


----------



## D E N Y S (31 März 2009)

wir gehen übers wlan online...das wird es aber leider wohl nicht sein den 3mal defekte hardware wäre auch iwo komisch

edit: zu langsam ;P drecks hotel-wlan -.-

achja der cpu-stop tritt auch schon ein sowie mal weit oberhalb der schleife nur in das netzwerk klickt...nochnichtmal direkt die schleife beobachtet ...


----------



## Hagen (31 März 2009)

Hallo Hawkster,

habt ihr schon die Programmversionen von STEP7 verglichen?

Gruss Hagen


----------



## Hawkster (31 März 2009)

Alles Wesentliche Identisch... also bezogen auf die Step7... v5.4 + SP3 + HF1/ K5.4.3.1


----------



## Ralle (31 März 2009)

Ihr könntet mal die Zyklusüberwachungszeit der SPS richtig hochsetzen. Dann nach dem Online-gehen jeweils die Zykluszeit ansehen (wird ja auch die größte angezeigt). Dann kann man vielleicht erstmal sehen, welchen Einfluß wer genau hat und ob die anderen Rechner alle die selbe Zykluszeiterhöhung verursachen. Was habt ihr für Einstellungen am Simatic-Arbeitsplatz, ist da einer der Chef? Ich hab das zwar noch nie ganz geschnallt was das bringt, aber wenn ihr zu dritt oder viert am Projekt arbeitet, wer weiß. Wo liegt das Projekt, bei dir oder auf einem Server? Wer war zuerst Online, du? Könnte unter Umständen auch ne Rolle spielen. Ist sicher ne Menge Probieren und Raten dabei um hier irgend etwas heraus zu bekommen.


----------



## Hawkster (31 März 2009)

Also, wir haben sie ma Testweise bei einem Kollegen hochgenommen. Die Zykluszeit hat 200ms erreicht. Was bei anderen passiert haben wir leider noch nicht getestet...

Also mein Arbeitsplatz ist definitiv auf Einzelplatz gestellt. Dennis, wie ist deiner Eingestellt? Systemsteuerung -> Simatic Irgendwas.

Nein, Arbeiten immer alleine an einer SPS.

PS: Triggerereigniss belegt (gibts da nen trick?)


----------



## D E N Y S (31 März 2009)

mhh bei mir stehts auf mehrplatz ...bin mal gespannt obs nen unteschied macht wenn ichs umstelle

hehe laut simulator scheints jetzt zu gehn...bin mal morgen früh gespannt


----------



## Hawkster (31 März 2009)

Mach die Simulation auf dann weiste es doch...
Selbst die Simulation hats auf 30ms gehaun. Ich test ma bei mir damit ich die MS weiß.

Dennis, Ohne F-Call und ohne Anwenderprog!


----------



## Zottel (31 März 2009)

Ich bin gerade unsicher wegen der Syntax:
Was soll:
    #LK_Temp.Zaehler
sein?
1. Ein Element aus einem UDT im Lokaldatenbereich
2. Ein Element aus einem #LK_Temp adressierten Datenbaustein?

Und wozu braucht ihr die Schleife? Steht da auch was Produktives im Schleifenrumpf?
Wenn ja, tut es nötig das in einer Schleife zu machen?
Oder könnte man auch pro Zyklus einen (oder 3 oder 5) Schritte der Schleife berechnen?
Wenn dann nach 100, 33 oder 20 Zyklen das Ergebnis vorliegt, kann man  ja einen Merker setzen, der dem Rest des Programms sagt, daß nun ein neues Eergebnis vorliegt...


----------



## Hawkster (31 März 2009)

Zeiten Offline:
Min -> 10
Durchschnitt -> 11-13
Max -> 23

Zeiten Online:
Min -> 10
Durchschnitt -> 11-13
Max -> 23

Werte sind somit unverändert...


----------



## D E N Y S (31 März 2009)

ok hab jetz en bissel gewartet und bin über die schleife gegangen...

erst isser stabil bei seinen 15ms geblieben nur ob1 + schleife ...und beim beobachten der schleife is er erst auch in dem bereich geblieben ...aber am end bin ich doch wieder bei 24ms gelandet -.-


hrhr ich warte mal auf morgen ....

edit: auch auf mehrplatz hab ich die zykluszeit +1ms ...heut mittag waren wir noch bei 30ms


----------



## Hawkster (31 März 2009)

Der Baustein ist ein FC.

Der LK_Temp ist eine Struktur im Temp-Bereich vom Baustein. Und in dieser Struktur ist der "Zaehler" hinterlegt.

Ja, die Schleife ist dringenst nötig  Weil da auch was sinnvolles drinsteht. ist zwar derzeit draußen (da wir das Problem analysieren).

Ja, Zottel. Deines wäre ein WOrk-Around und ist nicht die Lösung meines Problems. Schleifen gehen. Und ich habs auch schon oft genug verwendet und beobachtet. In viel viel komplexeren Prozessen... deswegen bin ich irritiert das eine 100 Durchgangs-Schleife (was ein Witz) so Probleme verursacht...

MFG
Hawkster


----------



## bike (31 März 2009)

Die Software ist nach deiner Aussage die selbe, gilt das auch für die Hardware?
Also ich meine CP UND Kabel?
Ist ein Profibus dran? Kann es sein, dass der dir die Zykluszeit hochtreibt?
Ich habe dies zur Zeit bei einigen Anlagen, die mit Bussteckern ausgestattet sind, die LED für Betrieb und Fehler haben. Sobald ich mit dem Kabel auf Profibus stecke werden Fehler angezeigt, die auch zum Absturz wegen Zykluszeit führen 

Bist du auf Profibus Anschluss oder am MPI?

bike


----------



## Hawkster (31 März 2009)

Versteh grad nicht was du sagen willst.

Verbinden tun wir via CP-343 (TCP/IP).

Am MPI hängt das OP sonst nix.
Am Profibus geschätzt... 80-90 Teilnehmer. Was dennoch net erklärt warums bei mir geht und bei anderen net.

Die Theorie mit dem Mehrplatzsystem steht zwar im Raum... hängt aber vom logischen meinerseits nicht mal ansatzweise in verbindung...


----------



## SPSKILLER (31 März 2009)

Hallo,

für mich sieht das aus, als ob das Problem vor der Schleife ist.
Mich macht die Klammer stutzig...
Schreib mal oben "CLR" dran.

Dann müsste das laufen 

Micha



Hawkster schrieb:


> ```
> L     0
> T     #LK_Temp.Zaehler
> 
> ...


----------



## D E N Y S (31 März 2009)

uns geht es nicht um die funktion der schleife sondern darum, warum wir an 4 von 5 pcs beim beobachten einen zykluszeitensprung von 70ms auf rund 190ms bekommen


----------



## tonga (31 März 2009)

> U(
> L     100
> L     #LK_Temp.Zaehler
> <=I
> )


versteh ich eh nicht , wozu brauchst du das U?
Gehe ich richtig in der Annahme das Du Deine Aktion 100mal ausführst, dann wieder russ?
Probier doch mal nen LOOP , wäre ne Alternative um zu schauen obs da auch passiert...


----------



## Hawkster (31 März 2009)

Klammer? Welche Klammer?! Du meinst die u(l l <=I)SPB?


----------



## Hawkster (31 März 2009)

Loop nutz ich net  Nicht flexibel genug der Rotz befehl 
Is genauson Befehl wie "INC", "DEC" usw. Befehle wos gibt aber man einfach nicht benutzt 

Ja, 100x durch und raus 

Das u( ) mach ich aus Schönheit. Ob mit oder Ohne ist unrelevant.



tonga schrieb:


> versteh ich eh nicht , wozu brauchst du das U?
> Gehe ich richtig in der Annahme das Du Deine Aktion 100mal ausführst, dann wieder russ?
> Probier doch mal nen LOOP , wäre ne Alternative um zu schauen obs da auch passiert...


----------



## tonga (31 März 2009)

Wofür die UND Verknüpfung?


----------



## SPSKILLER (31 März 2009)

ja, lass die weg, oder mach mal ein clr davor.
dein spb wird sonst bei 100 nicht unbedingt ausgeführt 
(kommt drauf an was vor der Schleife steht)

Micha


----------



## tonga (31 März 2009)

> Loop nutz ich net :smile: Nicht flexibel genug der Rotz befehl :smile:


Versteh zwar nicht was Deine Variante grad flexibler macht , aber ist auch Geschmackssache...

Da ja alle PCs "identisch" sind frag ich mich nur wo da das Problem sein soll...


----------



## Hawkster (31 März 2009)

Daran liegt es nicht... 
Aber dennoch du hast recht... blos ist das nicht immer in SPSen so? Ich mein wenn du irgendwo mit u() beginnst, musste auch irgendwo dein VKE "verschießen" 



SPSKILLER schrieb:


> ja, lass die weg, oder mach mal ein clr davor.
> dein spb wird sonst bei 100 nicht unbedingt ausgeführt
> (kommt drauf an was vor der Schleife steht)
> 
> Micha


----------



## Hawkster (31 März 2009)

Naja, ich kann den Schleifenzaehler schlecht manipulieren (vllt nen bestimmten Punkt überspringen oder so), ich kann die Aussprungbedingung im Fall der Fälle schlecht neu definieren.... deswegen... vielleicht möchte ich auch statt 1 immer 2 weiter zaehlen... das ist mit loop irgendwie möglich... aber da nehm ich lieber meins, sind 3 Zeilen mehr bin aber in alle richtungen offen 



tonga schrieb:


> Versteh zwar nicht was Deine Variante grad flexibler macht , aber ist auch Geschmackssache...
> 
> Da ja alle PCs "identisch" sind frag ich mich nur wo da das Problem sein soll...


----------



## SPSKILLER (31 März 2009)

hast du es ausprobiert???

Das "U(" gehört da auf jeden Fall nicht hin, ist sogar falsch!

Wenn vor der Schleife so was wie z.B.

```
U e100.0
//=M100.0 auskommentiert zu Testzwecken
```
 
stehen würde hälst du deine SPS an, da du solange in der Schleife bleibst,
bis E100.0 TRUE wird...

Anders kann ich mir dein Problem nicht erklären.

Micha


----------



## Hawkster (31 März 2009)

Ja, deine Theorie hatten wir schon auf der Baustelle gell Dennis.

Gut, das Problem ist bei deiner Lösung, was machste bei sowas:


```
U e100.0
//=M100.0 auskommentiert zu Testzwecken

U e100.2
= M100.3 //Mach was mega wichtiges
```
Da denk ich ist meines Doch noch sehr Sicher im gegenzug zu deinem


----------



## SPSKILLER (31 März 2009)

mein Beispiel sollte zeigen, warum das "U(" *weg muss*. 

Falls jemand durch Auskommentieren, oder was auch immer ein
VKE ohne Zuweisung über der Schleife stehen lässt, dann geht deine CPU in STOP !!!!


----------



## bike (31 März 2009)

Hawkster schrieb:


> Am MPI hängt das OP sonst nix.
> Am Profibus geschätzt... 80-90 Teilnehmer. Was dennoch net erklärt warums bei mir geht und bei anderen net.



Die Frage war ob die selbe Hardware verwendet wird?(Kabel und CP)
Und schon einmal versucht mit MPI die Schleife zu kontrollierren?

Denn wie schon erwähnt, habe ich zur Zeit Probleme mit Programmieren über Profibus und Zykluszeit.


bike


----------



## Zottel (31 März 2009)

Hawkster schrieb:


> ... blos ist das nicht immer in SPSen so?
> Ich mein wenn du irgendwo mit u() beginnst, musste auch irgendwo dein VKE "verschießen"


Nein, nach bestimmten Operationen (z.B. =, zumindest früher hießen die im Siemens-Jargon "VKE-begrenzend") wird ein zusätzliches Flag im Statuswort gesetzt, das bedeutet, die nächste Anweisung ist eine "erstabfrage" und der Operand wird ins VKE geladen anstatt mit diesem Verknüpft.

CoDeSys oder S7-200 sind da "logischer", da muß die neue Reihe mit einer Ladeanweisung (LD) anfangen...


----------



## Hawkster (31 März 2009)

Bike, gehen alle über WLAN auf die Steuerungen.
Das mim MPI wollte ich noch testen  Nur nebenher muss man ja noch der Arbeit nachgehen.

Gut, ok, wenn ich davor irgendwas blöd mach, muss man zugeben, gehts in Stop. Aber unter welcher Bedingung komm ich mit nem falschen VKE dahin? Außer wenn ich das eintippe was du da grad vorschlägst 
Ist ja auch egal Mensch, hier gehts um die Schleife und net um "Wie-Programmiere-Ich-S7-Ganz-Toll-Mit-Permanent-CLR-Anweisung-Damit-VKE-Immer-Richtig-Ist" 

Ist ja auch wurscht. Die CPU geht net ins Stop deswegen, habe ja schon MW hochzählen lassen und der kommt immer maximal bis 100 (Unbeobachtet) 
Beobachtet halt irgendwo zwischen 10 und 99


----------



## bike (31 März 2009)

SPSKILLER schrieb:


> mein Beispiel sollte zeigen, warum das "U(" *weg muss*.
> 
> Falls jemand durch Auskommentieren, oder was auch immer ein
> VKE ohne Zuweisung über der Schleife stehen lässt, dann geht deine CPU in STOP !!!!


Wenn zuvor eine Zuweisung erfolgt ist, ist doch das u( eine Erstabfrage, daher ist es doch unerheblich was zuvor war, oder?

Ich würde ggF ein CLR reinschreiben, dann ist VKE definiert immer 0
Doch erklärt dies nicht, warum beim einen die PLC in Stop geht und beim anderen nicht, das VKE ist doch nicht abhängig vom PC, der zum Debbugen der verwendet wird.


bike.


----------



## Zottel (31 März 2009)

```
L     0
      T     #LK_Temp.Zaehler

LP01: NOP   0
//==> Aktion Start


//==> Aktion Ende

      L     #LK_Temp.Zaehler
      L     1
      +I    
      T     #LK_Temp.Zaehler

      U(    
      L     100
      L     #LK_Temp.Zaehler
      <=I   
      )     
      SPB   LE01
      SPA   LP01

LE01: NOP   0
//FERTIG :D
```

In diesem Fall führt ein beim Eintritt in die Schleife gelöschtes VKE dazu, daß der Sprung zu LE01 nie ausgeführt wird.
Wenn du die Bedingung umdrehst und den bedingten Sprung zum Anfang der Schleife machst, würde sie nach einem Durchlauf abgebrochen...


```
L     0
      T     #LK_Temp.Zaehler

LP01: NOP   0
//==> Aktion Start


//==> Aktion Ende

      L     #LK_Temp.Zaehler
      L     1
      +I    
      T     #LK_Temp.Zaehler

      U(    
      L     100
      L     #LK_Temp.Zaehler
      >I  
      )     
      SPB   LP01

LE01: NOP   0
//FERTIG :D
```


----------



## Thomas_v2.1 (31 März 2009)

Hawkster schrieb:


> Is genauson Befehl wie "INC", "DEC" usw. Befehle wos gibt aber man einfach nicht benutzt



Nur dass die Befehle nicht zum Spaß drin sind.
Zeitvergleich (CPU 317):

L 1 // 0,05 µs
+I // 0,2 µs

INC 1 // 0,1 µs

Bei deiner 100er Schleife sind das 25 µs zu 10 µs.

Ansonsten schau ich auch nicht so auf die Ausführungszeit, aber bei Schleifen ist das schon sinnvoll.


----------



## SPSKILLER (31 März 2009)

Zottel schrieb:


> ```
> L     0
> T     #LK_Temp.Zaehler
> 
> ...


 
@Zottel: Mit Verlaub, aber das ist Blödsinn.

@Hawkster: Kannst du mal noch die "Aktion" posten?


----------



## Hawkster (31 März 2009)

Ich kanns jetzt net testen, aber für dich mach ich morgen mal das U( ) raus. Das erklärt dennoch nicht, warums bei mir geht wenn ichs anschau, und bei anderen net...

Und dies ist nicht der Fehler weil das MW (mit dem wirs schon getestet haben) nie über die 100 kommt  Und das er die Zusätzlich benötigten 65535 Zyklen durchführt, von denen Zufällig die Restlichen 32668 Zyklen (bei 32768 kommt ja Überschlag) das VKE 0 ist, um nicht rauszuspringen, ist unwahrscheinlich 

Also ist das Prob wo anders


----------



## Hawkster (31 März 2009)

Ok... nun mal der Komplette Code (welcher Derzeit nicht drin ist).
Also ich nehm mal das komplette NW


```
NOP   0
//#############################################################
//### Konfigurationen beschreiben
//#############################################################        
      L     100
      T     #LK_Temp.CNF_Schleifen_Anzahl

      L     23                          //0-23 (array)
      T     #LK_Temp.CNF_Leistungsklasse_Max

//#############################################################
//### Ablöschen der aktuellen Werte der Leistungsklassen
//#############################################################        
      L     0
      T     "DB_DH_Speicher_1".Leistungsklasse[1]
      T     "DB_DH_Speicher_1".Leistungsklasse[2]
      T     "DB_DH_Speicher_1".Leistungsklasse[3]
      T     "DB_DH_Speicher_1".Leistungsklasse[4]
      T     "DB_DH_Speicher_1".Leistungsklasse[5]
      T     "DB_DH_Speicher_1".Leistungsklasse[6]
      T     "DB_DH_Speicher_1".Leistungsklasse[7]
      T     "DB_DH_Speicher_1".Leistungsklasse[8]
      T     "DB_DH_Speicher_1".Leistungsklasse[9]
      T     "DB_DH_Speicher_1".Leistungsklasse[10]
      T     "DB_DH_Speicher_1".Leistungsklasse[11]
      T     "DB_DH_Speicher_1".Leistungsklasse[12]
      T     "DB_DH_Speicher_1".Leistungsklasse[13]
      T     "DB_DH_Speicher_1".Leistungsklasse[14]
      T     "DB_DH_Speicher_1".Leistungsklasse[15]
      T     "DB_DH_Speicher_1".Leistungsklasse[16]
      T     "DB_DH_Speicher_1".Leistungsklasse[17]
      T     "DB_DH_Speicher_1".Leistungsklasse[18]
      T     "DB_DH_Speicher_1".Leistungsklasse[19]
      T     "DB_DH_Speicher_1".Leistungsklasse[20]
      T     "DB_DH_Speicher_1".Leistungsklasse[21]
      T     "DB_DH_Speicher_1".Leistungsklasse[22]
      T     "DB_DH_Speicher_1".Leistungsklasse[23]
      T     "DB_DH_Speicher_1".Leistungsklasse[24]
      T     "DB_DH_Speicher_1".Leistungsklasse[25]

//#############################################################
//### Schleife 
//#############################################################        
      L     0
      T     #LK_Temp.Zaehler
      T     #LK_Temp.PTR_SRC_Leistungsklasse
      T     #LK_Temp.PTR_DEST_Leistungsklasse
      T     #LK_Temp.Leistungsklasse


LP01: NOP   0
//#############################################################
//### Aktion Start
//#############################################################        
//==> Pointer der Leistungsklassen-Quelle
      L     #LK_Temp.Zaehler
      L     50                          //<== Sprungweite
      *I    
      L     140                         //<== Start-Wert
      +I    
      L     P#1.0
      *D    
      T     #LK_Temp.PTR_SRC_Leistungsklasse

//==> Kopieren der Leistungsklasse in Temp-Var
      AUF   "DB_DH_Speicher_1"
      L     DBW [#LK_Temp.PTR_SRC_Leistungsklasse]
      T     #LK_Temp.Leistungsklasse

//==> Leistungsklasse im Toleranz-Bereich
      U(    
      L     0
      L     #LK_Temp.Leistungsklasse
      <=I   
      )     
      U(    
      L     #LK_Temp.Leistungsklasse
      L     #LK_Temp.CNF_Leistungsklasse_Max
      <=I   
      )     
      SPB   LVAL                        //Leistungsklasse Gültig (Valid)
      SPA   LINV                        //Leistungsklasse UnGültig (InValid)

LVAL: NOP   0
//==> Pointer der Leistungsklassen-Ziel
      L     #LK_Temp.Leistungsklasse
      L     2                           //<== Sprungweite
      *I    
      L     0                           //<== Start-Wert
      +I    
      L     P#1.0
      *D    
      T     #LK_Temp.PTR_DEST_Leistungsklasse

//==> Entsprechende Leistungsklasse um eins erhöhen
      AUF   "DB_DH_Speicher_1"
      L     DBW [#LK_Temp.PTR_DEST_Leistungsklasse]
      L     1
      +I    
      T     DBW [#LK_Temp.PTR_DEST_Leistungsklasse]

      SPA   LEND

LINV: NOP   0
//==> Unbekannte Leistungsklasse um eins erhöhen
      L     "DB_DH_Speicher_1".Leistungsklasse[25]
      L     1
      +I    
      T     "DB_DH_Speicher_1".Leistungsklasse[25]

      SPA   LEND

LEND: NOP   0

//#############################################################
//### Aktion Ende
//#############################################################        
      L     #LK_Temp.Zaehler
      L     1
      +I    
      T     #LK_Temp.Zaehler

      U(    
      L     #LK_Temp.CNF_Schleifen_Anzahl
      L     #LK_Temp.Zaehler
      <=I   
      )     
      SPB   LE01
      SPA   LP01

LE01: NOP   0
```

Können wir uns nun einmal von dem VKE0-Prob lösen und zum Thema zurückkehren.
Und ja, der Code funktioniert... solange ich ihn anschau


----------



## SPSKILLER (31 März 2009)

Hawkster schrieb:


> Ich kanns jetzt net testen, aber für dich mach ich morgen mal das U( ) raus.


 

... danach kannste den "Danke-Button" klicken


----------



## s3amdrer (31 März 2009)

Na ich hoffe mal auf eine genauso spannende Fehlersuche/Disskusion wie heute!
Es macht echt Spaß in diesem Forum mitzulesen.Alle sind respektvoll und man kann was lernen.

Gruß Rene


----------



## Gerhard K (31 März 2009)

*Alle sind respektvoll*
Träum weiter.Hier gibt welche die wissen nicht mal,dass es dieses Wort überhaupt gibt.
ist jetzt nicht auf dieses thema bezogen.
Gute nacht


----------



## Hawkster (31 März 2009)

ok... jetzt bin ich neugierig

2 Fälle:

```
U M0.0  //VKE0
U(
L 100
L #Zaehler
>=I
)
SPB Anfang
SPA ENDE
```


```
U M0.0  //VKE0
L 100
L #Zaehler
>=I
SPB Anfang
SPA ENDE
```
In meinen Augen geht beides in die Hose. Du jedoch behauptest der 2. Fall wird klappen...

Ok, Höre grade im unteren Fall wird nur der Vergleicher beim Absprung berücksichtigt.... das muss ich gleich ma Testen morgen  Wenn Ja, Sorry all, dann habt ihr recht. Dennoch isses net das Prob


----------



## SPSKILLER (31 März 2009)

genau so ist das...


----------



## Zottel (1 April 2009)

SPSKILLER schrieb:


> @Zottel: Mit Verlaub, aber das ist Blödsinn.


So, das mußte ich jetzt überprüfen, inwieweite es Blödsinn ist...Ergebnis: Es ist TEILWEISE Blödsinn.
Ich habe also beide Schleifen auf einer 315 getestet.
Die Durchläufe mußte ich auf 50 reduzieren, mit 100 bekam ich Zykluszeit-Überschreitungen.
Das wesentliche, was ich Hawkster mitteilen wollte, war eigentlich:
Seine Schleife hat einen bedingten Aussprung und danach einen unbedingten Rücksprung.
Wegen dem U( wird sein bedingter Aussprung ausgeführt, wenn das unmittelbar vor dem Vergleich vorliegende VKE 1 ist UND der Schleifenzähler >= 100.
Ist das VKE davor 0, so wird der Aussprung nie ausgeführt.
Meine geänderte Schleife würde stattdessen in dem Fall die Schleife einmal und den Rücksprung nie ausführen. Das wäre immerhin einfacher zu beobachten.
Meine Schleife, M76.0 bestimmt das VKE beim Eintritt:

```
U     M     76.0

      L     0
      T     #TEMP0

M001: NOP   0
      L     #TEMP0
      L     1
      +I    
      T     #TEMP0

      U(    
      L     50
      L     #TEMP0
      >I    // 
//      <=I   
      )     
      SPB   M001  //
//      SPB   M002
//      SPA   M001
M002: NOP   0

      L     #TEMP0
      T     MW    84
```
Diese Schleife wiederholt nur, wenn M76.0 =1, dann steht 50 im MW84, sonst 1.
Mein Satz über seine Version "In diesem Fall führt ein beim Eintritt in die Schleife gelöschtes VKE dazu, daß der Sprung zu LE01 nie ausgeführt wird."
ist Blödsinn. Der Grund ist aber subtil. Zitat aus der Hilfe zu SPB:

"Wenn VKE = 0, wird der Sprung nicht ausgeführt. Das VKE wird auf "1" gesetzt, und der Programmablauf wird mit der folgenden Anweisung fortgesetzt."
Wenn also Hawksters Schleife den 1. Durchlauf absolviert, stößt sie in jedem Fall auf eine unerfüllte Bedingung. SPB springt nicht, setzt aber das VKE auf 1. 
Der nächste und alle weiteren Durchläufe verknüpft diese 1 mit dem Ergebnis des Vergleichs, so daß der Abbruch und die Schleife funktionieren.

Resultat:
1. Ich habe dazugelernt. SPB beeinflußt das VKE.
2. Das hat wahrscheinlich keinen praktischen Wert für Hawkster, weil sich in dem "Aktionsteil" andere Operationen befinden, die das VKE beeinflußen.
3. Ich habe nochmal dazugelernt. Ich hatte Bedenken bei CLR. Funktioniert aber, weil: CLR setzt nicht nur VKE auf 0 (was ALLEINE für Hawkster fatal wäre), sondern auch /ER auf 0, so daß das U( *nicht keine* Erstabfrage ist, also zur Erstabfrage wird und damit de facto das VKE aus dem Vergleich GELADEN und nicht VERKNÜPFT wird. 
4. Eine möglichst einfache Programmierung ist immer vorzuziehen.
Hier sind überflüssig: 
- U( für die "Schönheit"
- der bedingte Aussprung gefolgt vom unbedingten Rücksprung. Ein bedingter Rücksprung reicht.

Etwas anderes wäre es, wenn Hawkster im "Aktionsteil" eine Zusatzbedingung auswertet. Allerdings wäre dann typischerweise ein "ODER" für den Abbruch oder ein "UND" für die Fortsetzung zu erwarten:
Zutreffenden Datensatz gefunden ODER alle Datesätze durchsucht, dann abbrechen.
Zutreffenden Datensatz NICHT gefunden UND nocht nicht alle Datesätze durchsucht, dann nächster Schleifendurchlauf.
@Hawkster:
Ich halte nicht viel von Schleifen in einem SPS-Programm. Insbesondere, wenn die Anzahl der Durchläufe variabel ist, bergen sie die Gefahr, daß ein programm plötzlich nicht mehr die "Echtzeitanforderungen" erfüllt. Halte mich für arrogant, aber zu 95% gehe ich davon aus, das du die nicht brauchst.

Ich habe deinen Code nur "quergelesen". Aber wenn die Mehrzahl der Daten nicht in jedem Zyklus neu sind, ist es häufig vorteilhaft, zu überlegen, in welcher Weise die neuen Daten dem alten Ergebnis hinzugefügt werden können.

Ein Beispiel:

Vor Jahren habe ich hier mal den Bubblesort-Algorithmus in S7-AWL gepostet, weil jemand eine Tabelle für Pumpenlaufzeiten sortieren wollte. Er schaltet eine Pumpe aus, addiert die absolvierte Laufzeit zur Gesamtlaufzeit dieser Pumpe und sortiert, um beim nächsten Mal diejenige Pumpe einzuschalten, die am wenigsten gelaufen hat.
Für seine 5 oder 7 Pumpen ist es belanglos, aber für 100 Pumpen sind es 4950 Durchläufe der inneren Schleife (nimmt mit n^2-n/2 zu).
Der effizientere Weg ist dann: 
- Den neuen Platz mittels "binary search" ermitteln.
- Alle alten Vorgänger in eine neue Tabelle kopieren
- Alle neuen Vorgänger kopieren
- Datensatz dahinter einfügen
- alle Nachfolger dahinter kopieren.


----------



## Hawkster (1 April 2009)

Also Zottel, Daumen hoch... mich hat das ja schon angefressen, aber dich hats ja jetzt total erwischt...

Bedingt dadurch, das es 4 Uhr nachts ist, komme ich derzeit nur noch bedingt hinterher.

Ich stelle jedenfalls fest, das du bis zum Erbrechen rumgetestet hast. 

Zu der Schleife... klar es ist eine Ansichtssache. Ich weiß nur, das ich bedingt durch die Schleife Sinnvoll viel Code ersparen kann, ob die das Nun noch Aufsplitte ist ja alles möglich. Wie man es realisiert ist ja immernoch ein anderes Thema, weil es mir ja eigentlich um den Magischen Stop ging.

Was mir bei dir auffällt, du Spring bedingt zum Schleifen Anfang, ich hingegehn Springe bedingt zum Ende. Soweit klar... deine Methode (muss ich zugeben) ist auch Sauberer. Bloß ich muss mir morgen in Ruhe nochma das mit den VKE's durchlesen, weil ich da gerade nicht mehr durchsteige.

Aber eine Sache fände ich klasse. Wenn Zottel sich jetzt einen derartigen Aufwand gemacht hat zu Testen, schleifen und Ergebnissse gesammelt hat, würde ich sagen

VOTE 4 STICKY!

In diesem Sinne lege ich mich jetzt schlafen und werde morgen mal den VKE's hinterger-schleifen 

Mit freundliche Grüßen,
Hawkster


----------



## Jo (1 April 2009)

@Hawkster,
ohne auf den Schleifeninhalt einzugehen, dass Problem ist mir auch bekannt. Nach meiner Erinnerung war ausschlaggebend, wo sich der Cursor beim "Brille-drücken" befand, innerhalb der Schleife => Zyklusüberschreitung, ausserhalb => ohne Problem. Wenn das Beobachten lief, konnte der Cursor in die Schleife gesetzt werden. Ich hatte damals allerdings innerhalb der Schleife beide Adressregister genutzt.
Aus den damaligen Hot-Line-Kontakten, ist dann ein FAQ entstanden. Evtl. krame ich mal das betreffende Projekt hervor.
mfG. Jo


----------



## Perfektionist (1 April 2009)

Zottel schrieb:


> ... Der Grund ist aber subtil. ...


es gibt noch einen weiteren "subtilen" Grund: SPB setzt /ER auf null.
Aber diese Erkenntnis wird dem TE nicht nützen


----------



## Ralle (1 April 2009)

Perfektionist schrieb:


> es gibt noch einen weiteren "subtilen" Grund: SPB setzt /ER auf null.
> Aber diese Erkenntnis wird dem TE nicht nützen



Hatten wir das nicht erst. In der Hilfe steht dazu, SPB ist VKE-Begrenzend. D.h. dann, daß nach einer Sprunganweisung, wenn diese ausgeführt wurde oder auch nicht, das VKE True ist und die nächste Abfrage auch eine Erstabfrage ist.


----------



## Perfektionist (1 April 2009)

Ralle schrieb:


> Hatten wir das nicht erst.
> ...


für die Nachwelt: http://www.sps-forum.de/showthread.php?p=187537&highlight=spb+vke#post187537

/ER := 0 ist im übrigen gleichbedeutend mit VKE begrenzen, der nächste Verknüpfungsbefehl setzt dieses Statusbit ("nicht Erstabfrage") dann auf eins.


----------



## centrox (1 April 2009)

genau das hab ich mir beim durchlesen die ganze Zeit auch schon gedacht...

btw. ich hab den gleichen effekt vor ein paar Wochen auch festgestellt. War  ne Schleife mit 128 durchgängen. Beim Beobachten ging die 314er in Stopp. Um die zu verhindern wurde die Schleife auf mehrere Runden aufgeteilt.


----------



## Hawkster (1 April 2009)

Also 

Nach erneuten Rumforschen folgende Erkenntnis.

1. Ich musste das Programm um eine weitere Schleife (gleicher Grundaufbau) erweitern. Somit habe ich im oberen Netzwerk eine einfache Schleife und im unteren Netzwerk eine komplexe.
2. Ich kann diese Schleifen mit meinem Rechner problemlos beobachten.
3. Dennis hat seinen Rechner auf "Einzelplatz" gestellt. Leider ohne erfolg.
4. Wir haben das Programm in eine andere Steuerung gespielt. Gleiches Problem, ich kann es anschauen, der Rest der Welt nicht.
5. In der test-Steuerung ist aber aufgefallen: Normale Zykluszeit 12ms (30 bei F-CALL). Die Einfache Schleife konnten die anderen noch gerade so beobachten. Zykluszeit war dann bei 120-140ms. Sobald wir in die komplexe Schleife wechseln Zykluszeitüberschreitung. Nur nicht bei mir, da schwankt die Zykluzszeit immer nur um +/- 1ms.
6. Wir haben alle Schnittstellen ausprobiert. Alles erfolglos...-> WLAN auf CP343
    -> LAN auf CP343
    -> Via einen Steckverbinder von Prozessinformatik auf die Profibus-Schnittstelle
    -> Via einen Steckverbinder von Prozessinformatik auf die MPI-Schnittstelle
​So, also und das mit dem U( ) ist auch draußen  Geht genausowenig.

Zottel, eine Sache hat mich Stutzig gemacht... du sagtest deine 315 schafft die Schleife nur 50x? Hast du diese zu dem zeitpunkt beobachtet? Wenn ja... mach die Anzahl der schleifen ma auf 100 und Beobachte den Baustein nicht... weil 100 Schleifendurchgänge und dabei Nichtstun ist ein Witz (sogar für ne 315)... Ich mein, ich hab es nochmal mit meiner 317 hier versucht:

Folgende Randbedingungen:
 -> Anwenderprogramm drinnen
 -> F-Programm drin
 -> Maximale Zykluszeit derzeit bei 78MS

Nun hab ich eine Schleife ohne jegliche Aktion integriert folgendes Ergebniss:100 Zyklen -> 78 MS (Unverändert)
1.000 Zyklen -> 78 MS (Unverändert)
10.000 Zyklen -> 83 MS (Oh, es tut sich was )
20.000 Zyklen -> 93 MS (Ok... nun wirds brenzlig)
30.000 Zyklen -> 132 MS (Ja. da hat der F-Call wohl mit reingespuckt)​Aber was ich dir damit sagen will.... ich glaub ja alles... aber nicht das eine 315 bei ner 100 Zyklen-Schleife den Geist aufgibt....

Und wenn man Schleifen sowieso nicht Brauch  Dann Prog mir mal nen Suchbaustein. Hab das ja schon gemacht... deswegen weiß ich das Schleifen eigentlich Oft gebraucht werden. Kommt auch wieder auf die Anwendung an.

PS: Aber immernoch gehts darum: WIESO GEHT DIE CPU _*!-B-E-I-M      B-E-O-B-A-C-H-T-E-N-!*_ IN STOP!

Mit freundlichen Grüßen,
Hawkster


----------



## Gerhard K (1 April 2009)

Sie geht in Stop weil sie sich beim arbeiten nicht über die schulter schauen lässt.
Sorry,aber das hat jetzt raus müssen.*ROFL*


----------



## Hawkster (1 April 2009)

Und ich hab das seltene Privileg ihr zuzuschauen oder wie? Fühl mich geehrt


----------



## Zottel (1 April 2009)

Hawkster schrieb:


> Zottel, eine Sache hat mich Stutzig gemacht... du sagtest deine 315 schafft die Schleife nur 50x? Hast du diese zu dem zeitpunkt beobachtet?
> Wenn ja... mach die Anzahl der schleifen ma auf 100 und Beobachte den Baustein nicht... weil 100 Schleifendurchgänge und dabei Nichtstun ist ein Witz (sogar für ne 315)... Ich mein, ich hab es nochmal mit meiner 317 hier versucht:
> Aber was ich dir damit sagen will.... ich glaub ja alles... aber nicht das eine 315 bei ner 100 Zyklen-Schleife den Geist aufgibt....


Die Schleife hatte ich in einem FC7, der aus dem OB1 aufgerufen wurde. Ansonsten machte das Programm nicht viel.
Der FC7 wurde beobachtet.
Im OB1 prev_cycl_time nach MW kopiert, um es per L MW im FC7 beobachten zu können. FC7 wurde permanent beobachtet.
Zykluszeit 1 bis 4 ms.
Schleife auf 100 Durchläufe.
CPU geht auf Stop.
Auch nach Schalter STOp->RUN ging sie wieder auf Stop.
Im Diagnosepuffer steht dann was von Zyklusüberschreitung. Ein leerer OB80 war vorhanden. Ob die pure Anwesenheit reicht oder Nachtriggern nötig wäre, weiß ich nicht.
Das geschah unabhängig davon, WO das Beobachten anfängt, in der Schleife, oder im Nachfolgenetzwerk.
Es gab keinen signifikanten Unterschied zwischen Beobachten in der Schleife oder hinter der Schleife.
Ich habe nicht versucht, den Baustein nicht zu beobachten.
Ich weiß nicht, welche sonstigen Einstellungen (max.Zykluszeit?) verändert sind, außer maximale Kommunkationslast von 20%->50%.
Ich habe nicht versucht, die Schleife unbeobachtet ausführen zu lassen.  Die CPU ist ein älteres Modell.


Hawkster schrieb:


> PS: Aber immernoch gehts darum: WIESO GEHT DIE CPU _*!-B-E-I-M      B-E-O-B-A-C-H-T-E-N-!*_ IN STOP!


Prinzipiell speichert die CPU während der Ausführung die Ergebnisse der einzelnen Schritte, um sie dann gesammelt zum PG zu schicken.


----------



## Hawkster (1 April 2009)

Ok, findest du aber nicht auch das eine Schleife von 100 Zyklen eine CPU nicht zum Stop bringen sollte?!

Ich mein, es sind im Endeffekt 100x das gleiche... L L +I T... also... würde mich stutzig machen.

Kommunikation steht bei uns auf 20 oder 10 Prozent.

Ich will doch eigentlich nur ne Plausible erklärung wieso ich gugn darf und die anderen net....
Fühl mich ja geehrt aber Toll isses net unbedingt....


----------



## Hawkster (1 April 2009)

Sorry... habs grad nochma durchgelesen deinen Text...

Hast du den FC7 nun mal unbeobachtet gelassen oder nicht? Versuch das mal ohne den FC7 zu beobachten. Einfach auf Run und gugn obs Run bleibt STRG + D 

Bei Stop -> STRG + I und Neustart


----------



## Zottel (1 April 2009)

Nachtrag: habe die HW-Konfig aufgeräumt, alle Profibus-Teilnehmer (waren nicht angeschlossen raus. CPU Einstellungen auf Standard.
Den OB1 aufgeräumt, da steht jetzt nur noch der Aufruf des FC7 drin.
100 geht nicht, 50 geht.
Konstante für Schleifenende  durch MW ersetzt. So kann ich die Schleifendurchläufe vom OB1 aus steuern.
Ohne den FC7 zu beobachten gehen auch 16000. Zykluszeit 121H. Allerdings geht die CPU bei der Funktion "erreichbare Teilnehmer" auf STOP. (Wollte das tun, weil in der CPU noch andere Baustein, z.B. der OB80 sind. Die wollte ich aus "erreichbare Teilnehmer/Baustein löschen".
OB80 und (OB35 der kostet ja eventuell auch Rechenzeit) rausgschmissen.
Ohne OB80: 8000 Schleifen geht, bei 9000 geht die CPU auf Stop. max.Zykluszeit bei 8000 92h=146, Grenze in HW-Konfig 150, das paßt schon.
Weitere Erkenntnis: Die Anwesenheit des OB80 reichte aus. Allerdings darf er ja nicht ohne weiteres mehrmals pro Zyklus aufgerufen werden.
Zielsystem Urgelöscht, nur OB1 und FC7 geladen.
8000 Schleifen geht, bei 9000 geht die CPU auf Stop. 
OB80 hinzugefügt.
16000 Schleifen geht, bei 20000 geht die CPU auf Stop. 
Im OB80 den SFC43 aufgerufen.
20000 Schleifen geht. max. Zykluszeit 163h
32760 Schleifen geht. max. Zykluszeit 23eh
100 Schleifen mit Beobachten des FC7 geht nun auch.
Wenn die Schleife mit beobachtet wird, ist das Beobachten enorm langsam (subjektiv, Fortschritt des grünen Balkens).
Max.Zykluszeit für 100 Durchläufe wenn der FC7 beobachtet wird: 163h.
Die CPU ist 6ES7-2AF03-0AB0, Hardware 1, Firmware 1.2.0.
Max.Zykluszeit für 1000 Durchläufe wenn der FC7 beobachtet wird: df0h, das sind 3.5 Sekunden.
20000 Durchläufe mit beobachten: Die CPU bleibt in RUN. Das Beobachten funktioniert eigentlich nicht mehr, da Step7 meldet, die Anweisungen würden nicht bearbeitet. Der Diagnosepuffer meldet alle 150ms Zykluszeitübeschreitung und addiert die gesamte Zeit auf. Das geht bis in die 42 Sekunden.
Fazit: Mit einem OB80 der SFC43 aufruft, kannst du das Aussteigen der CPU verhindern. Ob du aber etwas steuerst, was wegen der Zykluszeiterhöhung durch beobachten schiefgeht, mußt du selbst wissen.
Am Ende könnte es sinnvoll sein, diesen Baustein zu "schützen", damit ihn niemand aus versehen beobachtet...


----------



## Thomas_v2.1 (1 April 2009)

Ändert sich denn etwas wenn die CPU auf Prozessbetrieb steht und der Parameter für die max. Zykluszeitverlängerung entsprechend gesetzt ist?

Auf der Siemens Seite (Beitrag 23836167) steht dass bei Schleifen vor jedem Schleifendurchlauf der Status beim Beobachten aktualisiert wird.


----------



## Hawkster (1 April 2009)

@Zottel:
Danke, endich einer wo es mal probiert, also ist die Baustelle nicht verflucht sondern es scheint ansatzweise "normal" zu sein.
Nun ist halt die Frage "was ist an meinem Rechner 'unnormal'?" Ich bin bisher der einzige wo es beobachten kann, was ich ja nicht verstehe.

Desweiteren habe ich dieses "Schleife-Aussteig-Problem" noch nie erlebt... weil ich oft gezwungenermaßen Schleifen verwenden muss um bestimmte Problemchen zu lösen. Und diese Schleifenvorgänge sind bedeutend komplexer und bringen die CPU auch nicht ins Schwitzen (ob beobachtet oder nicht (also bei meinem Rechner jedenfalls)).
Das was ich da oben geschrieben habe an Schleife ist ein Witz...

Hier mal ein Auszug von einem Teilprogramm (jaaaa, da sind die U( ) drin ):

*[Siehe Folge-Post]*

Hmm... sollte ich mal bei Siemens anrufen und nach einer Erklärung/Begründung anfragen. Weil es mir ja doch sorgen macht das ich Bausteine schreibe wo 99% der Restlichen SPS-Bevölkerung nicht Anschauen darf da sonst die CPU in Stop geht

Mit freundlichen Grüßen,
Hawkster


----------



## Hawkster (1 April 2009)

```
NOP   0
//#############################################################
//### Wenn Stage 6 aktiv
//###  -> Netzwerk aktiviern
//#############################################################        
      U     #Stage_6.Stage_Start
      SPB   SST6
      SPA   EST6

SST6: NOP   0

      L     1
      T     #Schleife.Zaehler

L150: NOP   0
//#############################################################
//### START:  Loetpunkte aufsplitten
//#############################################################        

//#############################################################
//### QUELLE: Errechnen der Stelle im Stage 5-Block für Datensatz
//#############################################################        
      L     #Schleife.Zaehler
      L     1                           //=> Zähler wird bei 1 Initailisert, deswegen 0 für Multiplikator
      -I    
      L     "DB_Sold_Mgr_1".Parameter.Loetpunkt_Groesse    //==> Speichergröße (100 Byte pro Datensatz)
      *I    
      L     "DB_Sold_Mgr_1".Parameter.Stage_5_Startbyte    //==> Startbyte (Byte 332)
      +I    
      T     #Stage_6.src_Addresse_Offset

//#############################################################
//### QUELLE: Aufbau des Ziel-Any-Pointers
//#############################################################        
      L     P##src_Any_Pointer
      LAR1  

      L     W#16#1002                   //Typ BYTE
      T     LW [AR1,P#0.0]

      L     "DB_Sold_Mgr_1".Parameter.Loetpunkt_Groesse    //Anzahl Bytes
      T     LW [AR1,P#2.0]

      L     "DB_Sold_Mgr_1".Parameter.Temp_Job_DB    //Ziel-DB
      T     LW [AR1,P#4.0]

      L     #Stage_6.src_Addresse_Offset    //Anfang der Quelle
      SLD   3
      OD    DW#16#84000000
      T     LD [AR1,P#6.0]

//#############################################################
//### ZIEL: Errechnen der Stelle im Stage 6-Block für Datensatz
//#############################################################        
      L     50                          //<== Größe eines auftrags
      L     2
      *I    
      T     #Stage_6.dest_Data_Size     //<== Loetpunkt stellt 2 Aufträge das

      L     #Schleife.Zaehler
      L     1                           //=> Zähler wird bei 1 Initailisert, deswegen 0 für Multiplikator
      -I    
      L     #Stage_6.dest_Data_Size     //==> Speichergröße (100 Byte für 2 Aufträge)
      *I    
      L     "DB_Sold_Mgr_1".Parameter.Stage_6_Startbyte    //==> Startbyte (Byte 6832)
      +I    
      T     #Stage_6.dest_Addresse_Offset

//#############################################################
//### ZIEL: Aufbau des Ziel-Any-Pointers
//#############################################################        
      L     P##dest_Any_Pointer
      LAR1  

      L     W#16#1002                   //Typ BYTE
      T     LW [AR1,P#0.0]

      L     #Stage_6.dest_Data_Size     //Anzahl Bytes
      T     LW [AR1,P#2.0]

      L     "DB_Sold_Mgr_1".Parameter.Temp_Job_DB    //Ziel-DB
      T     LW [AR1,P#4.0]

      L     #Stage_6.dest_Addresse_Offset    //Anfang der Quelle
      SLD   3
      OD    DW#16#84000000
      T     LD [AR1,P#6.0]



//#############################################################
//### Daten temp. Zwischenspeichern
//#############################################################        
      CALL  "BLKMOV"
       SRCBLK :=#src_Any_Pointer
       RET_VAL:=#Stage_6.BLKMOV_Return
       DSTBLK :="DB_Sold_Mgr_1_Job_1".Stage_6_Temp.Original

//#############################################################
//### Orignal-Daten aufsplitten und speichern in Auftrags-Daten
//#############################################################        
      L     0
      T     #Clear_Int

      CALL  "FILL"
       BVAL   :=#Clear_Int
       RET_VAL:=#iDummy
       BLK    :="DB_Sold_Mgr_1_Job_1".Stage_6_Temp.Modifiziert.Kamera

      CALL  "FILL"
       BVAL   :=#Clear_Int
       RET_VAL:=#iDummy
       BLK    :="DB_Sold_Mgr_1_Job_1".Stage_6_Temp.Modifiziert.Laser

//#############################################################
//### Kamera-Daten
//#############################################################        
      SET  
      S     "DB_Sold_Mgr_1_Job_1".Stage_6_Temp.Modifiziert.Kamera.Kamera.Kamera_Punkt

      L     "DB_Sold_Mgr_1_Job_1".Stage_6_Temp.Original.Kamera.Roboter_Index_Nummer
      T     "DB_Sold_Mgr_1_Job_1".Stage_6_Temp.Modifiziert.Kamera.Kamera.Roboter_Index_Nummer

      L     "DB_Sold_Mgr_1_Job_1".Stage_6_Temp.Original.Kamera.Kamera_Prog
      T     "DB_Sold_Mgr_1_Job_1".Stage_6_Temp.Modifiziert.Kamera.Kamera.Kamera_Prog

//#############################################################
//### Laser-Daten
//#############################################################        
      SET  
      S     "DB_Sold_Mgr_1_Job_1".Stage_6_Temp.Modifiziert.Laser.Laser.Laser_Punkt

      L     "DB_Sold_Mgr_1_Job_1".Stage_6_Temp.Original.Laser.Roboter_Index_Nummer
      T     "DB_Sold_Mgr_1_Job_1".Stage_6_Temp.Modifiziert.Laser.Laser.Roboter_Index_Nummer

      L     "DB_Sold_Mgr_1_Job_1".Stage_6_Temp.Original.Laser.Laser_Dummy_Nr
      T     "DB_Sold_Mgr_1_Job_1".Stage_6_Temp.Modifiziert.Laser.Laser.Laser_Dummy_Nr

      U     "DB_Sold_Mgr_1".Berechnung.Nachloeten
      SPB   NL_1
      UN    "DB_Sold_Mgr_1".Berechnung.Nachloeten
      SPB   NL_0
      SPA   NL_E

NL_1: NOP   0                           //<== Nachloeten ist aktiv!

      L     "DB_Sold_Mgr_1_Job_1".Stage_6_Temp.Original.Laser.Laser_Nachloeten_Nr
      T     "DB_Sold_Mgr_1_Job_1".Stage_6_Temp.Modifiziert.Laser.Laser.Laser_Scharf_Nr

      SPA   NL_E

NL_0: NOP   0                           //<== Nachloeten ist Inaktiv!

      L     "DB_Sold_Mgr_1_Job_1".Stage_6_Temp.Original.Laser.Laser_Scharf_Nr
      T     "DB_Sold_Mgr_1_Job_1".Stage_6_Temp.Modifiziert.Laser.Laser.Laser_Scharf_Nr

      SPA   NL_E

NL_E: NOP   0

//#############################################################
//### Auftragsmuster beschreiben
//###   -> Auftragsmuster wird Anhand der Daten von Stage_1_Stage_2 errechnet
//#############################################################  

      L     #Schleife.Zaehler
      L     1
      -I    
      L     2                           //==> Speichergröße (2 Byte)
      *I    
      L     4                           //==> Startbyte (Byte 4)
      +I    
      L     P#1.0                       //==> Ins Pointer-Format bringen
      *D    
      T     #Stage_6.Offset_Auftrag_Pointer    //<== Pointer vom Ziel der Addresse

      AUF   "DB_Sold_Mgr_1_Job_1"
      L     DBW [#Stage_6.Offset_Auftrag_Pointer]
      L     #Daten_Allgemein.Arbeitsbereich_Startbyte
      -I    
      T     #Stage_6.Offset_Auftrag

      L     #Stage_6.Offset_Auftrag
      L     100
      /I    
      L     1
      -I    
      T     #Stage_6.Schiebewert_Muster

//#############################################################
//### ENTSCHEIDUNG: Schiebewert größer als ein DW
//###   -> Auftragsmuster 1_2 löschen und mit 2_2 fortsetzen
//#############################################################  
      U(    
      L     #Stage_6.Schiebewert_Muster
      L     31
      <=I  
      )    
      SPB   A1_2
      SPB   A2_2

A1_2: NOP   0

      L     #Stage_6.Schiebewert_Muster
      L     "DB_Sold_Mgr_1".Berechnung.Auftragsmuster_1_2
      SRD  
      SLD  
      T     #Stage_6.Auftragsmuster_1_2

      L     #Stage_6.Auftragsmuster_1_2
      T     "DB_Sold_Mgr_1_Job_1".Stage_6_Temp.Modifiziert.Kamera.Auftragsmuster_1_2
      T     "DB_Sold_Mgr_1_Job_1".Stage_6_Temp.Modifiziert.Laser.Auftragsmuster_1_2

      L     "DB_Sold_Mgr_1".Berechnung.Auftragsmuster_2_2
      T     "DB_Sold_Mgr_1_Job_1".Stage_6_Temp.Modifiziert.Kamera.Auftragsmuster_2_2
      T     "DB_Sold_Mgr_1_Job_1".Stage_6_Temp.Modifiziert.Laser.Auftragsmuster_2_2


      SPA   AEND

A2_2: NOP   0

      L     #Stage_6.Schiebewert_Muster
      L     32
      -I    
      L     "DB_Sold_Mgr_1".Berechnung.Auftragsmuster_2_2
      SRD  
      SLD  
      T     #Stage_6.Auftragsmuster_2_2

      L     0
      T     "DB_Sold_Mgr_1_Job_1".Stage_6_Temp.Modifiziert.Kamera.Auftragsmuster_1_2
      T     "DB_Sold_Mgr_1_Job_1".Stage_6_Temp.Modifiziert.Laser.Auftragsmuster_1_2

      L     #Stage_6.Auftragsmuster_2_2
      T     "DB_Sold_Mgr_1_Job_1".Stage_6_Temp.Modifiziert.Kamera.Auftragsmuster_2_2
      T     "DB_Sold_Mgr_1_Job_1".Stage_6_Temp.Modifiziert.Laser.Auftragsmuster_2_2


      SPA   AEND


AEND: NOP   0


//#############################################################
//### Daten temp. Zwischenspeichern
//#############################################################        
      CALL  "BLKMOV"
       SRCBLK :="DB_Sold_Mgr_1_Job_1".Stage_6_Temp.Modifiziert
       RET_VAL:=#Stage_6.BLKMOV_Return
       DSTBLK :=#dest_Any_Pointer


//#############################################################
//### Ende:   Umkopieren der Loetpunkte
//#############################################################        
      U(    
      O(    
      L     #Schleife.Zaehler
      L     64
      >=I  
      )    
      O(    
      L     #Schleife.Zaehler
      L     "DB_Sold_Mgr_1_Job_1".Stage_1_Stage_2.Letzter_Datensatz
      >=I  
      )    
      )    
      SPB   E150

      L     #Schleife.Zaehler
      L     1
      +I    
      T     #Schleife.Zaehler

      SPA   L150

E150: NOP   0

      SET  
      S     "DB_Sold_Mgr_1".Status.Stage_6_Fertig

      U     "DB_Sold_Mgr_1".Parameter.Stage_6_BEA
      BEB  


EST6: NOP   0
```


----------



## Zottel (2 April 2009)

Hawkster schrieb:


> @Zottel:
> Nun ist halt die Frage "was ist an meinem Rechner 'unnormal'?" Ich bin bisher der einzige wo es beobachten kann, was ich ja nicht verstehe.


Das Beobachten funktioniert ungefähr so:
- Das PG teilt der CPU die Adresse mit, ab der beobachtet werden soll.
- Die CPU speichert die Registerinhalte, die sich beim Ausführen jeder Anweisung ergeben. Das tut sie im Normalbetrieb nicht.
- Das PG fordert periodisch so einen Auszug an
Was ich nicht weiß, ist:
Was macht die CPU
- In Schleifen. Normalerweise beschränkt sich die Anzahl der "beobachteten" Anweisungen mehr oder weniger auf den Code im sichtbare Fenster. Weiß nicht, woher die kommt, ob das PG eine Endadresse, eine Anzahl von Anweisungen vorgibt, oder die CPU ein Limit hat oder was auch immer.
Reine Spekulation: In Schleifen könnte es wohl sein, daß die CPU pro Ausführung speichert. Möglicherweise wird für ein "langsames" PG die Liste sehr lang und die CPU muß irgendwelchen Aufwand zum Speichermanagement betreiben.


Hawkster schrieb:


> Hier mal ein Auszug von einem Teilprogramm (jaaaa, da sind die U( ) drin ):


Nützt nicht ganz viel: Wegen der ganzen symbolischen Namen & UDTs läßt sich das nicht ohne Kontext übersetzen...


Hawkster schrieb:


> Hmm... sollte ich mal bei Siemens anrufen und nach einer Erklärung/Begründung anfragen. Weil es mir ja doch sorgen macht das ich Bausteine schreibe wo 99% der Restlichen SPS-Bevölkerung nicht Anschauen darf da sonst die CPU in Stop geht


Ja wäre interessant. Zum Abschluß: Ich habe mit IBH-Link und MPI-Baudrate 187,5k getestet. Man könnte die MPI Baudrate reduzieren, um ein "langsameres" PG zu simulieren.


----------



## Zottel (2 April 2009)

Thomas_v2.1 schrieb:


> Ändert sich denn etwas wenn die CPU auf Prozessbetrieb steht und der Parameter für die max. Zykluszeitverlängerung entsprechend gesetzt ist?


Ich habe mal Prozessbetrieb eingestellt.
Mit "zulässige Verlängerung"
5 ms kann ich aus "Beobachten" keine Variable mehr steuern, Meldung "D0AA, Zeitlimit aus Prozessbetrieb überschritten"
15ms: dasselbe.
40ms: Ich kann steuern, beobachten, 8000 Durchläufe gehen, 9000 bringen den STOP.


----------

