Allgemeine Meinung zu Calypso

[[An...]]

Hallo zusammen,

ich bin nach mehreren Jahren Programmiertätigkeit auf diversen Messprogrammen in ein Unternehmen gewechselt, welches Zeiss Calypso als Standardsoftware nutzt.
Zeiss Calypso gilt mit seinem immensen Marktanteil ja schon fast als Industriestandard, daher könnte man meinen, der "Mercedes der Messtechnik" sei den anderen Markteilnehmern deutlich überlegen.

Kurz und knapp: ich kann diese Annahme nicht bestätigen und muss leider sagen, dass ich von Zeiss und insbesondere von Calypso enttäuscht bin.

Zuerst meine positiven Eindrücke über Calypso:

• die Tastereinmessung: es könnte kaum einfacher sein, neue Taster zu erstellen - einfach antasten und los. Keine nervige manuelle Eingabe diverser Tasterdaten.

• der Marktanteil: viele Partner arbeiten ebenfalls mit Zeiss, was den Messwertabgleich deutlich vereinfachen kann.

• PiWeb: eine sehr gute Software, insbesondere die einfache Statistikauswertung

• die hohe Wiederholgenauigkeit hat mich ziemlich überrascht

• Schneller und unkomplizierter Service seitens Zeiss

Meine negativen Eindrücke:

• Übersichtlichkeit: man merkt Calypso sein Alter an und dass es ursprünglich mit geringerem Funktionsumfang veröffentlicht wurde. Man findet Funktionen in Untermenüs wo sie eigentlich nicht hingehören und sucht sich teilweise die Finger wund. Dass die Buttons mit 7.4 die gleiche Farbe bekommen haben, macht das ganze nicht gerade besser...

• Fehlende Kollisionserkennung: ja es gibt "Planner". Warum muss man sich allerdings eine Offline-Lizenz kaufen, wenn man nur "am Bauteil" programmiert, um in den Genuss einer Kollisionserkennung zu kommen? Ich verstehe einfach nicht warum ein so elementares Sichereitsfeature nicht zur Standardaustattung gehört.

• Autorun: eine Erweiterung die nichts anderes machen sollte als Copy+Paste. Ich habe es leider schon fast aufgegeben, da es keinen sichtbaren Grund für die zahlreichen Abbrüche gibt. Außerdem werden meines Wissen keine Messpunkte gespeichert, was eine nachträgliche Auswertung unmöglich macht (vielleicht irre ich mich hier)

• Optik der O-Inspekt: zahlreiche Bugs, keine richtige Implementierung in Calypso, fehlende Funktionen

• Zahlreiche Punkte z.B.: fehlende nachträgliche CAD-Verschiebung im Programm, Zahlreiche Abstürze, grundlegende Funktionen nur über Umwege oder Zusatzlizenz erreichbar, schlechte 3D-Connexion-Funktionalität, Multi-Window nicht möglich, geringe Individualisierungsmöglichkeiten, usw...

Befindet sich seitens Zeiss eigentlich bereits ein Nachfolger von Calypso in Arbeit? - Ich kann mir nicht vorstellen, dass man hier noch jahrelang "Evolution statt Revolution" betreiben kann.

Mir geht es nicht darum, Calypso schlechtzumachen, mich interessieren einfach welchen Allgemeineindruck ihr von Calypso habt.

Beste Grüße
Andreas

[[No...]]

Oha, da hast du jetzt vielleicht die Büchse der Pandora geöffnet 🤣

Please sign in to view this quote.

Man gewöhnt sich an alles...
Was mich allerdings in den letzten 33 Jahren immer wieder gewundert hat, ist Zeiss' Hang zu eher exotischen Entwicklungsplattformen. [list=]

UMESS 300, womit ich gelernt habe, basierte auf einer von HP abgekündigten BASIC-ähnlichen Programmiersprache aus den 70ern. Die wird in ähnlicher Form noch heute in den Steuerungs-Makros verwendet

UMESS-UX wurde in den 90ern auf UNIX entwickelt, als alle anderen schon auf PCs setzten

Calypso basiert auf Smalltalk, das seine Wurzeln auch schon tief in den 70ern und 80ern hatte und sicher für die eine oder andere Eigenart von Calypso verantwortlich ist.

Please sign in to view this quote.

Ich wüßte nicht, daß Planner eine Kollisionserkennung in dem Sinne hat, wie du sie dir wahrscheinlich vorstellst.
Ich dachte früher (bevor ich Calypso tatsächlich genutzt habe) auch immer, wenn man ein CAD-Modell hat, muss die Kiste doch erkennen können, wie sie es zu umfahren hat. Aber nein...
Planner bemerkt eine Kollision auch erst wenn sie passiert ist. Es geht halt nur nichts kaputt dabei. Und blind drauf verlassen sollte man sich auch nicht in jedem Fall, weil Planner bis heute nicht in der Lage ist, die Maschine zu 100% korrekt zu simulieren. Sonst würde nicht mal eben das Portal über den Tisch hinausfahren, um einen Punkt zu erreichen oder in manchen Fällen das Werkstück durch die Granitplatte hindurch angefahren werden. 🤣

Please sign in to view this quote.

Wir fahren mit Autorun unsere gesamten Serien-Messungen. Es ist ganz brauchbar, wenn auch die Oberfläche etwas unordentlich und verspielt wirkt, wenn man sie nicht pflegt. Deine Probleme kann man umschiffen, aber es könnte in der Tat einfacher sein.

Please sign in to view this quote.

DA triffst du bei mir mal voll ins Schwarze. Das habe ich von Anfang an gedacht, als wir die Maschine bekommen haben. Da merkt man an allen Ecken und Enden, daß Calypso für sowas nicht gemacht wurde und die Funktionen nachträglich aufgepfropft wurden. Vielleicht nicht bei 08/15 Programmen, aber wenn man Calypso's Möglichkeiten ausreizen will, vertrödelt man anfangs sehr viel Zeit mit nervigen Bugs.

Please sign in to view this quote.

Das würde mich auch mal interessieren. Ich hätte längst damit gerechnet, aber anscheinend will man die greise Kuh noch ein paar Jährchen melken 🤣

[[Ka...]]

Moin Andreas,

Zum Planner:
Ein Stück teure Software die wohl aus einer Auftragsarbeit eines großen Kunden entstanden und nach Ablieferung entwicklungstechnisch in die Versenkung geraten ist. Wie Norbert schrieb: Kollision gegen die eigene Geometrie wird so gut wie nie erkannt: Schaftantastung und ähnliches nur bei viel Glück...
Die Software ist gut zu nutzen um ein Programm im Groben vor zu bereiten; mehr aber leider auch nicht.

Zur Weiter/Neuentwicklung von CALYPSO:
Ich hörte aus 1. Quelle, dass Zeiss an einer 64Bit Version arbeitet. Ein Zeithorizont wurde aber nicht genannt. Aus dem Kontext des Gespräches erahne ich aber das es mindestens noch eine 7.8 Version geben wird. Also werden wir noch einige Jahre mit dem jetzigen Konstrukt leben müssen.
Und ob eine Neuentwicklung wirklich "besser" ist oder einfach nur mehr "Bunti-Klicki" enthält... Wer weiß das schon. Böse gesprochen sind mir ältere Softwareentwicklungen lieber weil da die Programmierer noch mehr Zeit bekommen haben um Ihre Aufgaben gründlich zu erledigen.

Programmieren heute:

Brain(OFF);
code = Chat_gpt_query("Write me a programm");
nicer(code);
fwrite(fd,code);
Brain(ON);
😃 😃 😃

Gruß
Karsten

[[Da...]]

Please sign in to view this quote.

:D

[[Mi...]]

Mich ärgern ja am meisten die fehlenden Sicherheitsfeatures. Wenn ich ein Programm bereits an einer Station offen habe und an einer anderen das ebenfalls öffne kommt nichtmal eine Nachricht das es bereits geöfnet ist. Und wenn diese zwei Stationen dann gleichzeitig damit arbeiten übeschreiben die sich gegeseitig die Daten und es kommt nur Müll raus der nicht nachzuvollziehen ist. Richtig doof wenn man grad dabei ist seine Maschinenfähigkeit statistisch auszuwerten möchte und nebenbei noch Messungen durchführt.

Das Paket mit der Simulation ist eine einzige Katastrophe weil man zum Beispiel mit kleinen Tastern einfach komplett durchs Teil durchfahren kann ohne das es erkannt wird. Man kann nichtmal den Regler auf NULL runterdrehen damit die Simulation anhält und man Abstände betrachten kann wenn es mal eng wird. Es erfordert stattdessen viel Geschick im genau richtigen Moment auf = zu drücken. Es gibt keine Taste mit der ich diese Button ansteuern kann um wenigstens mit "Start" "Halt" gespamme zum richtigen Moment stehen bleiben kann. Nein eine pure Geschicklichkeitsübung.

Ich bin noch nie so schnell an die Grenzen des machbaren gestoßen wie mit diesem Programm. Das scheitert lustigerweise nichteinmal an der fehlenden Funktionialitäten sondern eher an der fehlenden und unzureichenden Dokumentation der Funktionen und den zahlreichen Paywalls hinter denen diese versteckt sind. Abhilfe kann da nur ein großer Geldbeutel und viel Zeit auf den gefühlt 1000 angebotenen Schulungen bringen.

Von den zahlreichen Bugs und random Abstürzen mal ganz zu schweigen. Einmal hat die Maschine einen Fehler geworfen aber ist ganz normal weitergefahren und hat weitergemessen. Die ganze Spätschicht über sind Teile vermessen worden die gut waren. Am nächsten Tag dann das Böse erwachen als festgestellt wurde das für drei Maße mit engen Toleranzen einfach den ganzen Abend über immer wieder der gleiche Wert in die Protokolle geschrieben wurde. Alle anderen Maße wurden ganz normal gemessen. Zum Glück ist das nur einmal passiert (wo wir das wissen). Jetzt starten wir nach jeder Fehlermeldung vorsichtshalber neu 🙄

Ich könnte ewig weitermachen deswegen jetzt noch paar positive Worte:
Das Kantinenessen auf Schulung immer eine 10/10 ! 🤣



Kleiner Spaß. Das Programm an sich ist schon gut aber die vielen kleinen Dinge die nicht passen vermiesen mir schnell die Stimmung. Es geht wahnsinnig schnell Programme lauffähig zu erzeugen und auch manuelle Messungen funktionieren einwandfrei. Ein rießiger Vorteil ist auch der einfache Austausch an Programmen mit anderen Firmen.

[[Se...]]

Please sign in to view this quote.

Dieses Problem lässt sich einfach lösen:
Auch wir haben unsere Programme zentral auf einem Server und es kommt oft vor, dass ein Programm gleichzeitig auf mehreren Stationen verwendet wird.
Man muss einfach einen eigenen Ordner für die Istwerte jeder Station definieren.
Extras -> Einstellungen -> Arbeitsumgebung -> Istwerte / Festes Verzeichnis

Ansonsten stimme ich dir zu, was den Planner betrifft: Er hat noch viel Optimierungspotenzial! Es ist wirklich bedauerlich, wenn man bedenkt, was er kostet...

Und es stimmt, dass die Software sehr mächtig ist und viele Vorteile bietet. Und genau das ist es, was die vielen kleinen Fehler so ärgerlich macht: Die Software ist doch in der Lage, so hochkomplexe Aufgaben zu bewältigen, warum müssen wir uns dann mit grundlegenden Funktionen herumschlagen, die nicht funktionieren?

[[Mi...]]

Please sign in to view this quote.

Danke für die Info 😃 Da hat sich das meckern wohl wieder gelohnt

[[Ka...]]

Moin,

Please sign in to view this quote.

Ja neee 😮
Ich will ja nicht den Spass verderben, aber so einfach ist es eben leider nicht. Es gibt einige Ablaufdaten die während des Programmablaufes in das Programmverzeichnis geschrieben und auch wieder gelesen werden. Natürlich ohne vorher zu prüfen ob da noch eine andere Instanz unterwegs ist....

protheadpara ist die Datei mit der direktesten Auswirkung denn diese Daten werden vom startenden Programm zunächst eingelesen und dann später beim CNC Start wieder beschreiben. Wurde diese aber gerade von einer anderen Instanz beschrieben hat man eine nervige Kollision von Protokollkopfdaten. Es gibt noch einige andere Dateien die beschreiben und gelesen werden doch deren Konfliktpotential habe ich nicht weiter untersucht...

CALYPSO ist eben ein echtes Single-User/Single Tasking Program. Das lässt sich im späteren Entwicklungsverlauf nur äußerst schwer wieder in ein Multiuser/Multitasking verschlimmbessern. 🙂 ZEISS Empfehlung ist ja auch alle Daten lokal zu halten weil es sehr wohl bekannt ist, dass Netzwerkshares zu Problemen führen.

Gruß
Karsten

[[Ya...]]

Hallo zusammen,

ich persönlich bin von einer Werth KMG mit WinWerth version 2006 auf Win XP im Jahr 2018 auf eine Contura G2 und Calypso gewechselt.

Meine erste Aufgabe war es dann Vorrichtungen mittels RPS in einem Fahrzeug Koordinatensystem auszurichten.
Obwohl ich das noch nie gemacht hatte, hat es mit einem Halben Tag Arbeit und viel F1 drücken funktioniert.

Seitdem freue ich mich über jede Aufgabe die mir vor die Füße geworfen wird, denn bis jetzt konnte ich mit ein Bisschen Hirn Schmalz so gut wie alle Probleme lösen.

Klar ist es Nervig, wenn man einen Halben Tag in ein Messablauf investiert und beim ersten Start Calypso sich ohne Meldung schließt. Dann schau ich eben was übrig ist und mach es noch mal. 😁

Der Planner hat seine Macken und die Autorun Oberfläche und die Definition der Messpositionen in der Oberfläche ist für mein Empfinden veraltet und zu Komplex. Ich hoffe einfach das in der Zukunft da noch was passiert.

Da ich noch mindestens 36 Jahre vor mir hab kann sich noch einiges ändern.. Mal schauen wo die Reise hin geht.

Mfg Yannick

[[Se...]]

Please sign in to view this quote.

Danke Karsten für die Ergänzung!
Mit Ausnahme der fortlaufenden Messungsnummer sind die Protokollkopfdaten bei uns fest vorgegeben. Ich verstehe jetzt auch, warum wir hin und wieder Unstimmigkeiten mit dieser Nummer haben.
Ansonsten funktioniert die Zentralisierung der Programme auf einem Server gut. Wir wären eh nicht in der Lage, den Pflegeaufwand für alle unsere Programme zu verwalten, wenn sie lokal auf jedem Rechner laufen würden.

Aber ich stimme dir zu: Es ist wirklich schade, dass diese so wichtige und grundlegende Funktion nicht verfügbar ist... 🙁

[[Ka...]]

Moin Sebastien,

Wenn du etwas spaß am programmieren hast, kannst du eventuell ein Locking für die Datei protheadparam entwickeln. Es gibt ein paar "userexit", also Aufrufe von externen Programmen aus dem Programmablauf heraus. Siehe in der Bedienungsanleitung nach "Ablaufsteuerung mit externen Batch-Dateien".
In der *.bat kannst du dann ja ein Programm aufrufen das du mit deiner Lieblingsprogrammiersprache entwickelt hast; mit DOS-Batch möchte man ja nun wirklich nicht mehr arbeiten 🙂

Happy hacking!

Gruß
Karsten

[[Ch...]]

Ich finde das die Performance von der Software extrem schlecht ist. (32Bit im Jahr 2023??)

Softwareabstürze gehören zur Tagesordnung und werden einfach nicht behoben.

Desweiteren finde ich die jährliche Softwarewartungsgebühr viel zu teuer für eine Fehlerhafte Software.

[[An...]]

Please sign in to view this quote.

da kann ich nur zustimmen.
Wir haben auch ein Softwarepflegevertrag mit diversen Optionen und Hardwarepflegevertrag, da kommt im Jahr
so einiges zusammen, nach fünf Jahren Pflegeverträge haben wir unsere DuraMax quasi zweimal gekauft.
Da ist natürlich Ärger mit Softwareproblemen gegenüber der Preisgestaltung für Aufwände und 32 Bit Version nicht mehr realistisch.

[[Ch...]]

Das schlimmste sind ja auch die empfohlenen Systemvoraussetzungen.

Ich selbst habe einen Rechner bei der KMG mit 2xXeon und 96GB Ram.

Der starke Rechner ist komplett umsonst...

Denke mal es würde ein 486er reichen.

[[Ka...]]

Moin Christian

Please sign in to view this quote.

Die Performance (also Ablaufgeschwindigkeit) von CALYPSO hat ja nun zunächst nichts mit der 32Bit Version zu tun. Ich finde die Software im Messbetrieb gerade ausreichend schnell. Die 32Bit beschränken nur den adressierbaren RAM Speicherbereich und langsam wird es erst, wenn die Software ( eigentlich das Betriebssystem ) anfängt zu pagen ( Auslagern von virtuell gemapten Speicher auf z.B. Festplatte ). Das kommt nicht vor, denn es ist ja auf den durchaus SEHR überdimensionierten Rechnern von ZEISS mehr als genug RAM vorhanden. Kritisch wird es, wenn der maximal zur Verfügung stehende Adressraum nicht ausreicht ( warum auch immer... ); dann kracht es.
Kurz: 64 Bit wird nicht schneller...

Softwareabstürze verzeichnen wir auch viel zu häufig für eine so ausgereifte ( und alte ) Software!

Wir konnten ebenfalls keinen wirklichen Mehrwert an einem Softwarewartungsvertrag feststellen. Die Jährlichen Kosten sind mehr als enorm und so haben wir uns entschieden den aktuellen Stand "einzufrieren".
Die letzten Weiterentwicklungen von CALYPSO waren hauptsächlich für den optischen Bereich und marginale für uns interessante Dinge. Das Bugfixing findet aus unserer Anwendungssicht eigentlich nicht mehr statt.

96GB Ram ist natürlich quatsch! Auch wenn das Betriebssystem und diverse andere Programme lustig Speicher nutzen reichen 32GB sicherlich mehr als genug aus. Viel Performance wird vom acis32 Kern verbraten der aber auch schon eine sehr betagte Version hat und sicherlich kaum die GPU Leistung modernster Grafikkarten wirklich nutzt.

Gruß
Karsten

[[No...]]

Please sign in to view this quote.

Ja, dieses Problem hat mich in der Vergangenheit schon einige Nerven gekostet. Wir verwenden in den Protokollkopfdaten eine Art Index hinter der Teilebezeichnung, um bei Bedarf in unserer QDAS-Datenbank einen neuen Datensatz anzulegen (z.B. wenn sich der Merkmalsumfang ändert).
Editiert man nun dasselbe Programm auf verschiedenen Rechnern, kann es passieren, daß veraltete Protokollkopfdaten aus der protheadpara gelesen und dann beim Speichern sogar in die inspection Datei geschrieben werden. Auf einer anderen Station, wo vielleicht noch kein protheadpara vorhanden ist, verwendet Calypso dann stattdessen die Daten aus der inspection und legt diese dann in einer neuen protheadpara ab. Und schwupps haben sich so die veralteten Daten auf die andere Station übertragen. Das ist fast als wenn sich ein Virus ausbreitet. Und dann wundert man sich, warum ein Programm plötzlich wieder auf einen alten Stand springt und die Daten im falschen Datensatz landen.

Ich habe dafür eine Radikalkur eingeführt: Jedesmal wenn ein Pogramm geladen wird, werden sämtliche protheadpara Dateien in allen Verzeichnissen per Batch gelöscht. Da wir die auftragsbezogenen Daten sowieso bei jedem Programmstart neu eingeben und die anderen in der inspection stehen, hat das in der Praxis bei uns keine negativen Auswirkungen. Seitdem ist Ruhe.