All Activity

PositionCMM uses machine coordinates, not your base system. It will also go in the order of Z then Y then X, unless specified otherwise. Look at the last example for moving in the Y direction first. But I would recall that circle into machine coordinates first, or you'll be in for a rough time.

Hallo Matthias, vielen Dank für deine Antwort 🙂 Das stimmt, bei dem dargestellten Protokoll fehlt die Toleranz, bzw. sie wurde links unter dem Namen vom Merkmal nicht angezeigt. Ich habe heute alles geschlossen, den PC neu gestartet und plötzlich geht es - sehr nervig und nicht zufriedenstellend... Möglicherweise habe ich in PiWeb etwas umgestellt und durch das Neustarten wurde es wieder zurückgesetzt? Grüße!

If it's just a chamfer, then i would stick to the closest feature to this chamfer. In other words it's local angle If part is thin it can bend by fixture force or machined features can bend via machining forces. Then chamfer is to none machining force. So if it's chamfer of a hole - you can compare angle to plane at hole or hole itself.

I agree with the posts above when using a small stylus (sub 1mm) on a large 30mm ref sphere. A small stylus on a large ref sphere runs the risk of shanking out if the shaft is stepped. Example image below. If you can ensure this isn't occurring on your setup then I wouldn't think there should be any other limitations. I also don't think you should see any issues when using a large stylus (over 1mm) on a small ref sphere (8mm). Unless it is so large that it's contacting the shaft of the ref sphere itself when scanning from the side. Maybe others have experienced differently but I have used upwards of 5mm diameter styli on my 8mm sphere without issue at the 180/0 position.

We're having some trouble agreeing on an angle result. Depending on what the other plane is, the CMM measures the angle between 43° - 47° I'm told by the engineer that it's actually a near-perfect 45°. The customer uses a 3d scanner and their results are very close to my cmm results. Is there a super secret way to evaluate angles differently? Here's a visualization of the chamfer's profile. I added random datums to constrain the DoF.

Can someone help me understand this PCM command, positionCMM()? I'm trying to get the probe to move in the -Y direction immediately after the program is done running. This PCM command will be place in the post settings for the overall program PCM. I'll list my code below. *"variable" will be a set parameter inside of a parameter file. Actualx = getActual("circle").x Actualy = getActual("circle").y Actualz = getActual("circle").z if "variable" == 1 then positionCMM(Actualx, Actualy, Actualz) endif As soon as the program is done running the probe will just go straight up. Not sure what I'm doing wrong. Any help would be appreciated, thanks!

Oh I understand now, thanks!

Ich habe das jetzt mal bei mir getestet. Das graue Kommentarfeld als auch Kommentare im Programmierbaren stopp werden Automatisch bei mir Aktualisiert im AutoRun bei Änderungen. Ich bin bei Calypso 2025 8.0.1603

Das ist dann wohl ein Bug, denn der Kommentartext (graues Feld rechts) steht nachweislich nicht im Autorun-File, wird also dynamisch aus dem jeweiligen Prüfplan eingelesen. Aber natürlich kann es sein, dass nach dem erstmaligen Einlesen der Daten in den Arbeitsspeicher das Feld danach nicht mehr aktualisiert wird. Wir ändern an dem Kommentar nur sehr selten mal was, darum fällt sowas bei uns praktisch nicht auf. Der Kommentar ist für unsere Bediener auch nicht relevant. Wenn allerdings sogar der geänderte Text aus einem programmierten Stop nicht aktualisiert wird, ist das ein gravierendes Problem, das ich an den Support melden würde.

I think you got me wrong here. What I described is not an issue between Planner and the real-world CMM, but a (hypothetical) issue in Planner itself. If you just don't bother about loading "real" PCF data into Planner and only use the SSC models instead, you're good and all that was said above will be true. Loading an SSC model will generate ideal probe data anyway, so no need to load a PCF at all.

Hallo, könnte es möglich sein das bei Ihnen die Toleranz fehlt !!! Grüße Matthias

LOL good one!

Hahahaha

I asked the AI to optimize the userfields.ini file (and selected the wrong file, userfields_AIMS.ini, by mistake). The response was: This configuration file is for ZEISS Calypso (a widely used metrology software for coordinate measuring machines), and it does contain a classic pop-culture Easter egg. The Easter egg is hidden in the [u_field_deviceID] section under the default value: defaultValue=8675309 The Story Behind the Easter Egg The number 867-5309 is one of the most famous telephone numbers in pop culture. It is the title and central theme of the 1981 hit rock song "867-5309/Jenny" by Tommy Tutone. In the song, the narrator finds the number and the name "Jenny" written on a wall and decides to call it. Because the song became a massive hit, this number is widely recognized by developers and engineers, who frequently use it as a placeholder, test number, or subtle joke in code and configuration files. The ZEISS software developers clearly slipped this in as a clever nod to the song.

@Joe Kerman I would imagine qualifying 180° of a small stylus on a large sphere would lead to shaft shank out problems more times than not.

I think mainly due short probe shaft.

This here was my main worry, i had to measure many components because I had no idea what some of the builds were (and some were custom) so i ended up just measuring each piece with calipers, then build the stylus model from that. After i would take the probe to a height gage or a Keyence and measuring the top of the probes to the base of the system, then just editing the numbers to match what i got with the height gage or keyance. Suffice to say, not exactly a super precise way to measure the probes, but it was really the only thing i could think of because we had ordered the components from many different companies years before i started working here, and have no documentation on what it was we ordered. So my worry was that my actual probes would be different then the models i created and that it may cause the issues you mentioned. I dont think Ill be able to do more with it until i get the planner dongle in and have the software in front of me (which i guess wont be for a couple weeks) because im thinking ill be able to find a way to get more information about the probe models i created when they are actually in planner (ruby locations and such)

The way I have that type of inspection is to use a reference plane/circle/line/etc. from the 1st op that can be picked up in the flip and measured to ensure you are getting the same results for that feature. I have something similar where there is a flat section with a thru hole and counterbores on each side with the depth called out on one side, and the thickness of the material between the 2 c'bores is dimensioned (see snippet below). Since htere was a datum plane that the hoile was one, I was able to measure from teh datum plane tot he bottom fo the first c'bore (with the depth called out), then after the flip, I can measure the datum plane again and then measure the depth of the undimensioned c'bore depth. After that I used Result Element to subtract the depth from the second side from the datum plane from the dimensioned depth from the datum plane to get the result. Result Element formula: (getActual("DATUM D PLANE").z- getActual("1 OF 4X, .112 DEPTH POINT").z)*(-1)- getActual("1 OF 4X, .083 C'BORE DEPTH = ZONE 3B2_Z").actual

In training they told me probes less than 1mm should qualify on an 8mm sphere, and larger probes on a 30mm sphere. Does anyone have any wisdom as to why? What exactly are the bad effects of qualifying on too large/small of a sphere? We are troubleshooting some wierd problems and realized we have been qualifying a 2.5mm probe on an 8mm reference sphere for a little while. Sigma is always low. Wondering how far I need to run this up the NCR tree.....

I am able to measure both sides with no issue at all writing in a programmable stop and then creating a second alignment-the issue is the data not computing the variable distance I am looking for - I've created a 2nd alignment on the bottom plane of the CAD to establish the opposing face but not getting accurate results from this..

Well for that there is "Base alignment match utility". I have not used that, but i theory you have to be able to measure same features in both alignments to match them. Then you would be able to measure distances and other callouts as you need.

Here's a hypothesis: missing or incorrect formula in one of the "Name definitions for output files" windows. Go to Resources > Name for output files > ... for this Measurement Plan... Select "PDF File Graphics (custom report and plot)" from the drop down. Uncheck the "Name from setting for all Measurement Plans" box. Or if this needs to stay checked for this program, go into Resources > Name for output files > ... for all Measurement Plans... Select "PDF File Graphics (custom report and plot)" from the drop down. Make sure there's an appropriate path specified.

I have a drawing callout for a distance between one plane to another along with parallelism. The part I am inspecting currently is fixtured on a plate that can only measure one side, the goal is to write a program that I can create a programmable stop, essentially flip the part over in the same orientation, create a 2nd alignment to validate where my part is sitting in 3D space- the issue I am having is that the data doesn't reflect accurately when I flip the part over and measure the distance or parallelism from the original alignment or probing strategy from the first plane to the next... Is this a matter of manipulating the data in evaluation settings or is it an alignment issue? need help!!

https://portal.zeiss.com/knowledge-base?id=1128721

https://portal.zeiss.com/knowledge-base?id=1664567 this article can be helpful