All Activity

No, I found the error: I used "Link to actual element (mesh adaptation)" Intead "Link to actal element".

Hi , it works - version 2026 wrong vector?

Yes sounds like Sven says, the balancing from the Probe head ist failed. 😔

Hi all, Think I'm having a brain loss moment and cannot figure out how to align a particular part (will add photos when I’m in work). Part is 1” square tube bent into a half ring, the half ring is then twisted/tilted 30 degrees, meaning there is no ‘flat’ surface to create a plane on. Can’t help but feel I’m missing something simple?

Good morning, I have took a point on nominal section, then I created the actual element, then I want to link each other, but the OK button is obscured and I can't link each other. I use Zeiss inspect 2026 at the last version, with 2021 version I haven't this problem. Can somone help me?

Hello, after replacing kathode, I get this message: (2026 release) Even after logout, and create "new project", it still remains: Someone idea how to fix this please? 🙂 Thank you! Leslie

@Lincoln KnottAll old, settled versions will be removed. What dou you need.

Hallo, kennt jemand einen PCM Befehl um die Drehrichtung umzuschalten? Grüße Sebastian

The error points to a faulty sensor.

We also work with an 8 mm RS for small stylus balls.

Hello, We use an 8 mm sphere to calibrate our 0.5 mm or 0.3 mm probes. Whether a larger sphere can be used depends on the length of the shank. The problem is that it is difficult to tell whether the shank has collided with anything during calibration: the parts are too small to be visible. That was the reason we decided to use an 8 mm sphere.

Moin Robert, The question here is which compiler and which options Zeiss used to create the 64-bit binary. Another question is whether the actually minor floating-point differences between AMD and Intel have any noticeable effect on CALYPSO at all. It would be great if the system could determine at runtime whether the hardware platform is Intel or AMD and then switch accordingly. I'm pessimistic about this: Just because a 64-bit executable is now being produced doesn’t necessarily mean that the internal libraries have also been optimized (i.e., for AMD/Intel opcodes). Zeiss is likely aware of the problem, and if it really has a noticeable impact on calculation results, they’ll take the usual approach: the lowest common denominator. In other words, they’ll use the simple x86-compatible math library that produces identical results on both platforms. To be sure, you'll have to ask Zeiss, and I'd almost bet a case of beer that you won't get any definitive information from a developer. At any rate, here's something from support to put your mind at ease: “Everything will work” ... or something along those lines.

I have a bunch of old i9 9900 / i7 10700 machines, with P2200 graphics cards that are about to be replaced, mostly due to GPU driver support ending, other than security fixes. To avoid being in such a situation again, for quite some time, I intend to go with systems that have RTX 2000 Pro Blackwell GPU's. Our IT department demands it must be Lenovo, and come from CDW. The problem that I am running into is availabilty of Intel systems, that meet my requirements. (Thanks AI) My workstation, for simulation, is a Threadripper Pro 7945WX, for the same reason. There weren't any viable Intel options at the time of purchase, and my previous machine had died. I was told that using AMD for the production machines would be a bad idea, due to some differences on how Intel and AMD do math. As Calypso it now 64bit, and Intel actually pays AMD to be able to use their 64 bit instruction set, it didn't make sense to me. Is there anyone here that is using AMD for their production machines? Spec of one of my available options: Ryzen 7 Pro 9745 3.8 GHz, 64gb DDR5, 1tb NVME SSD, and RTX 2000 Pro Blackwell.

I use a self-centering point to measure the external/internal diameter of the gear teeth. Also used for measuring bevel gear teeth.

Hi PiWebians, Come across an issue I seemingly cannot fix. When plotting roundness in PiWeb it is “transposed” and there is no option to reverse it, if you use a legacy plot there is an option to transpose, this then makes the plot reflect the CAD evaluation when displaying points, which I can only assume is the true representation. Does anyone know how to transpose a PiWeb plot? Thanks in advance

Secondary Alignments and caliper distances are your keys to success here. The alignments will bring those numbers in line.

I am not sure if this Prismo is the Ultra or they are separate systems. I have worked with the large Prismo Ultra's at Cummins in Rocky Mount, and I swear those calibrations were under 1.0 for 1800 sizes. I could be wrong. Hell, I may be reading this report wrong, I usually don't pay them much mind. As far as I can tell, this particular CMM came in around 1.5, I thought it would have been lower.

We just had an error I've not seen before. The CMM was running a well-proven program through lunch. When we returned the stylus was in contact with the part, traffic light was red. The error was "418: problem with sliding average". I cleared the error and picked up where it left off. The stylus made contact with the piece, the sensor (VAST Gold) gave the green light indicating contact, and... seven entire seconds later the machine registered the hit. The machine moves normally and seems to be measuring fine, but every single-point-strategy cylinder in this program suffers from the same problem; it takes between 1 and 7 seconds to register a hit after contact. It appears this only happens with this program as I was able to successfully re-run a piece from another lot of a different part number with none of the weird behavior. There have been no collisions. The machine has run 2 shifts 5 days a week since calibration two weeks ago. It's an Accura2 with VAST Gold. I saw planes run, both single points and scanned; no problem. I saw 2D curves run without any issue. I changed the affected cylinders to other stylus systems and the problem persisted. I ran a qualification (Master Probe and another stylus), no issue. All cylinders mentioned here are oriented along the Y axis and at very similar X/Z positions. Probing forces and speeds are identical. It's an obscure problem. Is it familiar to anyone?

Can you explain how you did this?

Can anyone tell me what causes the Status Window to clear? We've had times in the past when we found it to contain just a day or two of data (fewer than 20 lines). Today, for other reasons, I restarted the computer running Calypso, restarted the C99, homed the machine, logged in as multiple users... None of these cleared it. The boss wants to know what's up. Mind you, we do know how to change the number of lines displayed in the window. We do know how to collect the sm_events.dat file. We do know about the C99 side logs as well.

I went to the portal to look at something, and I didn't see anything older than (2020) 7.0 Did Zeiss remove older version from the download portal? Lincoln

Thems R facts. The Zeiss technicians always tune the CMM to achieve the best possible results; even when they are well within the machines stated MPE.

In real life, if everything is working properly, then you'll always have a much smaller length measurement error than the stated MPE value. If you look at your calibration certs, you'll see they are well under the stated MPE values. I take care of my machines and that's the case for me at least. That's why the Prismo Ultra will advertise it's capable to 0.5 + L/500 µm, but its stated MPE is only 0.9 + L/350 µm.

Hi all, I'm having some trouble establishing a reliable and repeatable workflow for our before-and-after scan comparisons in GOM Software 2022. Currently, we compare two independently acquired 3D meshes to generate a color-coded heat map showing surface deviations, typically to evaluate material added or removed. Our current workflow is: Import both meshes (previous and current scan). Convert the previous scan into nominal CAD to serve as the reference. Recalculate our alignment using Local Best Fit. Recalculate the surface comparisons and deviation labels. Export the inspection report. The problem I'm encountering is that when I import the meshes and convert the reference scan to CAD, the converted CAD sometimes appears offset from its original position in space. When Local Best Fit recalculates, it aligns the current scan to this offset reference. As a result, some deviation labels no longer correspond to their intended measurement locations, while others fail to compute entirely. Because each part has its own unique reference scan, maintaining a single fixed CAD model isn't an option. My questions are: Is there a way to preserve the original mesh coordinates when converting an actual mesh to CAD? Can the two meshes be aligned to one another before converting the reference mesh into CAD? Would a reference-stage comparison or another mesh-to-mesh workflow be more suitable for this application? What would be the recommended approach for automating this process so that surface comparisons, deviation labels, and report pages update reliably for each new pair of scans? Ideally, we'd like to establish a project template or automated workflow where we import two meshes, calculate their differences, and generate a report without manually correcting their positions each time. Any guidance specific to GOM Software 2022 would be greatly appreciated. Thank you!