All Activity

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

hello you can check our knowlege base for article related to your issue

Also entweder stehe ich gerade komplett auf dem Schlauch und verstehe euch falsch, oder bei uns läuft hier etwas schief. Der Prüfplan wurde in diesem Fall aktualisiert, genauer gesagt das Kommentarfeld. Auf Bild 1 und 2 seht ihr die beiden identischen Prüfpläne. Der rechte Prüfplan wurde neu eingelesen und erst danach wurde das aktualisierte Kommentarfeld übernommen. In meinem oberen Beispiel war der programmierbare Stopp gemeint. Nachdem ich diesen eingefügt hatte, wurde er in beiden Programmen angezeigt. Als ich anschließend den Text im programmierbaren Stopp geändert habe, wurde diese Änderung jedoch nicht mehr aktualisiert bzw. übernommen. Wir arbeiten nicht mit Versionierungen.

for i in gom.ElementSelection ({'category': ['key', 'elements', 'part', gom.app.project.parts['Part'], 'explorer_category', 'inspection']}): x = i.get('name') if gom.app.project.inspection[x].computation_status == 'computed': print(f'Feature {x} is computed') else: print(f'Feature{x} would not compute')

I came back from vacation and the CMM was not used while away, Windows on my desktop was updated for 1/2 hour and now Calypso doesn't produce a PiWeb report. I am not drawing any conclusions from the Windows update but that was one thing I can think of that could possibly affect the operation. Is there anything I can do to fix that? The report is always automatic, I believe I had it set correctly years ago, never changed it since. I wonder if there is anything I can do to fix it.

If i remember correctly, there was an option to store anything into folder "inspection/MEASUREMENT_PLAN/dataForPiWeb" and it was stored into it. But i never tested it. So running BAT while protocol is not ready, importing some info into that folder, could theoreticaly import into database those files.

Has anyone continued working on this without the use of PCM? We are looking to add something similar as Kartsen, where we would like to add data from a hand-held device to our reports. We have several CMMs but we only have 1 PCM license on our main PC, so we cannot use the readPCMFile or runPCMFile functions on our CMMs.

Check if you have enabled PDF printout and what settings is used for path.