All Activity

@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.

Hi everyone, I have been trying to get the MSA 1 sheet to give me values for CG and CGK but can't seem to figure it out... Can someone please point me in the right direction?

That's right! It was marking things it shouldn't have... Thanks a lot, Sven!

Refer here - Excel Report User Defined fields - General Discussion - ZEISS Qualityforum

hi the option is not masking, i know it sound strange but to hide in report u need to activate marking (Marcar). in the first window ocultar should be activated

To do it the way you want, you need to select the option one step down—"Mark," not "Mask." Alternatively, right-click directly on your inspection characteristic and select "Mask" there.

Good morning, everyone. Even after following these steps, a feature that I have selected as masked is still appearing in the report. Could someone tell me what I'm doing wrong? Thank you very much.