All Activity

That is very good advice, I have found that once as well causing a bunch of issues.

all i am trying to do is make the probe raise up in the z rotate then continue to the next feature rather than raise in the z shuttle to the next feature then rotate.

I have wondered over the years why Calypso doesn't have detection when the RDS or an XTR articulates near the +X or -X uprights. When you use Planner (Simulation), you can show the max volume which means each CMM has the ability to adjust to a working volume to calculate an articulation coordinate based on the length of a stylus.

Dear All Our We team would like to inquire about a discrepancy in the nominal angle values displayed in ZEISS CALYPSO between the True Position and Features windows for Feature A2. The values displayed are as follows: True Position – Nominal Position (Angle): -21.000° Features – Nominal Angle: 339.000° Actual Angle: 339.225° We understand that -21.000° and 339.000° may represent the same angular orientation, as they differ by 360°. However, we would like to confirm whether this is the expected behavior in ZEISS CALYPSO. Could you please clarify the following points? Why does the True Position window display the nominal angle as -21.000°, while the Features window displays it as 339.000°? How do the Positive Orientation and Negative Orientation settings affect the angle definition and measurement calculation? Which angle setting should be used to ensure the True Position evaluation is correct according to the engineering drawing? Could this difference in angle representation affect the True Position calculation or measurement results?

If Richards approach doesnt help, you can try to restart your controller. If that doesnt help you can try to take out the sensor of the "dovetail guide" if you have a MASS compatible CMM. Unfortunately this message often means that the Sensor is damaged. Best Regards Marcel

----Englisch version below--- Guten Tag zusammen, gibt es eine Möglichkeit, eine TOP-Fehler-Auswertung über mehrere Messungen und Bauteile zu erstellen? Von Vitronic erhalte ich über CSV die Ergebnisse der Inline-Schweißnahtüberwachung. Für jede Schweißnaht steht unter anderem die Bewertung „Schweißnaht Gesamt“ = IO/NIO zur Verfügung. Ich möchte nun nicht nur einzelne Bauteile betrachten, sondern beispielsweise einen Zeitraum von zwei Wochen auswählen und daraus ermitteln: Welche Schweißnähte wurden am häufigsten mit NIO bewertet? Wie häufig trat der jeweilige Fehler im ausgewählten Zeitraum auf? Darstellung als Tabelle, absteigend nach Fehlerhäufigkeit sortiert. Ziel ist eine kompakte TOP-Fehler-Liste über alle Bauteile, sodass die aktuellen Problemschweißnähte direkt ersichtlich sind und nicht täglich mehrere Einzelprotokolle durchsucht werden müssen. Wisst ihr, ob bzw. wie sich eine solche Auswertung realisieren lässt? Viele Grüße Martin ----------------------------------------------- Hello everyone, is there a way to create a TOP error analysis across multiple measurements and parts? I receive the results from the Vitronic inline weld inspection via CSV. For each weld, the data includes the overall assessment “Weld Overall” = OK/NOK. Instead of analyzing individual parts only, I would like to select a specific period, for example the last two weeks, and determine: Which welds were rated NOK most frequently? How often did each error occur within the selected period? Can the results be displayed in a table, sorted by error frequency in descending order? The goal is to have a compact TOP error list across all parts, allowing us to immediately identify the welds currently causing the most issues without having to review multiple individual reports every day. Does anyone know whether this type of analysis is possible and, if so, how it can be implemented? Best regards, Martin

Wir hatten bevor ich die Contura übernommen habe einen Freien nicht gerade begabten Programmierer. Spät kam raus, dass er mit RDS sich gar nicht auskennt. Dort gab es mal eine Kollision wo sich der Sensor gelöst hat. Er wurde daraufhin entlassen und ich kam ins Spiel. Ist aber 4 Jahre her und seither hat sich der Sensor nie wieder gelöst.

Guten Morgen Sven, es kommt ab und zu (wenn auch selten) vor das sich die schwarze Rändelmutter löst, bzw. nicht 100% fest ist. Dies kann durch Kollisionen oder auch Vibrationen geschehen. Es fällt dann meistens auf wenn die Messergebnisse sichtlich schlechter werden. Ich würde Sie festziehen und in 1-2 Wochen nochmals gegenprüfen ob sie sich nochmals gelöst hat, wenn ja müsste man schauen ob die Mutter evtl. beschädigt ist. Wir haben das Thema ab und zu im Support ist aber eher ein seltenes Thema, fragen wir aber als Standard mit ab wenn das Fehlerbild in die Richtung geht wie du es beschrieben hast. Grüße Marcel

Seems you can have missing safety plane - which should be covered in newer versions of Calypso ( should not be empty ). If you need to move probe in one feature ( skipping part of fixture/part ) then go to strategy and place either new safety plane or non-scanning points in space.

So mainly those deviations can relate to vectors of touch. You base alignment will not be perfect so in every run you can touch the part in another locations, so there is first variable - another spot - another touch vector. Then you should use in formula "GetNominal" instead of "GetActual" - this can lead also to this deviation ( i did conversion and your difference is 0,1mm in Z axis )

Well, a few things to note: no sketch of a part no description how big is deviation in part location/rotation no info about what licences you have ( curve, FF, ... ) What you can do in Calypso is manual mode to force user to obtain a few features. You can use start alignment, RPS, loops of base alignment, is some stage you can also use curves. We have one part, which has one groove to clock a part. I did a fixture, where you clock that part by putting a rod into this groove for fixturing - after that this rod is removed and you can run program. Also you can pick someone on forum, which you want to trust and PM with more sensitive data to this problem.

Guten Morgen Zusammen, gestern als ich zur Arbeit gekommen bin, hatte ich eine Mail von der Spätschicht. Sie hatten Probleme, dass sich die Messungen von einem zum nächsten Teil extrem verschlechterten. Sie haben es erneut gemessen und es war noch schlechter. Zum Schluss haben sie noch ein ganz anderes Teil vermessen und es war genau so. Da es mehrere Sonden betraf gatte ich gleich die Maschine im verdacht. Bei genauerer Prüfung stellte ich fest, dass sich der XXT-Sensor am RDS-Kopf gelöst hat. Ich hatte gleich eine Kollision im verdacht. Allerdings hat der Ereignismonitor nichts der gleichen Aufgezeichnet. Hatte einer dieses Problem schon einmal oder ist dies bekannt? Grüße aus dem Schwarzwald

I once had a problem where the XXT sensor had come slightly loose from the RDS head. Check that the black union nut connecting the RDS to the XXT is securely tightened.

Unfortunately, there is nothing repeatable about the setup. It is basically put in by eyeball. One attempt at the setup has it balanced on three 123blocks. Another attempt uses a clamp and an adjustable riser. There just isn't a great way to control it. But that still wouldn't solve the problem.

Your form is pretty tight which likely precludes a wobbly reference sphere or damaged reference sphere, reference probe, or probe. If you are having the issue with multiple probes then I have to wonder if the problem isn't in the probe holder. Given that the deviation in location is primarily in Z, that would indicate that the calibration could be oot in Z. As I type this I think I would expect the measured diameter would be off by about 0.005" to account for the issue. Unfortunately, I am new to automated CMMs and Calypso so I don't have a lot of insight. I am following the topic to see if I can learn something from this.

Hi James, I'm not completely sure if I understand what particular part of the process is causing the crash but if you need the probe to move before it rotates to the for the next feature you can use CMM position points in the strategy of the last feature before the crash to move it to a safe position. Those you can key in manually or simply move your probe (rotated to the correct angle) to the location and hit the button. Under strategy it should be the first button on the left. Otherwise, if the travel is an issue you can block an edge of the clearance cube to prevent it from traveling along that edge. Youll find that option under plan -> Navigation -> Block edges. Under strategy you can also use clearance moves after the measuring strategy to get the probe out and away. Ex if it's backing out to an X- clearance plane and that's too low or too close to the X- side of the machine. You can say X- clearance, Z+ Clearance, X+ clearance. I'm fairly new to XXT and needing to do that so there are probably other cleaner options available as well. Perhaps one of the other users will have a better suggestion.

can anyone tell me how to make my probe come out of a feature raise up then rotate then shuttle to the next feature rather than shuttling and trying to rotate next to the mast and knocking my probe off?

We have a feature that we want to measure with a symmetry point to make sure it is well centered on a fairly thin wall when measuring a line on that edge. So there are two symmetry points, one for each point in the feature. The feature is connected to its own alignment, which is just a 90° rotation about the X-axis so that what was +Z becomes +Y. The symmetry point is in the base alignment. We also wanted to do a test to see if the symmetry point was significant and this is where we saw some weird stuff. The edge we are measuring is at 45° to the Y axis and perpendicular to the Z axis when in the base alignment. We created the measurement and put a formula in for the measured point's Y location (remember the feature is in its own alignment). the formula reads something like: GetActual("symmetry point 1").z This formula is in the definition of the point inside the measurement strategy and not on the nominal of the feature itself. Then we duplicated the feature and put the same formula in except we put a 0.015" offset so it reads: GetActual("symmetry point 1").z - 0.015 It looks pretty good so far. It says that the measurement point in the one is 0.015" lower than the other prior to any measurements being taken. Then we test this six separate times, export all the nominals and measured points to text files, import them all into a common excel sheet and start to analyze the results. There are a few troubling observations. 1) the difference in the nominals of each point is not exactly 0.015". It ranges from around 0.012 to 0.016, but is not exactly 0.015. Be aware that both points are using the same symmetry point. 2) all nominal and measured Z-values match. Between the six tests there are 12 points for the regular and 12 points with the offset. The Z-value for each point was unique, but the nominal and measured values for the point were a perfect match. Why would either 1 or 2 happen? Before you ask, I cannot share any pictures or files.

OK so you're saying that you set your limit at .0005in true position. Which aligns with my understanding as well for an expectation, maybe a little tighter than I would've said but broadly the same. I like your strategy of moving the cal-sphere around the table for subsequent iterations. I think that's a good set-up in general. I've had some ideas as to how to codify the verification moving forward, I think I'll incorporate some of that. Anyway, thank you, I appreciate it. I was really just looking for someone who is very familiar hands on with an XXT to share what their standard is for location verification. Everyone I talked to was somewhat back and forth on what numbers I should be holding that to.

From my XXT probe checking program where I use the 5 standard articulations (1 thru 5). I use the Reference Sphere, XYZ zero is set by the MasterProbe. I then use each articulation and measure the sphere. I report the True Position (TP) for each articulation at .0003 Sphere (Shape of zone). If any are OOT I investigate the issue. Using a Contura 900x1200x600 I run this program once a month (I do a similar test with the VAST XTR Gold). Every month, the Reference Sphere is placed in a new location, I use 5 standard location and two levels of height in Z axis (My riser is 6 inches). This is how I detect nonconformities with a sensor; this method allows the sensor (either one) to move in a wide area around the Reference Sphere while taking measurements and uses a good portion of my volumetric area. Typically, I can detect if a stylus, a sensor or a quadrant has an issue that should be evaluated, after evaluation if found to be a non-fixable issue in house it is escalated to Zeiss. I have been using this method for almost 20 years, and it hasn't failed me yet. As an FYI, I also perform this test with no filters or outliers to detect sensor issues, but I use a wider tolerance. When I run without filters and outliers, it is considered a non-quality program and not for suitable part measurements. I plot data from both programs in excel which tells me if something is wrong. The second program is only run when I think there is an issue after the all testing of the first program is exahuasted. Over laying bell curves of the quality program and the non-quality program should reveal shifts that indicate an issue.

My system has an RTX A4000 16gb, and the CAD models still gets like what you are getting, with complex models, at times.

@Marcel Hartmann, that is so encouraging to hear about! Metrology often involves evaluation of multiple CAD entities in the same setup, and digital distinction of these entities is valuable. Calypso users have found ways to accommodate the "fusing / stitching" in the software but not without sacrificing functionality. Thanks for continuing to improve and evolve Calypso.

I ran into a problem with a wheel file being corrupted, long way around i found where the wheel files are saved and was able to just replace it in this folder. Using 2025 it is located here: C:\Users\***USERNAME***\AppData\Roaming\gom\2025\gom_edited_addons\**tempFileString***\scripts\modules

Hi, Do you have a new standard VAST exchangeable module? If so, you need to register/activate it first; the instructions on how to do that are on the packaging.

1. Can the RondCom NEX 200 scan spheres (Concave or convex). My part is a cylinder with a sphere on the top. I can scan circular perpendicular to the cylinder axis no problem, but can I scan parallel to the cylinder axis? 2. How do I control or set the best angle of the Stylus shaft for scanning a sphere? Typical Sphere diameters are from Ø.180 to over Ø.500