TIA Online Probleme TIA V13

PENT89

Level-2
Beiträge
37
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Guten Morgen zusammen,

ich wollte mal wissen, ob ihr die selben Probleme habt wie ich.

Also ich sitze gerade vor einer Anlage die in Produktion läuft. Sobald ich mich Online schalte bekomme ich interessante Fehler innerhalb der Maschine. Unteranderem Positionierungsfehler.
Wenn ich Offline bin funktioniert alles Tadellos.

Kennt einer das Problem und hat einer eine Lösung? Ist das mit V14 immernoch ein Problem?

Danke an alle.
 
Ich glaube die Zykluszeit geht durch das Online verbinden und noch mehr beim Online beobachten rauf. Wenn man nun in der Software durch irgendwelche Zeiten positioniert kann eine Erhöhung der Zykluszeit schon zu Problemen führen.
 
Die TIA-Dinger sind keine SPSen.
Das Grundprinzip einer SPS basiert auf der durch einen vorhersehbar langen Zyklus garantierte weiche Echtzeit.

Wenn ich mir das Zykluszeit-Gehoppse bei einem an Sonsten sauber ohne viel Springerei laufenden Prozess
anschaue, weiss ich eigentlich schon alles.

Probiere mal, beim Webserver den maximalen Zeitverbrauch pro Zyklus einzustellen ...
Jow, geht nicht.

Soweit zum Thema Echtzeit, bzw zum Thema SPS.

( 2010 in Mannheim TIA-Präsentation: Versprochen wurde:
"Funktionalität, Funktionalität und ... Funktionalität".

Bekommen haben wir
Verstümpertes Firmware-Design, einen Designer-Amoklauf und bodenlose Ignoranz der Aufgabenstellung gegenüber.

Gruss
Werner
 
@heisch
Zum verstümperten FW-Design und Designer-Amok würde ich ohne mit der Wimper zu zucken zustimmen.

Wo ich allerdings nicht so ganz folgen kann, in welchem Punkt sich jetzt das "Zykluszeit" Gehopse mit TIA ggü. Step7 nennenswert verschlechtert haben soll, das war bei 300/400 auch schon so, dass jedwede Kommunikation eine Rückkopplung auf die Zykluszeit hat ... Webserver habe ich allerdings noch nicht intensiv genutzt, höchstens mal mit Standard-Oberfläche zur Diagnose ...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@MSB

Ja, vielleicht hast Du recht.
mein erste Spiel -S7 (314, klein und gemütlich) hatte auch bei streng zyklischem Programm eine Abweichung von 30%.

Interessanterweise die 95U nicht, obwohl die auch keinen MC5-Prozessor hatte, dort hat ein 8051-Nachfolger den Job erledigt.

Bei den schnelleren S7 ist das dann nicht mehr aufgefallen, ausserdem war in der Regel die Zykluszeit dahingehend nichtmehr
überprüfbar, weil viel gesprungen wurde .. und sei es nur dass irgen welche Sache gezählt wurden.

Was ich ja noch verstehe, ist, dass wenn was verschickt oder empfangen werden muss, dann muss das eben getan werden.
Das hängt ja mit Peripherie oder Prozess zusammen.
Gerüchten zufolge sitzt in den kleinen 1500ern ein Armprozessor mit einem Kern.
Wenn schon kommuniziert werden muss: das Programmiergerät tut's, der Bus tut's .... sind denn die Mehrkern-ARMs so teuer ?
Ein Pi 3 kostet 36 Eu !

Wo mein Verständnis aber absolut endet, ist der Einsatz eines Webservers, mit dem man dann von "aussen"
(Industrie 4.0, Spionage 4.1, Sabotage 4.2) die Zykluszeit kaputt hauen kann, ohne dass der Programmierer das begrenzen kann.

Für mich fehlt es bei solchen Sachen schon an den Basics.
Solche Leute sollten keine SPSen bauen.

Gruss Werner
 
Für mich fehlt es bei solchen Sachen schon an den Basics.
Solche Leute sollten keine SPSen bauen.

Ach tröste dich, auch die welche die Dinger programmieren sollen, haben immer weniger Ahnung von "Zyklus"...

Hab eine 1200er bei mir, die ein Spezial-Spezial-Superprogramm drauf hat, welches nur für die Überwachung von Sensorik geschrieben ist.
Erinnert in den Programmteilen welche ich bisher gesehen habe eher an eine C# oder Java-App :(
Wird dann angeblich gebraucht um auf <5ms genau zu erkennen, wenn sich ein Wert ändert...
Gut, versteht zwar keine weshalb man das benötigt, wenn man erst die Wandlugszeit der 8AI-Module betrachtet und dann noch, das z.B. der eine Luftdrucksensor in einer 1,5Zoll-Leitung sitzt... :ROFLMAO: Aber Hauptsache man Könnte erkennen, Wenn sich ein Wert mal Tatsächlich so schnell ändert... *ROFL*

MfG Fabsi
 
Uns wurde gesagt man solle nicht mehr im OB1 das Programm laufen lassen... Weil dort eben die Zykluszeit beim Verbinden zu hoch geht... Also alles in einen Weckalarm OB machen...

Man muss nicht alles verstehen...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Was bedeutet zu hoch geht?

Ich hab mir gestern einen Programmteil mit Positionierung Online angesehen. Dabei hatte ich jedesmal Positionierfehler. Erst als ich offline gegangen bin war alles gut.

Um eine solche Fehlpositionung hin zu bekommen müßte ich eine Zeit von > 500ms haben....
 
Uns wurde gesagt man solle nicht mehr im OB1 das Programm laufen lassen... Weil dort eben die Zykluszeit beim Verbinden zu hoch geht... Also alles in einen Weckalarm OB machen...

Ich hol das Thema nochmal hoch... Hab das heute morgen gar nicht auf Anhieb gefunden :) Aber das mit dem Weckalarm probier ich jetzt mal aus :D

Hab da ein lustiges, oder eher ärgerliches Problem:
1511-1PN mit ein paar Modulen daran, 1 HMI und 3 Put/Get zu 400er und 300er Steuerungen, sowie Webserver aktiv.
Die macht die meiste Zeit quasi nix, weil diese nur für Machinenumrüstung benötigt wird.
Verbinde ich mich mit dem Ding, direkt mit dem Punkt "Online & Diagnose" offen sieht man am rechten Rand ja die Zykluszeit. Da das Programm recht groß ist, liegt die so im Mittel bei 3-5ms (also solange sie quasi nichts berechnet ;) )
Jedoch steht schön daneben die längste Zykluszeit bei 54ms, was ich stark annehmend vom Verbindungsaufbau her rührt...

Klar, sind nicht ganz die eingestellten 50% für Kommunikation von der Zykluszeit, aber für unseren Prozess noch vertretbar...

Dann hab ich eine neue 1511C-1PN, hier hängt am X1 ein Profinet-Drive per IRT. Am X2 nur das PG... Sonst ist außer der Stromversorgung noch absolut Nichts angeschlossen...
Als Programm ist auch nur die eine Positionierachse unter Tech-Objekte angelegt, sowie das Beispielprogramm des Achsenherstellers darauf. (1 FB "Beispiel", 1FB MC-Power&Home für diese Achse kombiniert und 1 DB, nebst den 2-3 Achsenbausteinen)
Verbinde ich mich jetzt mit dem Dre**s-Ding und habe den Punkt "Online & Diagnose" offen, dann geht sogar die SF-LED an, obwohl das Demoprogramm nicht mal abgearbeitet wird. Denn dazu müsste ich ja den DB online öffnen und "Start-Drücken"...
Zykluszeit liegt bei 2-3ms und wenn ich den DB aufrufe... Tja, dann hauts hoch bis über 100ms und teilweise auch noch bis >300ms, was ich dann immer nur daran merke das die Möhre stoppt...

Ich probiere also nun das mit dem Weckalarm-OB mal aus und werde hier berichten :)

MfG Fabsi
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@Fabicard

Liegt das nun an der neuen CPU oder eher am Verwenden der Technologieobjekte? Ich nutze ganz deswegen immer noch vorwiegend Servos, die alles selbst berechnen und von mir nur die Position, Geschwindigkeit und Start bekommen. Hast du das mal getestet?
 
@Ralle: Im Prinzip macht der Servo ja vieles selbst :D Wenn ich mir das "Fahrverhalten" von der Achse anschaue, dann scheint der diesem lediglich die Werte bei MC_MoveAbsolute auch einfach nur zu übergeben... Die Tech-Objekte will ich dort ja nur nutzen, damit ich noch 2 andere Geräte mit Drehgeber/Markensignalen synchronisieren kann...
Es liegt aber definitiv an den Tech-Objekten und der CPU, vergleiche ich das jetzige Verhalten mit der 1511er, dann kann man da durch PG-Kommunikation die Zykluszeit ebenfalls übermäßig hochtreiben, jedoch nicht so extrem wie mit den Tech-O auf der CPU ;)

@RogerSchw85: Ich versuche mal von dem Display ein Video zu machen, ggf. glaubst du mir das ja dann ;)

Ein Problem hab ich inzwischen gefunden, die V3.0 von den Tech-Objekten verbraucht immense Ressourcen auf der CPU mehr, als die V2.0... Gut, mit der gehts auch ausreichend bei mir.
Jetzt liege ich bei 0-4ms Zykluszeit. Wenn ich online mit dem PG verbinde springt diese einmalig hoch bis maximal 54ms, was immer noch viel viel zu hoch ist aber ok für mich in diesem Fall... Geht man auf Software-Komplett-Laden, baut das PG so viel Kommunikation auf, das kurzfristig die SF-LED angeht. (die geht fürs Laden eh in Stop, aber interessant ist es schon)
Die Kommunikation durch das HMI allerdings, die macht wenn überhaupt 1ms an der Zykluszeit...

MfG Fabsi
 
Wie verhält es sich, wenn du eine feste Mindestzykluszeit von beispielsweise 10ms vor gibst? Hast du das mal probiert? Oder kommt das gar nicht in Frage?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ach da hatte ich auch schon daran gedacht. Bevor ich mit den Tech-Objekten von V3.0 auf V2.0 gewechselt hab, einfach mal 10ms und 50ms eingetragen. Brachte ebenso wie alles in einen Weckalarm-OB zu packen... Überhaupt nichts :)

MfG Fabsi
 
Ich dachte immer bei der Technologie in der 1500-er regelt auch die SPS und der Servo ist nur ein "dummer" Steller. Alles Andere erklärt ja nicht wirklich den hohen Zykluszeitverbrauch.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Gibt es bei der S7-1500 sowas wie Prozessbetrieb und Testbetrieb? Bei S7-300/400 kann man darüber einstellen, daß die zulässige Zykluszeiterhöhung durch Kommunikation nicht überschritten wird.

Programm nicht im OB1 sondern in zyklischem Weckalarm-OB ausführen:
- dann muß man selbst für die Aktualisierung des Prozeßabbildes der Eingänge und Ausgänge sorgen (SFC26 + SFC27) oder nur direkt mit der Peripherie arbeiten
- die Zykluszeiterhöhung durch PG-Kommunikation passiert trotzdem noch, doch es sollte keinen Einfluß mehr auf das Programm haben

Harald
 
@Wincctia: Ich hab diverse ausprobiert, da TIA ja die Prio automatisch nach der eingestellten "Weckzeit" setzt. Probiert mit 1ms, 2ms, 5ms, 10ms und auch mal scherzeshalber mit 50ms da hat aber der Antrieb direkt gestreikt :D
Da der Tacksynchrone Betrieb nur bis 4ms einstellbar ist, hab ich darüber dann jeweils mit dem "mehrfachen des Taktes" die Weckzeit eingestellt.

@PN/DP: Ja das hab ich auch gedacht mit dem Testbetrieb, gibt es bei der S7-1500 aber nicht. (Ich hab so bissel das Gefühl, dass die das "immer" macht :( )
OB1 war leer, in dem Weckalarm-OB waren lediglich die MC-Aufrufe. Somit entfällt die "selbst-Aktualisierung" weil das durch das Tech-Objekt automatisch mit dem Taktsynchronen Betrieb gemacht wird ;)
Das Verhalten der Achse, soweit ich sie zu diesem Zeitpunkt bedienen konnte, war identisch. Lediglich dazu kamen dann noch die Fehlermeldungen das die Bearbeitung des Weck-OB den Zeitfehler erzeugt hat, wenn ich mit dem PG verbinden wollte...

MfG Fabsi
 
Hallo Fabi,

das würde aber dafür Sprechen das dein Unterbruch Ob noch zu nieder Priorisiert war weil sonst sollte er ja laut Handbuch die Kommunikation unterbrechen können.


Mit freundlichen Grüßen Tia
 
Zurück
Oben