TIA CPU313C gegen S7-1500 tauschen? Oder bessere Alternative?

[escride1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi,

ich habe heute an einer Anlage mit einer 313C (6ES7313-5BF03-0AB0) zu tun gehabt.

Es wird aktuell der schnelle Zähler genutzt um im Programm dann anschließend für eine Lackmengenberechnung per Anzahl Impulse*Zeit den Lackauftrag zu berechnen. Da der Hersteller scheinbar schon mitbekommen hat das es nicht so gut funktioniert, wird die Ausgabe nun nicht in Echtzeit (wie es die Programmstruktur eigentlich vorsieht), sondern durch eine nachprogrammierte Lösung nach Beendigung der Lackierung als Gesamtverbrauch angezeigt und daraufhin ein selbstgebastelter Regler +/- für etwas mehr/etwas weniger aktiviert, also Step für Step. Das heisst, es dauert mitunter 5 bis 20 Teile bis der Regler einen richtigen Wert hat mit dem die restlichen 60 Teile lackiert werden können. Also Ausschuss bzw. Nacharbeit in hoher Zahl aktuell.

Diese Anzeige schwankt von Teil zu Teil bei deaktiviertem Regler, also bei konstanter Ausgabe (4-20mA-Geber anstelle der SPS für den Frequenzumrichter, welcher den Druck aufbaut, angeschlossen zum Test). Folglich bleibt es definitiv dabei das die Messung "fehlerhaft" ist.

Nach einiger Recherche konnte ich sehen das sie CPU zwischen 19 und 47ms Zyklus schwankt, sehr viele bedingte AWL-Sprünge, die Impulse*vergangene Zeit allerdings auf einen festen Zyklus (24ms) programmiert wurden. Also ist das definitiv ungenau.

Da der Kd am liebsten eine Regelung haben möchte die direkt eingreift überlege ich ob es Sinn macht die 313er gegen eine 1500er zu tauschen, da der Zyklus hier signifikant niedriger ist und dann die Zykluszeit unter 3ms fällt, was bedeutet das man dann den Regler wieder aktivieren kann um die Menge nahezu in Echtzeit zu berechnen.
Eine typische Druckregelung mittels Prop-Ventile selbst kommt aufgrund einer angeblich früheren schlechten Erfahrung nicht in Betracht, keine Ahnung was da früher verbockt wurde. Ich muss also für die Druckregelung den Frequenzumrichter sowie Pumpenmotor beibehalten.

Die Anlage wurde von mir übernommen, der Hersteller hat kein Interesse mehr am Support gehabt. Im Zuge einiger Korrekturen sowie Erweiterung wurde das Projekt bereits in TIA V15 migriert und alle Bausteine so angepasst, das im Falle eines Ausfalles die Station binnen weniger Stunden auf eine 1500er getauscht werden könnte. Die Arbeit mit der Migration wäre also nicht das Problem. Auf meiner Agenda stehen noch die saubere Umstrukturierung des Programms (mehrere FC-Aufrufe zu einem FB ändern weil das aktuelle an zig Stellen im Programm bearbeitet wird, sehr unübersichlich, da teilweise Ausgänge mehrfach zugewiesen werden).

Das aktuelle Rack der 313er ist voll. Es müsste für künftige Erweiterungen (einige gewünscht) also entweder eine Rackerweiterung oder eine ET200 eingesetzt werden. Profinet ist durch einen CP bereits vorhanden, das alte Profibus muss beibehalten werden, also muss auch ein Netzübergang mit dran. HMI wurden bereits alle auf aktuelle Profinetgeräte hochgetauscht, da die alten blass, teilweise ganz defekt waren.
Der Arbeits- und Ladespeicher ist aktuell zu 93% gefüllt. Viel geht also so oder so nicht mehr da er nicht erweiterbar ist.

Was wäre nun also Eure Meinung hierzu? Das eventuell irgendwann eine 1500 kommen muss ist wegen den Erweiterungen in 2020 schon fast klar, nur eben speziell nur für diese Funktion bereits jetzt?

 

[PN/DP]

Hast Du evtl. eine aktuelle CPU 6ES7313-5BG04-0AB0 im Lager? (Oder eine 313-6CG04, 314-6CH04 oder gar eine 314C-2PN/DP 314-6EH04 ?)
Da könntest Du als einfachstes schon mal die CPU austauschen und würdest vermutlich auf 12..32ms Zykluszeit runterkommen und hättest doppelt soviel Programmspeicher. Logikanweisungen sind 25..30% schneller, Festpunktarithmetik ist 12 mal schneller und Gleitpunktarithmetik ist 4 mal schneller als die vorhandene 313-5BF03. Das sollte die Situation verbessern..

Woraus werden Sollwerte gebildet, wie ausgegeben? Nicht das da langsame Analogbaugruppen im Spiel sind anstatt der CPU-integrierten Analog-EA. Kann der angestrebte Regelkreis bzw. der Prozess denn tatsächlich schneller gemacht werden? (Aus Deinen Ausführungen habe ich leider nicht verstanden, was denn nun das nicht lösbare Problem ist.)

Ich verstehe nicht, wofür der schnelle Zähler benutzt wird, und warum von einer (womöglich nur schlecht programmierten) ungenügenden Lösung zu einer noch schlechteren Lösung gewechselt wurde. Zur Software-Qualität können wir ohne Anschauen nichts sagen.

Das aktuelle Rack der 313er ist voll. Es müsste für künftige Erweiterungen (einige gewünscht) also entweder eine Rackerweiterung oder eine ET200 eingesetzt werden.

Könnte vielleicht ein großer Programmteil an eine zweite CPU ausgelagert werden? So daß die CPU nur den zeitkritischen Part zu bearbeiten hat. Könnten die Fehlschläge der Vergangenheit damit zu tun haben, daß der CPU mehr und mehr vorher ungeplante zusätzliche Aufgaben übertragen wurden?

Ohne dringende Not würde ich nicht von der S7-300 zu einer S7-1500 wechseln - da holt man sich ungeahnte Probleme ins Haus, wenn man mit dieser Migration noch wenig Erfahrung hat.

Harald

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich würde mich Harald anschließen und auf eine 314-6EH04 gehen. Die hat auch gleich Profinet dabei und das volle Rack konnte man z.b. mit einer ET200M Profinet erweitern. Oder dezentrale Peri mittels Et200, Beckhoff io.......

Ich habe gelesen, dass du schon Profinet hast.

Der Weg hätte auch noch den Vorteil, das nicht viel umverdrahtet werden muss, es wenig Risiken gibt und du ein stabiles System hast.

 

[escride1]

Guten Morgen zusammen,

Hast Du evtl. eine aktuelle CPU 6ES7313-5BG04-0AB0 im Lager? (Oder eine 313-6CG04, 314-6CH04 oder gar eine 314C-2PN/DP 314-6EH04 ?)
Da könntest Du als einfachstes schon mal die CPU austauschen und würdest vermutlich auf 12..32ms Zykluszeit runterkommen und hättest doppelt soviel Programmspeicher. Logikanweisungen sind 25..30% schneller, Festpunktarithmetik ist 12 mal schneller und Gleitpunktarithmetik ist 4 mal schneller als die vorhandene 313-5BF03. Das sollte die Situation verbessern.

die genannten Baugruppen habe ich nicht mehr auf Lager, wohl aber eine 315-2DP. Müsste dazu dann aber auch noch die beiden Baugruppen nachstecken, also E/A.
Wieviel die schneller sind, was Du aufgeführt hast, ist ja mal beträchtlich. Damit habe ich mich nie auseinandergesetzt. Kommt eher selten vor, das ich so dermaßen den Zyklus unter Kontrolle haben muss.

Woraus werden Sollwerte gebildet, wie ausgegeben? Nicht das da langsame Analogbaugruppen im Spiel sind anstatt der CPU-integrierten Analog-EA. Kann der angestrebte Regelkreis bzw. der Prozess denn tatsächlich schneller gemacht werden? (Aus Deinen Ausführungen habe ich leider nicht verstanden, was denn nun das nicht lösbare Problem ist.)

Ich verstehe nicht, wofür der schnelle Zähler benutzt wird, und warum von einer (womöglich nur schlecht programmierten) ungenügenden Lösung zu einer noch schlechteren Lösung gewechselt wurde.

Die Berechnung erfolgt im AWL-Code (was ja nicht schlimm ist) und wird anhand der Zählerimpulse sowie vergangene Zeit sowie K-Faktor und Menge in ccm/s durchgeführt. Bedeutet, das jeder Impuls einen festen Wert bedeutet der der Lackmenge entspricht. Auf Dinge wie Viskosität etc. wird keine Rücksicht genommen. Also die Analogbaugruppen kommen da garnicht in Betracht, da die damit nichts zu tun haben. Der Zähler wird versorgt von einem Durchflusssensor, der pro Impuls 0,2ccm wiederspiegeln soll.

Die Problematik wäre ja das er den Durchfluss genauer regeln möchte, ohne das Teile dauernd in den Ausschuss oder Nacharbeit kommen. Er muss aktuell bis zu 1/4el der Teile nacharbeiten lassen. Wenn ich aber "Live" den Durchfluss verändern will, so muss ich ja auch sehr schnell eingreifen und nachregeln. Daher dachte ich an die sehr viel kürzere Zykluszeit. Laut Oberflächentechnik muss ich in den Bereich unter 3ms kommen.

Zur Software-Qualität können wir ohne Anschauen nichts sagen.

Nun, es ist fast selbstredend das wenn ein Ausgang oder Merker mehrfach geschrieben wird und im Falle des Merkers sogar jedes mal eine andere Funktion erfüllt, die Qualität nicht ganz so optimal ist.
Das aber bekomme ich nach und nach in den Griff, ist nur umschreiben und nicht so arg kompliziert.

Könnte vielleicht ein großer Programmteil an eine zweite CPU ausgelagert werden? So daß die CPU nur den zeitkritischen Part zu bearbeiten hat. Könnten die Fehlschläge der Vergangenheit damit zu tun haben, daß der CPU mehr und mehr vorher ungeplante zusätzliche Aufgaben übertragen wurden?

Ohne dringende Not würde ich nicht von der S7-300 zu einer S7-1500 wechseln - da holt man sich ungeahnte Probleme ins Haus, wenn man mit dieser Migration noch wenig Erfahrung hat.

Eine zweite CPU wäre für diesen Part vielleicht eine Möglichkeit, allerdings sehe ich da eher da mehr Probleme drin. Das Programm ist so ineinander verstrickt das ich einen Großteil auseinanderreißen muss. Zum Teil werden Merker gesetzt die im gleichen Zyklus benötigt werden, als Flanke. Würde ich eher ungerne machen, das ist sehr viel Arbeit.
Die Anlage wurde damals aufgestellt und das was in der HMI und Anlagenbeschreibung drin ist, ist auch programmiert. Nur das eben ein Großteil nicht funktioniert oder nicht richtig, und dann Workarounds erstellt wurden, die aber auch keine volle Funktion erstellen. Also von ungeplanten Aufgaben würde ich hier weniger reden. Leider vielmehr von versucht und nicht geschafft.

300er auf 1500er habe ich in diesem Jahr alleine über 30 hochgerüstet. Das Migrieren wäre nicht das Problem. Wie erwähnt, ist im Zuge der HMI-Tauschaktion das gesamte Projekt bereits ins TIA migriert worden und alle auf einer 1500 nicht lauffähigen Konstrukte wurden umgearbeitet. Funktionen sind 1:1 erhalten geblieben, Probleme auch ^^.

Ich würde mich Harald anschließen und auf eine 314-6EH04 gehen. Die hat auch gleich Profinet dabei und das volle Rack konnte man z.b. mit einer ET200M Profinet erweitern. Oder dezentrale Peri mittels Et200, Beckhoff io.......

Ich habe gelesen, dass du schon Profinet hast.

Der Weg hätte auch noch den Vorteil, das nicht viel umverdrahtet werden muss, es wenig Risiken gibt und du ein stabiles System hast.

An die dezentrale Peripherie hatte ich ja schon gedacht, ET200 eben.
Und wenig umverdrahten klingt immer gut.



Ich werde nachher einmal das Projekt zum Testen auf eine alte 313er die ich noch da habe sowie auf die 315er laden. Mal schauen, was da an Zyklusveränderung bei rumkommt wenn die ganze Peripherie nicht da ist.
Problem ist am Ende ja, wenn ich Bauteile tausche, muss es auch laufen.
Ich werde mich nachher nach dem kleinen Test nochmal dazu äußern.

 

[DeltaMikeAir]

Hier mal ein Vergleich der technischen Daten deiner 313 mit der 314-6EH04:


https://support.industry.siemens.com/cs/pd/495261?pdti=pi&dl=de&lc=de-WW

Umrüstung auf 1500ér oder nicht, letztendlich kommt es wohl darauf an, wieviel darf der Umbau kosten, wie lange darf er dauern und wie lange soll die Anlage noch laufen.

Wir rüsten öfter mal 300ér hoch auf leistungsstärkere 300ér. Meistens da wir mehr Speicherkapazität benötigen wenn wir neue Sorten in Abfüll/Verpackungsmaschinen
einfügen oder wenn die Zykluszeit grenzwertig wird.

Der Vorteil ist eben, dass es sehr schnell geht und man ggf. auch innerhalb weniger Minuten wieder zurückbauen kann falls es unerwartete Probleme gibt.

 

[escride1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Also,

ich habe die beiden CPUs miteinander verglichen und bin auf 22ms Zyklus heruntergekommen mit der 315 und auf 31ms mit der 313er. Angemerkt, die gesamte Peripherie hängt nicht dran.
Die Werte bleiben also problematisch für eine Regelung.

Ich habe dann das ganze auf einer 1515 die ich noch da habe aufgespielt und konnte einen Zyklus unter 1ms erreichen.

Bedeutet für mich erstmal das die Wahl einer 1500er womöglich die beste Option ist.


Dennoch habe ich einen Spezialisten für diese Anlagenart kontaktiert um von ihm eventuell eine Alternative anbieten zu lassen bzw. ihm mitgeteilt das er mir dem "aktuellen Standard" entsprechend aufzeigen soll wie diese Regelung am optimalsten gehandelt wird. Werden womöglich externe Bauteile sein, aber wenn es läuft, besser als rumzumurksen.

Ich warte das nun also ab.

Erstmal Vielen Dank.

@DeltaMikeAir
Das Bild Retrofit.jpg lässt vermuten das Du da irgendwo eine Möglichkeit hast die CPUs auszuwählen und gegeneinander zu vergleichen. Ist dem so? Wo würde das gehen?

 

[Holzmichl]

Ich habe bei einer Anlage letztes Jahr aus genau den selben Gründen von 313C-2DP (6ES7313-6CF03-0AB0 V2.0) gegen 314C-2PN/DP (6ES7314-6EH04-0AB0 V3.3) getauscht.
Zykluszeit vorher 20-22ms; mit Ausreißern Richtung 30ms - nachher stabil 1 - 2ms ohne Ausreißer.
Grund für den Tausch 313 gegen 314 war die Zykluszeit, Profinet+Profibus und auch die Umrüstung übers Wochenende war kein Problem.
Aktuell mit Durchfluss- und Prozessregelung plus 50% Erweiterung der Anlage bin ich bei 3-4ms.
Final bleibt es trotzdem deine Entscheidung

 

[DeltaMikeAir]

@escride1
Nein, das habe ich per Printscreen und MsPaint
aus den technischen Daten selbst erstellt

 

[Holzmichl]

Zuviel Werbung?
-> Hier kostenlos registrieren

@escride1
Nein, das habe ich per Printscreen und MsPaint
aus den technischen Daten selbst erstellt

In deinem Vergleichsbild ist dir glaube ich ein Fehler unterlaufen.
Die Zykluszeiten sind vertauscht in den beiden CPU-Spalten

 

[DeltaMikeAir]

Ja, stimmt

 

[Ingmar64]

Warum laufen die Berechnungen nicht in einem Zyklus-OB (OB35) mit konstantem Zyklus?

 

[Sarek]

Zuviel Werbung?
-> Hier kostenlos registrieren

Schon mal an ne VIPA 313SC gedacht?
Da solltest du an ähnliche Zykluszeiten wie bei S7-1500 rankommen

 

[DeltaMikeAir]

Ich habe auch eine Migration hinter mir und was mir am meißten Kopfschmerzen bereitet hat ist der fehlende Zykluskontrollpunkt.
Visualisierungen, welche mit WinCC flex / 300ér sauber liefen bereiteten mir unter TIA Runtime / 1500ér große Probleme.

Das Übersichtsbild einer Palettenkomissionieranlage hat geblinkt wie ein Weihnachtsbaum weil die Werte irgendwo im Zyklus abgeholt werden
( wo sie vor der Bearbeitung z.B. initialisiert werden oder noch berechnet wird... )

 

[escride1]

Warum laufen die Berechnungen nicht in einem Zyklus-OB (OB35) mit konstantem Zyklus?

vermutlich weil der Programmierer es nicht besser wusste. Ich weiß es nicht. Habe ich ja nicht geplant, hätte ich aber auch nicht gemacht.

Schon mal an ne VIPA 313SC gedacht?
Da solltest du an ähnliche Zykluszeiten wie bei S7-1500 rankommen

Nein. Wir haben aber bis 2011 selbst Vipa-Baugruppen verbaut mit enormen Problemen die uns heute manchmal noch nerven. Daher würden wir keine Vipa mehr von uns aus anbieten. Daher sind wir auch nicht UpToDate was es bei Vipa überhaupt noch gibt.
Da Vipa seinerzeit so oder so nie eine Funktion garantiert hat, und das zum Teil heute noch so ist, was man an diversen Beiträgen sehen kann, werden wir auch nicht nochmal Alpha-Tester werden.
Der Preisunterschied ist zwar teilweise enorm, aber wir lassen davon lieber die Finger.

Ich habe auch eine Migration hinter mir und was mir am meißten Kopfschmerzen bereitet hat ist der fehlende Zykluskontrollpunkt.
Visualisierungen, welche mit WinCC flex / 300ér sauber liefen bereiteten mir unter TIA Runtime / 1500ér große Probleme.

Das Übersichtsbild einer Palettenkomissionieranlage hat geblinkt wie ein Weihnachtsbaum weil die Werte irgendwo im Zyklus abgeholt werden

Ja, das ist nervig. Hilft nur nochmal umstrukturieren und die Daten in einen DB auslagern der dann am Ende des Zyklus kontrolliert bei Änderung beschrieben wird. Zumindest programmiere ich deshalb viele Dinge nur noch so, oder vermeide es ein Bit, Word, Int, ... innerhalb eines Zyklus mehrfach zu beschreiben.

Wie ich aber bereits an anderer Stelle erwähnte migriere ich Anlagen am laufenden Band. Große Probleme habe ich damit nicht wirklich. Zumindest bisher. Die Größe liegt dann meist bei um die 500 Variablen. Manchmal eben mehr, manchmal weniger.

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hilft nur nochmal umstrukturieren und die Daten in einen DB auslagern der dann am Ende des Zyklus kontrolliert bei Änderung beschrieben wird

Ja, so habe ich es dann auch gelöst

 

[Maagic7]

Die VIPA Ersatzt für die Siemens 314C ist

VIPA CPU314SC DPM
24DI, 16 DO, 8DIO, 4xAI, 1xAI PT100, 2A0
Speicher 512kB erweiterbar bis 2MB (jeweils 50/50% Programm/Daten)
Profibus DP Master
Konfigurierbar mit TIA Portal

Ich habe z.B. die VIPA 314SC/DPM als Ersatz für die Siemens 314C im Einsatz.
2 volle Racks, ET200 Erweiterung, Profibus, 2ter Profibus über Siemens CP-Karte
HMI an der Ethernet PG/OP. Da laufen etliche Regler, Profibuskommunikation mit anderen Anlagen,
MPI Kommunikation über Get mit mehrerne anderen 300er CPUs, Ethernetkommunikation mit mehreren
1500er über zus. Ethernet CP Karte ...
Ich habe und hatte damit keinerlei Probleme die irgendwie auf die VIPA zurückzuführen wären!

Ich habe viele VIPAs als Ersatzt für die Siemens verbaut.
Ich kann die hier immer wieder wage zitierten Meldungen, es gibt Probleme mit den VIPAs nicht nachvollziehn.
Ganz im Gegenteil. Ich bevorzuge mittlerweile die VIPAs vor den Siemens.


Das hat folgende Gründe

1. VIPA verwendet den Seed7 Prozessor, ein echter ASIC für die CPUs. Die Siemens CPUs laufen mit Softwareinterpreter
was, teilweise bei mir bei Spezialfunktionen auch schon zu Problemen geführt hat.

2. Der im Vertleich zur Siemens imense Speicherausbau und die Geschwindigkeit der VIPAs
Siemens bietet bei keiner der aktuell erhältlichen 313C/314C einen ähnlichne Speicherausbau (bei Siemens ist glaub ich bei 192kB Schluß)
(Wobei man sagen muss dass die aktuellen Siemens ähnlich gute Zykluszeiten wie die VIPA erreichen)

3. Der Speedbus der VIPAs
Die VIPA 300er Serie bieten alle einen 2ten Bus auf der linken Seite der CPU, der sogenannte Speedbus
Man kann also die VIPAs also nach links und rechts erweitern. Links am Speedbus aber nur mit den spziellen Speedbus Karten von VIPA.
Speedbus ist auch wirklich schneller als der normale 300er Bus. Zeitkritische I/O Anwendungen lassen sich hier bis zu einem bestimmten Punkt direkt in Software realisieren

4. Die VIPAs haben alle standard SD Karten,
was eine Softwareupdate ermöglicht, ohne ein PG zu benutzen.
Man kann im Büro auf einer 2ten CPU das Program draufspielen, RAM nach ROM kopieren und dann die S7.wld Datei
mit Email zum Kunden Schicken. Dieser spielt dies mit einem Standard SD-Karten-Leser auf die SD-Karte der SPS. Macht ein urlöschen und das neue Programm ist drin.

Nachteile der VIPAs

1. Alle Vipa Speed7 CPUs können keinen MCR-Stack
d.h. ist das im Originalprogramm verwendet muss man das händisch in jedem betroffenen Netzwerk in UND-Verknüpfungen ändern

2. Alle Speed7 CPUs sind 4-Akku CPUs, damit hat man diverse Probleme, wenn AWL-Programme davon ausgehen, dass eine 2-AKKU-CPU
vorhanden ist. Da 4Akku CPUs bei arithmetischen Operationen mit AKKU3=>AKKU2 den AKKU2 überschreiben (POP Anweisung), was so bei 2-AKKU-CPUs
nicht der Fall ist.

3. Bausteine werden beim Übertragen vom PG auf die CPU nicht automatisch auf die MMC geschrieben.
Bei VIPA ist immer ein RAM nach ROM notwendig, was einen CPU-STOP auslöst.

4. Die Bausteinnummern
Siemens kann glaub ich mittlerweile Bausteinnummern bis über 16000 handeln (Dank Softwareinterpreter)
Die VIPA kann glaub ich bis 4096 oder 8192.
Also erst prüfen, ob die verwendeten Bausteinnummernbereiche passen.

 

[ducati]

Min den tech. Details hast Du sicherlich recht, aber. Von vielleicht 300 Stck 300er CPUs von Siemens hatten wir hier vielleicht 3 Defekte. Von ca. 20 Vipa CPUs hatten wir auch schon 3 Defekte!
Von 20 1500er CPUs bisher noch keine Defekte... Unsere Erfahrungen halt...