Einschränkungen bei VIPA Speed7 CPUs

Schrat007

Level-1
Beiträge
17
Reaktionspunkte
1
Zuviel Werbung?
-> Hier kostenlos registrieren
Wer hat denn Erfahrungen mit VIPA-CPUs und deren Betriebssicherheit? Außerdem kann man mit Speed7-CPUs nur vier Bausteine übertragen, die dann tatsächlich in EINEM Zyklus ("gleichzeitig") aktiv werden. VIPA bestätigt das, sagt aber, dass kein Kunde damit ein Problem hätte. Ich bin sehr an Meinungen interessiert!!
 
Wir benutzen schon lange Speed7-CPU und hatten bisher keine Probleme. Ich übertrage auch mal mehrere Bausteine, bisher keine Beanstandung. Anfangs gab es Probleme mit dem FB125 (Profibusdiagnose), das funzt inzwischen. Schön ist, daß die 318 als GSD-Grundlage dient, da kann man sich etwas mehr lokalen Speicher einstellen, die VIPA benötigt auch für den SFC20 etwas mehr lokalen Speicher als eine 318. Macht i.d.R. nichts, ich bin aber genau darüber schon einmal gestolpert. Hat man viel Stringverarbeitung, ist das extrem nützlich, da Stringoperationen und Strings u.U. viel lokalen Speicher benötigen. Hier kann die VIPA dinge, die die 319 definitiv nicht mehr schluckt. Funktionssicher sind die Teile im übrigen ebenso wie Siemens.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
An alle die VIPA Erfahrung haben:

Wo liegt den die VIPA CPU preislich im Vergleich zu Siemens ???

Hat VIPA "nur" CPU n der 300er Bauform oder haben die auch andere Bauformen ???
 
Vipa

Im letzten Jahr haben wir VIPA in grösseren Stückzahlen eingesetzt. Im Grunde lief es völlig anstandslos. Da man nur mit den den NET CPU'en über Ethernet auch zwischen den CPU'en kommunizieren kann. Haben wir diese im Einsatz. Bei einer Steuerung hatten wir das Problem, dass WinCC noch zugreifen konnte, aber nicht mehr Step7. Liess sich aber mit einer neuen Firmenware beheben.
In der Regel sind die Produkte von VIPA preislich günstiger. Aber es passt halt nicht immer. Mein typisches Beispiel. Ich benötige nur eine CPU315 oder schlichter aber einen Ethernet CP für echte Kommunikation. In diesem Fall komme ich im 300terter Format bei Siemens günstiger als bei VIPA. Hier muß ich dann die Speed bezahlen obwohl ich es vielleicht nicht so leistungsstark brauche.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Mehrere Bausteine laden

Also uns hat VIPA bestätigt, dass wirklich nur vier Bausteine gleichzeitig ladbar sind. Beispiel:
Man ändert in einem FB einen Parameter oder statische Lokaldaten. Der FB sei 3x aufgerufen in verschiedenen Instanzen. Man muss also übertragen: Den FB, die drei IDBs dazu, die drei Bausteine, die den FB aufrufen. Macht in toto also 7 Bausteine. Bei Siemens kein Problem, bei VIPA nur im Stopp möglich, da sonst Inkonsistenzen auftreten und einen Stopp verursachen können.
An sonsten eine schöne Maschine, vor allem auch das Speichermanagement und die Zykluszeit (dort je nach Anwendung von gleichauf bis Faktor 10). Sehr gut auch die Möglichkeit, mehr als zwei Profibus-Master über den Speedbus anschließen zu können und alle mappen die E/A in das Prozessabbild ohne Zutun des Anwenders. Nachteil: Die CPU kann keine zwei Profibus-Master auf den eingebauten Schnittstellen wie 317/318/319 von Siemens.
Wer verwendet denn GRAPH7 auf Vipa-CPUs? Da hatten wir schon Probleme.
 
Unsere Erfahrungen

Wir verwenden fast ausschließlich Vipa-CPU's (200er und 300er sowie 300S), so daß ich im Vergleich zu Siemens nichts direkt sagen kann. Für uns existieren aber folgende Auffälligkeiten der Vipa-CPU's:
- beim Übertragen von Bausteinen läuft der Speicher mit der Zeit voll und muß komprimiert werden. Das ist besonders lästig, wenn man sowieso schon bei 90% ist und so nach jeder Übertragung komprimieren muß.
- dafür entfällt das Übertragen RAM->ROM
- DBs sind bei allen CPU's remanent (ist manchmal lästig, aber meistens praktisch)
- Speed7 ist rasend schnell, für Zykluszeiten >10ms braucht man schon sehr viele Float-Operationen, mit "normalen" Befehlen ist das nicht zu schaffen
- die Übertragung von/zur seriellen Schnittstelle (RS232), egal ob integriert oder auf CP, ist sehr langsam und für Steuerungsaufgaben faktisch nicht brauchbar
- teilweise treten bei FB-Aufrufen (bei allen CPU's) Effekte auf, die entweder von einem Compilerproblem (wir verwenden Step7 5.4) oder von einem Verwaltungsproblem auf der CPU herrühren: in der Variablentabelle und im aufrufenden FC/OB haben die übergebenden Variablen einen Wert, beim Beobachten des FB selber einen anderen (und der FB arbeitet auch so, wie er mit den falschen müßte). Einzige Abhilfe (auch Urlöschen hilft nicht): anderen Instanz-DB verlinken
- wenn sich Ausgangs-Variable während des Zyklus ändern (z.B. prinzipiell erstmal genullt werden) aber zum Zyklusende stabil sind, ist die Anzeige im Vipa-Touchpanel alternierend
- Graph läuft auf allen CPU ohne Probleme (außer Speicherplatzverbrauch), auch mit mehreren IDB, dann allerdings muß man sich im Step7 um die Aktualisierung der IDB selber kümmern (geht wohl nicht auf Kosten von Vipa)
- vom PG über PB-Master auf PB-Slave-CPU durchgreifen geht nicht mit 200er CPU's
- Hotline ist immer sehr engagiert und meistens erfolgreich
Interessant wäre jetzt für uns, welche Probleme davon auch bei "echten" S7-300 auftreten.
 
Diese "FB/FC-Effekt" ist mir auch bekannt, betraf aber bisher immer nur die Anzeige. Ein Befehl vor dem Bausteinaufruf, wie z.Bsp. ein SET hat das bisher immer behoben. Muß ich mir auch mal ansehen.

PS. VIPA arbeitet daran, schein nicht so einfach zu sein, kann auch sein, daß es bei den neusten FW schon abgestellt ist.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
An Ingmar64

- Speed7 ist rasend schnell, für Zykluszeiten >10ms braucht man schon sehr viele Float-Operationen, mit "normalen" Befehlen ist das nicht zu schaffen
--> Wir haben hier bei einer Anlage 30ms, vergleichbare Anlagen liegen bei 12ms auf einer 319. Anderes Beispiel: 8ms auf VIPA 317SN, 22ms auf CPU317 (Siemens), hängt also schon vom aktuellen Projekt und dessen Zusammensetzung ab.

- teilweise treten bei FB-Aufrufen (bei allen CPU's) Effekte auf, die entweder von einem Compilerproblem (wir verwenden Step7 5.4) oder von einem Verwaltungsproblem auf der CPU herrühren: in der Variablentabelle und im aufrufenden FC/OB haben die übergebenden Variablen einen Wert, beim Beobachten des FB selber einen anderen (und der FB arbeitet auch so, wie er mit den falschen müßte). Einzige Abhilfe (auch Urlöschen hilft nicht): anderen Instanz-DB verlinken
--> Das sieht nach inkonsistenten Bausteinen aus, wir übersetzen dann die Quellen neu. Kann man im Bausteinordner prüfen (Bearbeiten->Bausteinkonsistenz prüfen). Dann unter "Ansicht->Abhängigkeitsbaum nur Konflikte". Da ist dann eine Liste der nicht korrekt zusammen passenden Bausteine.

- Graph läuft auf allen CPU ohne Probleme (außer Speicherplatzverbrauch), auch mit mehreren IDB, dann allerdings muß man sich im Step7 um die Aktualisierung der IDB selber kümmern (geht wohl nicht auf Kosten von Vipa)
--> Das muss man bei mehreren immer! Kann man sich aber eine Quelle machen, wo alle drinstehen und die dann übersetzen, NACHDEM man den Graph-Baustein geändert hat.

- Hotline ist immer sehr engagiert und meistens erfolgreich
--> Stimmt! Falls einer mitliest, an dieser Stelle nochmal vielen Dank.

Das sind also weiß Gott nicht alles VIPA-Effekte. Soweit zur Beruhigung :)
 
An Schraat007

Ich bin mir ziemlich sicher, daß es keine Inkonsistenzen sind, denn es werden keine Konflikte gefunden und auch das gesamte Projekt neu übersetzen bringt wie gesagt nichts.
Verblüffenderweise tritt dieser Effekt teilweise auch plötzlich erst nach einiger Betriebszeit auf (manchmal Stunden, manchmal Tage).

An Ralle:
Manchmal funktionierte es wirklich so, meistens aber nicht.
 
An Ingmar64

- Speed7 ist rasend schnell, für Zykluszeiten >10ms braucht man schon sehr viele Float-Operationen, mit "normalen" Befehlen ist das nicht zu schaffen
--> Wir haben hier bei einer Anlage 30ms, vergleichbare Anlagen liegen bei 12ms auf einer 319. Anderes Beispiel: 8ms auf VIPA 317SN, 22ms auf CPU317 (Siemens), hängt also schon vom aktuellen Projekt und dessen Zusammensetzung ab.

Hallo,

mich würde das Projekt, bei dem die 319 so viel schneller ist, sehr interessieren! Die 319 ist eigentlich nur bei Floating Point und SFCs/SFBs richtig viel schneller! Da scheint wohl irgendwo noch viel optimierungspotential zu sein, dass wir noch nicht entdeckt haben.


Grüße
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

mich würde das Projekt, bei dem die 319 so viel schneller ist, sehr interessieren! Die 319 ist eigentlich nur bei Floating Point und SFCs/SFBs richtig viel schneller! Da scheint wohl irgendwo noch viel optimierungspotential zu sein, dass wir noch nicht entdeckt haben.


Grüße

Mir ist (denn ich habe auch nachgemessen) aufgefallen, dass unter anderem bestimmte Systemfunktionen (GADR_LGC, RDSYSST) auf der 319 schneller laufen. Bei den Bausteinen DPRD_DAT und DPWR_DAT steht der Test noch aus. Ich kann ja die Ergebnisse dann auch bekanntgeben.
 
Mir ist (denn ich habe auch nachgemessen) aufgefallen, dass unter anderem bestimmte Systemfunktionen (GADR_LGC, RDSYSST) auf der 319 schneller laufen. Bei den Bausteinen DPRD_DAT und DPWR_DAT steht der Test noch aus. Ich kann ja die Ergebnisse dann auch bekanntgeben.

Danke!

Die für mich interessante Frage wäre jetzt aber, für welchen Anwendungsfall ein derart intensiver Gebrauch von Systemfunktion von Bedeutung ist, um so einen Unterschied zu erzeugen?
 
Danke!

Die für mich interessante Frage wäre jetzt aber, für welchen Anwendungsfall ein derart intensiver Gebrauch von Systemfunktion von Bedeutung ist, um so einen Unterschied zu erzeugen?

Nur zur Info: das war EIN Effekt, da kommt sicherlich mehreres zusammen. Zur Frage: Da sind 75 Servoantriebe über Profibus angekoppelt, da kommt schon was zusammen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Nur zur Info: das war EIN Effekt, da kommt sicherlich mehreres zusammen. Zur Frage: Da sind 75 Servoantriebe über Profibus angekoppelt, da kommt schon was zusammen.

Die Profibus-Zykluszeit hat, wenn keine GSD-Datei bei der Speed7-CPU eingebunden ist, keine Auswirkung auf die SPS-Zykluszeit. (Man kann die Zyklen koppeln, ist aber nur eine Option)

Mir ist bis jetzt noch kein real eingesetztes Anwenderprogramm untergekommen, dass solch große Unterschiede unter gleichen Bedingungen gezeigt hätte.
Mir geht es ja nur darum herauszufinden, woran so etwas liegen kann.
 
Die Profibus-Zykluszeit hat, wenn keine GSD-Datei bei der Speed7-CPU eingebunden ist, keine Auswirkung auf die SPS-Zykluszeit. (Man kann die Zyklen koppeln, ist aber nur eine Option)

Mir ist bis jetzt noch kein real eingesetztes Anwenderprogramm untergekommen, dass solch große Unterschiede unter gleichen Bedingungen gezeigt hätte.
Mir geht es ja nur darum herauszufinden, woran so etwas liegen kann.

Nein, die Profibus-Zykluszeit natürlich nicht. Aber 75 Servoantriebe sind 150 Aufrufe DPRD_DAT und 150 Aufrufe DRWR_DAT. Da spielen auch Mikrosekunden plötzlich eine Rolle. Die Aufrufe für LGC_GADR sind nur im Anlauf, die Aufrufe für RDSYSST sind nur 2 pro Zyklus.
 
Nein, die Profibus-Zykluszeit natürlich nicht. Aber 75 Servoantriebe sind 150 Aufrufe DPRD_DAT und 150 Aufrufe DRWR_DAT. Da spielen auch Mikrosekunden plötzlich eine Rolle. Die Aufrufe für LGC_GADR sind nur im Anlauf, die Aufrufe für RDSYSST sind nur 2 pro Zyklus.

Danke! An den Themen DPRD_DAT und Co. wird gearbeitet.

Frage aus Interresse: Was würde dagegen sprechen die Servo-Daten in das Prozessabbild zu Mappen und ohne DPRD_DAT zu arbeiten, in der Speed7-CPUs sind die Daten trotzdem konsistent. Diese Methode ist deutlich schneller! (Laut SIEMENS Handbuch geht es auch mit CPU318 und CPU400)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Danke! An den Themen DPRD_DAT und Co. wird gearbeitet.

Frage aus Interresse: Was würde dagegen sprechen die Servo-Daten in das Prozessabbild zu Mappen und ohne DPRD_DAT zu arbeiten, in der Speed7-CPUs sind die Daten trotzdem konsistent. Diese Methode ist deutlich schneller! (Laut SIEMENS Handbuch geht es auch mit CPU318 und CPU400)

Haben wir auch überlegt. Wir schreiben aber unsere Software sehr standardorientiert, also auf einer breiten Palette von Hardware ohne Änderung lauffähig. Sonst bekommen werden die Erstellungskosten für die Software zu hoch. Und die Methode mit DPRD_DAT und DPWR_DAT ist die einzige, die auf ALLEN S7-CPUs läuft. Wobei wir S7-400 fast nie im Einsatz haben, dafür gibt es eigentlich keinen vernünftigen Grund, gerade seit Speed7.
Schade eben nur, dass es beim Übertragen die Grenze mit 4 Bausteinen, die man in einem Zyklus aktivieren kann, gibt. Sonst wäre das unsere Standard-Maschine. Müssen wir uns wohl in Geduld fassen und bie dahin 319 einsetzen.
 
Haben wir auch überlegt. Wir schreiben aber unsere Software sehr standardorientiert, also auf einer breiten Palette von Hardware ohne Änderung lauffähig. Sonst bekommen werden die Erstellungskosten für die Software zu hoch. Und die Methode mit DPRD_DAT und DPWR_DAT ist die einzige, die auf ALLEN S7-CPUs läuft. Wobei wir S7-400 fast nie im Einsatz haben, dafür gibt es eigentlich keinen vernünftigen Grund, gerade seit Speed7.
Schade eben nur, dass es beim Übertragen die Grenze mit 4 Bausteinen, die man in einem Zyklus aktivieren kann, gibt. Sonst wäre das unsere Standard-Maschine. Müssen wir uns wohl in Geduld fassen und bie dahin 319 einsetzen.


Vielen Dank für die Anregungen.
Wir arbeiten an diesen Punkten, dauert aber noch.
 
Zurück
Oben