All Activity

My understanding is this: In the old hole pattern evaluation method, the best-fit position was calculated based on the nominal values. As a result, the size of the tolerance zone had no influence on the measurement result. The new GD&T feature, however, seems to calculate the best-fit position based on the tolerance zone size of each individual feature. This is just my personal understanding. Is there any official documentation or explanation available for the new GD&T functionality?

Morning! Looking at this, the Pos Tol in the left photo is adjusting the tolerance individually with an allowed Best Fit (Rotational). Calypso looks at the individual tolerances and finds the best position to rotate all features. The main Element that has the most bearing on your rotation is B.1 where the tolerance band is relatively small vs B.4 where you have a much larger tolerance band. Calypso may rotate your elements to try fit B.1 into tolerance even if the element B.4 has to rotate away from its own tolerance center. When you establish a tolerance on the right photo, that tolerance applies to all elements and so B.1 thru B.4 will all be treated equally.

Dear colleagues, in the previous method of evaluating the position tolerance of a hole pattern, modifying the tolerance did not affect the measurement results. However, in the new GD&T evaluation of hole pattern position tolerance, updating the tolerance zone also changes the measurement results. What is the reason for this? What is the difference between the two?

Have you activated ID chip recognition? Open the button data management and check the ID chip settings with the button replaced. If you have changed the button, the ID will no longer be correct.

Shot in the dark. Does it still exist in the location it was originally loaded from?

Don't forget to log out and log back in. Otherwise it won't work. At least it didn't for me.

Hallo Karsten, dein Problem ist ja offensichtlich gelöst. Nur als Tipp für die Zukunft: mit dem PCM-Befehl changeStylusSystem("Tastersystemname") funktioniert der Tasterwechsel ebenfalls

For some stupid reason, the Zeiss knowledge database is ONLY accessible to colleagues in the US. It’s really annoying that Zeiss USA feels the need to restrict access! To access the database change temporally your location at your ZEISS account, save it an try again to follow the given link.

Norbert, Die Problematik in dieser Welt ist die, dass wir immer noch kein Bier via e-mail verschicken können! Daaanke für diesen Tipp. So funktioniert es auch mit dem Tasterwechsel. Beste Grüße Karsten

I am not catching your intents here. I've found you can use MIN and MAX point flag as a measurable point. This way i am using to get depth of a part marking ( via flatness ). Then just projected distance to that plane. Also you can use user defined evaluation, where you can use this point as a variable.

That might be the same problem I had posted about a while ago.

I didn't see a change when trying that refactored version of the script. I feel that there may be something else I'm missing so I decided to look at other files within the program directory. I am currently reviewing the "startfile". Comparing two working programs vs my single non-working one. The working programs each have additional user defined fields at the end of the list. (u_NewVariable6 and u_NewVar BPQ449) Strangely everything else seems to match up with the exception of one of the working copies being TRUE for pdfExport and FALSE for protocolHead. I basically have different settings for all three programs, but I think the user defined fields may be a tell. I do not see these within the programs themselves though. I seem to recall an INI file is needed for that sort of thing.

Any possible way to use said min/max points for subsequent calculations?

First time I've ever seen something like that. I would probably just keep taking off components one by one to try and isolate the problem child. One stylus off, other stylus off, knuckle off, etc. If it keeps alarming when completely dissasembled, maybe it has something to do with the qualification? Very shocked that changing the adapter plate and rack port didn't help.

@Don M. Try this to fix your filepath to accept the CMM variable correctly (you currently show bpq473RunTracker.txt) cmm="000000" cmm=getRecordHead("dmesn") selectCase cmm case "810021" cmm="BPQ449" case "810475" cmm="BPQ472" case "810480" cmm="BPQ474" caseElse cmm="000000" endSelect read=readListFile(getActualInspectionDir()+"\startfile").asArray.asString Speed=mid((strElement(40,"'",read)),7,10) SpeedStr="Run Speed; "+Speed+" mm/s" StartTime=getRecordHead("time") StartTimeStr="Measurement Start Time; "+StartTime filePath="\\\\nos\\data\\Gear_Lab_Zeiss_Output\\Run_Trackers\\" + cmm + "\\RunTracker.txt" addToFile(filePath,("Measurement Plan Name; "+getRecordHead("planid"))) addToFile(filePath,("Operation Number; "+getRecordHead("u_OpNum"))) addToFile(filePath,("Start Date; "+getRecordHead("date"))) addToFile(filePath,SpeedStr) addToFile(filePath,StartTimeStr) This assumes these folders already exist - \\nos\data\Gear_Lab_Zeiss_Output\Run_Trackers\BPQ449\ \\nos\data\Gear_Lab_Zeiss_Output\Run_Trackers\BPQ472\ \\nos\data\Gear_Lab_Zeiss_Output\Run_Trackers\BPQ474\ \\nos\data\Gear_Lab_Zeiss_Output\Run_Trackers\000000\ This version establishes all your variables before writing anything to a file, and should correctly pass the variable "cmm" into the file path.

Here is the original script. I also re-ran this script and it gives me the same result after removing the local path. Program runs, no errors, but files are not saved where they should be. read=readListFile(getActualInspectionDir()+"\startfile").asArray.asString Speed=mid((strElement(40,"'",read)),7,10) SpeedStr="Run Speed; "+Speed+" mm/s" StartTime=getRecordHead("time") StartTimeStr="Measurement Start Time; "+StartTime addToFile(("\\nos\data\Gear_Lab_Zeiss_Output\Run_Trackers\bpq473RunTracker.txt"),("Measurement Plan Name; "+getRecordHead("planid"))) addToFile(("\\nos\data\Gear_Lab_Zeiss_Output\Run_Trackers\bpq473RunTracker.txt"),("Operation Number; "+getRecordHead("u_OpNum"))) addToFile(("\\nos\data\Gear_Lab_Zeiss_Output\Run_Trackers\bpq473RunTracker.txt"),("Start Date; "+getRecordHead("date"))) addToFile(("\\nos\data\Gear_Lab_Zeiss_Output\Run_Trackers\bpq473RunTracker.txt"),SpeedStr) addToFile(("\\nos\data\Gear_Lab_Zeiss_Output\Run_Trackers\bpq473RunTracker.txt"),StartTimeStr) cmm=getRecordHead("dmesn") if cmm=="810021" then cmm="BPQ449" endif if cmm=="810475" then cmm="BPQ472" endif if cmm=="810481" then cmm="BPQ473" endif if cmm=="810480" then cmm="BPQ474" endif

@Don M. Is it possible for you to paste your inspection_PCM file contents here (remove any sensitive information)?

The filepath was set for both global and local. I've removed the pathing for the local settings and Calypso seemed to work correctly, no PCM error and the PiWeb report populated afterwards. The issue I have now is, Calypso straight up ignored the global file path location and reverted to the default settings in (Extras>Settings>Environment>Paths).

cmmAct=getRecordHead("dmesn") cmm="" selectCase cmmAct case "810021" cmm="BPQ449" case "810475" cmm="BPQ472" case "810480" cmm="BPQ474" caseElse cmm="000000" endSelect

@Don M. Is this filepath set in your global file, or in the local program? It looks like something in this program is triggering an output before "cmm" is defined. This gives you the error. Yup, that confirms it. In your global text file, move your case logic to the very top. This sets the variable from the very beginning, before anything begins to output. Put this at the top before anything happens. cmm=“000000” selectCase getRecordHead("dmesn") case "810021" cmm="BPQ449" case "810475" cmm="BPQ472" case "810480" cmm="BPQ474" caseElse cmm="000000" endSelect

I've tried to use the mapped address, but Calypso didn't seem to like that. Maybe I'll give it some more testing. More food for thought. We are usually outputting the default report, measuring points and a PiWeb report. All with the same file path and naming convention. I decided to remove measuring points from the list and while I still receive a PCM error, it no longer shows the pcm script as the culprit. The program also generates the piweb report which it previously didn't do. Something strange is afoot.

Ahhhh. Progress. You have to create an Element Group from the Points first.

I've had issues using raw network paths - instead I prefer to use mapped network paths instead.

It appears that Calypso defaults the cmm number to either 9999 or 000000 if it does not find a match case in the script. I did not see a local copy of the script in the program folder, however, the program is responding to changes I make to the global pcm script (ex. message(cmm)). I just can't figure out why the process seems to work on one program and not another given everything appears to be set the same way. Here is the file path in question as well; "\\NOS\Data\Gear_Lab_Zeiss_Output\"+cmm+"\"+getRecordHead("planid")+"\"+getRecordHead("order")+" "+getRecordHead("date")+"\"+"Part_"+getRecordHead("partnbinc")+"_Time_"+getRecordHead("time")+".txt"

In Calypso this would be super straightforward. 😞 Either way. I need to measure (6) points and then have the software pull the min/max points, so that those points can be used for subsequent actions. I see that there is a Minimum and Maximum inside of Inspection - Check Dimensions - Positions - Check Y, but I'm unable to get these to work.