Erfahrungen MoviSuite / UHX-Controller

O

Olli_BS

Level-2
Beiträge
503
Reaktionspunkte
120
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich möchte mal Erfahrungen zur neuen SEW-Welt sammeln.
Meine persönlichen:
- MonsterWare (Speicherplatz, Installationsdauer) [nächste Version soll Updater bekommen !)
- Bedienoberfläche hat etwas von Jemands-Selbstverwirklichung (WIndows Standard-Bedienelemente neu erfinden, unten Links klicken für "zurück")
- Parameter Anordnung = "naja". Hat bei mir etwas gedauert, bis ich verstanden habe das ganz viel unter "Überwachungsfunktion" zu finden ist und Sollwerte/Istwerte in der Praxis fast irrelevant ist. Suchen und fluchen....
- Controller umständlich, sehr viele (wichtige) Detail-Einstellungen wild verstreut, Adressenoffset schon selber zählen/rechnen und je Achse eintragen. Insgesamt kostet ein Controller sehr viel Zeit (Vorteil von gesparten Busoptionskarten ist damit dahin)
- Oft (zuoft !) Warmstart erforderlich (vorher als nicht PowerUser unklar, bei welche Änderung was erfolgt)
- Keine Status/Fehleranzeige in Movisuite von Interpolier Movikit-Halbschalen. Nur im IEC-Editor Feldbus Monitor (und auch nur Nr., kein Text) >> Ein No-Go.
[Aber dafür Kreis-Projektansicht, Default-Darktheme, MainButton Oben rechts (wie die coolen Internet-Browser) : Klare Prioritäten]
- Die 3 verschiedenen Datenspeicher (FU/SD XML/SD IEC-Prog.) führen relativ schnell zu Inkonsistenz und Unsicherheit beim Benutzer

+ Drehmomentbegrenzung mit Positionierung zusammen geht gut und simple (im Moment der größte Mehrwert aus meiner Sicht)
+ Handbetriebsmenu (einfaches Hin und Her Fahren zum Einmessen)
 
Leider sind manche Funktionalitäten (allerdings Stand 2022, dann haben wir aufgegeben) nicht sauber zum funktionieren zu bringen, wie z.B. Synchronlauf mit veränderlichen Getriebe. Soll laut SEW gehen, aber SEW hat es auch nach etlichen Sitzungen nicht richtig zum Laufen gebracht. Es gab immer wieder ruppige Starts und Stops bis hin zu Fehlerstops beim Starten und Stoppen der gekoppelten Achsen. Dank Trace im TIA konnte ich zumindest ausschließen, daß die SPS hier was versaut. Also Workaround: Die SPS reicht die Istwerte der einen Achse multipliziert mit dem Getriebefaktor an die anderen Achsen als Sollwert weiter. Zumindest für unsere Anlage reicht es so, sauber ist es eigentlich auch nicht. Und dafür brauche ich keinen teuren UHX-Kontroller.
Und das Konzept, daß ich Änderungen im Umrichter in den Kontroller einpflegen muß, finde ich unmöglich. Viele Änderungen, die bei Movi B im Betrieb gingen gehen hier nur noch im Stillstand.
Und zumindest damals hat die sonst sehr gute Hotline bei dem Wort "Movi C" sofort abgewinkt.
Die Idee für Movi C + Kontroller finde ich schon gut, aber abgesehen vom Design ist davon zu wenig in die Realisierung gekommen.
Dann kommen solche Dinge hinzu wie eine langsame PN-Schnittstelle (>50ms laut TIA-Trace) des Kontrollers, was mir keiner erklären geschweige denn abstellen kann.
Vielleicht wäre der Weg zu Standard-Schnittstellen, wie sie z.B. von Siemens verwendet werden besser. Dann könnte man sich (und auch SEW, denn dort bindet das ja auch Ressourcen) mit Standardfunktionen in der SPS weiterhelfen.
 
Ingmar64 schrieb:
Dann kommen solche Dinge hinzu wie eine langsame PN-Schnittstelle (>50ms laut TIA-Trace) des Kontrollers, was mir keiner erklären geschweige denn abstellen kann.
Zum Vergrößern anklicken....
Eigentlich habe ich darauf gesetzt, das Sie wie versprochen <= 1ms können,
also wieder nur Marketing Geschwafel. Besser währe es gewesen wenn Sie
die Schnittstellen Performance hoch gesetzt und die Automatisierung
den SPS Herstellern überlassen hätten.
Die heutigen SPSen wie Siemens oder Beckhoff können die Motion Funktionalität
spielend mit machen und man schaut dann nur auf einer Automatisierungssoftware.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Tja, so alt auch die MDX61 sind, so flexibel sind sie auch mit IPOS.
Eine Weiterentwicklung oder wenigstens ein Kompatibelitätsmodus hätte mir als Kunde deutlich besser gefallen. Evolution statt Revolution 😀
 
Die Zykluszeit des Kontrollers bekomme ich eventuell auf unter 1ms. Aber wenn ich die Istwerte der Achsen über PN einlese, bekomme ich nur >50ms einen geänderten Wert. Dabei ist das Lesen/Schreiben auf die Schnittstelle im Controller im 1ms Zyklus enthalten.

Ich muß allerdings zugeben, daß ich keinerlei Erfahrungen mit dem Verhalten der Standalone Movi C habe. Vom Lehrgang weiß ich nur, daß die Konfiguration wesentlich komplexer als bei Movi B ist.
 
Ingmar64 schrieb:
Die Zykluszeit des Kontrollers bekomme ich eventuell auf unter 1ms. Aber wenn ich die Istwerte der Achsen über PN einlese, bekomme ich nur >50ms einen geänderten Wert. Dabei ist das Lesen/Schreiben auf die Schnittstelle im Controller im 1ms Zyklus enthalten.

Ich muß allerdings zugeben, daß ich keinerlei Erfahrungen mit dem Verhalten der Standalone Movi C habe. Vom Lehrgang weiß ich nur, daß die Konfiguration wesentlich komplexer als bei Movi B ist.
Zum Vergrößern anklicken....
Das mit den sehr langsamen einlesen der Positionswerten ist mir schon
bei den Moviaxis System auf die Füße gefallen und musste es umschiefen,
das ich einen externen Geber an die Steuerung anschließen musste.
Selbst das weiterreichen der Gebersignale über Moviaxis Geberausgang
auf einer Geberkarte im ET200sp Format funktionierte nicht.
Da weiß ich nicht an wenn es gelegen hat Siemens oder SEW, die Signale
brachen weg.

Ich weiß es nicht wirklich Ethercat ging doch bei Moviaxis schnell, wie ist
das bei Movi C geht das schnell?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich habe gerade mir mal gerade einen TIA Trace von UHX-Istwerten angesehen und komme auf Änderungen im ca. 20ms Raster (CPU Zyklus Zeit ca10ms). Ist der Kleinste (UHX25) Controller der intern mit 1ms läuft (und auch hart an seiner Perfomance Grenze arbeitet ...)
 
Ingmar64 schrieb:
Leider sind manche Funktionalitäten (allerdings Stand 2022, dann haben wir aufgegeben) nicht sauber zum funktionieren zu bringen, wie z.B. Synchronlauf mit veränderlichen Getriebe. Soll laut SEW gehen, aber SEW hat es auch nach etlichen Sitzungen nicht richtig zum Laufen gebracht. Es g
Zum Vergrößern anklicken....
Mal aus Neugier: Was war denn da überhaupt der Weg:
Über SingleParameterAccess das "i" ändern und sonst alles Standard
oder
hab ihr ein spezielles IEC-Prog bekommen/gemacht?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Im Programm des UHX gibt es Parameter Zähler und Nenner für den Synchronlauf. Die werden normalerweise nur aus der Inbetriebnahme beschrieben bzw. beim Laden des Programms in den UHX. Diese Parameter wurden zusätzlich auf die Schnittstelle gelegt und konnten so von der SPS aus beschrieben werden. Diese Idee hat prinzipiell auch funktioniert. Wir haben dabei mit einem virtuellen Master gearbeitet, alle Slave-Motoren blieben ständig eingekuppelt. Trotzdem kam es bei Starten und Stoppen des Masters offenbar immer mal wieder zu plötzlichen Änderungen des Drehzahlsollwertes für eine der Slave-Achsen (Asynchronmotor, alle anderen Synchronmotoren), wodurch diese Achse und damit der gesamte Verbund in Störung ging oder es auch manchmal "nur" mechanisch knallte.
Die jetzige Lösung, ein Motor als Master und dessen Istwerte über die SPS umgerechnet als Sollwerte für die anderen Achsen hätte man sicher auch ohne UHX mit MoviDrive B preisgünstiger realisieren können. Zum Glück fahren wir lange Rampen und es ist genug Spiel im System, dadurch bleiben die entstehenden Verzüge im System unauffällig.
SEW hatte dabei die Konfiguration für diesen Zweck abgenickt und war auch etliche Tage bei uns für die Inbetriebnahme zu gange. Der sporadische Fehler ließ sich aber nicht eingrenzen, deshalb der Workaround wie beschrieben.
Was sich auch als zwar theoretisch möglich aber praktisch unrealisierbar herausstellte, war die Einbindung zusätzlicher, von den Motoren unabhängiger Streckengeber (Absolutwertgeber). Hier war das Überlaufverhalten nicht in den Griff zubekommen, da immer irgendeine Umrechnung wirksam ist und der Überlauf also zu krummen Werten der übermittelten Istposition stattfindet. Hier mussten wir dann zu zusätzlichen Profinet-Gebern wechseln und den Überlauf in der SPS berücksichtigen.
Bei den externen Gebern ist uns auch aufgefallen, das die istwerte so langsam aktualisiert werden, als wir aus ganz anderen Gründen einen Trace über den Weg gemacht haben. zu Testzwecken hatte ich auch mal das gesamte SPS-Programm deaktiviert um die Zykluszeit zu kürzen, es blieb bei >50ms für neue Positionsdaten.
 
Hat jemand schon Erfahrungen mit V2.5? (Ich nicht)
Den Release Notes nach hat sich ja bei den Movikit-Versionen nicht viel getan.
Also fast "nur" die Assistenten ?

Witzig fand ich ja die Tabs (glaube ab V2.4) Eigentlich bin ich großer Fan von Tabs, aber hier helfen die mir so gar nicht, da ich als Gelegenheits-User fast nie etwas direkt finde, sondern ziemlich viel angeklickt habe bis zum Fund. Also Tableiste immer voll...

Grundsätzlich sind bei mir 2 Erfahrungen hängengeblieben:
- Sehr vieles was man im Nachhinein anpassen möchte ist unter "Überwachungsfunktionen" versteckt.
- Bei Problemen jeglicher Art "IEC-Projekt neu erstellen" auswählen (wenn man soviel Zeit hat)
 
Zurück
Oben