Todes-Schleife...

Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
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...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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:
Code: 
      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
Zum Vergrößern anklicken....
 
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
 
U(
L 100
L #LK_Temp.Zaehler
<=I
)
Zum Vergrößern anklicken....
versteh ich eh nicht , wozu brauchst du das U?:confused:
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...
 
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?:confused:
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...
Zum Vergrößern anklicken....
 
Loop nutz ich net :smile: Nicht flexibel genug der Rotz befehl :smile:
Zum Vergrößern anklicken....
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...
 
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
Zum Vergrößern anklicken....
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
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...
Zum Vergrößern anklicken....
 
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.
Code: 
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
 
Ja, deine Theorie hatten wir schon auf der Baustelle gell Dennis.

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

Code: 
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 :)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
mein Beispiel sollte zeigen, warum das "U(" weg muss. :rolleyes:

Falls jemand durch Auskommentieren, oder was auch immer ein
VKE ohne Zuweisung über der Schleife stehen lässt, dann geht deine CPU in STOP !!!!
 
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.
Zum Vergrößern anklicken....

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
 
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" :)
Zum Vergrößern anklicken....
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...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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" :D

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 :D
 
Zuletzt bearbeitet:
SPSKILLER schrieb:
mein Beispiel sollte zeigen, warum das "U(" weg muss. :rolleyes:

Falls jemand durch Auskommentieren, oder was auch immer ein
VKE ohne Zuweisung über der Schleife stehen lässt, dann geht deine CPU in STOP !!!!
Zum Vergrößern anklicken....
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.
 
Code: 
      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...

Code: 
      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
 

Similar threads

T
Step 7 Schleife mit indirekter Adressierung
Antworten
12
Aufrufe
2K
Tschigi
T
RoBop
Sonstiges Fernwartung nach China
Antworten
13
Aufrufe
7K
Boxy
Boxy
Gerhard Bäurle
TIA-Portal: Siemens-Vortrag Zusammenfassung
Antworten
6
Aufrufe
36K
georgeleo104
G
P
Pointer Zeiger FIFO LIFO
Antworten
1
Aufrufe
94K
PN/DP
PN/DP
Zurück
Oben