All Activity

@Chris Verrill I still don't have a resolution to this and just noticed you replied so I see it isn't just me. I just opened a ticket with Zeiss this morning to see if they might have any idea why or how to resolve this. I will update here if I get anything back from them. Thanks for letting me know you had the same problem!

Along those lines Jason from experience with a lot of active R/T scanning is : If you start a passive R/T program, and the previous part was an active R/T scan program, and it update the R/T cal data, etc; if the part was bad or set up not so well, the R/T value could be high and therefore subsequently skew the data in the passive program; that's why its' recommended freshly calibrating the r/t prior for most of those programs - you could also use PCM to check if current R/T data is 'too high' etc.

Most of the programs are currently set up as passive use of the table. There are a couple that use active for one feature. But i think all programs are set to active. I think right now the plan is to keep it like that for the most part. Maybe we could start to implement more active measurements later as we start to clean up some of the programs and probes. There are several setups of probes that are mirror opposites or doubles and instead of rotating the table they change the probe. This will be one of the items we will be changing soon. I was told today by one of the operators that they have been getting bad results after several runs and then they will requalify the rotary and the parts will measure in tolerance again. Now, I haven't seen the reports yet so i don't know how in is in and how out is out. Lots of things to work on and learn for sure

Thank you everyone for your valuable feedback infact it worked

I agree with Jeff. I honestly use the base alignment more as a start alignment. I never use it in any characteristics. I'd just use one of the holes for C datum for the base alignment, then refine it properly later.

Just in case you're still viewing this thread, how would I go about measuring this in calypso? I basically understand what you're implying I'm just not sure how to go about measuring it.

Okay thanks very much for your input. It's appreciated...

I have a weird frustrating issue with GearPro, want to see if anyone else if seeing the same thing. For years I've stitched my GearPro reports to the end of my Calypso reports using PDF all (using GhostScript) save in Calypso. Never had any issues with it. Recently, I've had a couple of programs that are failing to stitch together. Its saving just the Calypso reports. Even more frustrating, its not entirely repeatable. It seems to happen more often on all tooth scans (reports are larger maybe causing issue?). Also, if I restart Calypso and GearPro it will almost always correctly stitch the first one just find, but subsequent runs may not stitch. I know this isn't necessarily a GearPro issue, but has anyone seen this before?

Hi @James Bates I'm curious: why do you need to set up a rotational pattern for the base alignment? The purpose of a base alignment is primarily to facilitate navigation of your probing system and provide basic stability for the measurement plan. Typically, secondary alignments and features utilize rotational patterns for position characteristics.

you're definitely on the right path, just remember Calypso uses it's own version of small talk programming language. Your code appears right for python and similar languages, I haven't yet got GPT to spit out any useable smalltalk code for Calypso. I no longer have PCM access directly otherwise I would test it out for you.

Understandable issues, I wish there was a tool that could help you with this but I can't think of any. With that many operators maybe a simple solution is just having a procedure in place where someone other than the one who assembled the styli system does a quick double check of the tightness before okaying it for use. That won't get rid of all the issues but it may mitigate them enough to be in at an acceptable level.

"why are people that seem to have no grasp on the delicate nature of building CMM stylus systems allowed to create them"...... Union shop...which is great but now I am dealing with the other side of the coin..... I am in a shop that is union and have over 200 styli systems.... some have been in place for over 30 years..... 17 cmm operators (not programmers) run the machines with a new turn over. 7 machines and no budget to make 1400 stand alone probe systems (one for each machine) and no RDS head (do not want one and really no use for one). I am thinking about fabricating one but with the shop, it has to through a "design team" first, then budget, then bidding, then fabricating/production.... but I can get one off the shelf... much, much easier..... Was also thinking about 3d printing them with a set breaking point, but that would only keep them from over tightening them and afraid the probes would be now be too loose.

Thanks Karsten I'll check with our IT department to see what might be blocking access to the (local) file. Note: For this particular part, we cleaned up the entries in PiWeb and reloaded all measurements as a workaround.

Wonderful!

Hi, Looks to me a file /directory access issue. If you use the standard method of store the PiWeb data, the data is stored local in a SQLite database file. The name of the file is the same as the program name. If the previous file is not visible at the moment the file should be extended, a new one will be created. Check the creation time of these three files. If you use central PiWeb DB ( small business/Enterprise ) you have an issue while uploading the PiWeb Data from your local machine. In general it should be easy to merge the data to one DB-file. But this need a internal knowledge of the Db structure which is not documented. I´m sure ZEISS has it´s own merge tool. Ask them for service.

Are you talking about assembling CMM stylus systems? We are a busy high production shop and I would be very hesitant to let anyone else but those that program on the CMM's (me and one other guy) the access and ability to create stylus systems and switch out stylus probes for a lot of different reasons. How often are you finding you need to build or swap out probes and stylus systems and why are people that seem to have no grasp on the delicate nature of building CMM stylus systems allowed to create them? Who creates them in the software and qualifies them after they are built? Not including the master probe we have two basic stylus setups that cover about 90% of what we do on our Duramax VAST XXT CMMs, a straight probe and a star probe, and a few odd ones for specific jobs as needed. It very well may not be realistic for your purposes but If you are able to minimize the amount of stylus systems used in programming you may get away with not having to build as many and have less chance of error? I couldn't find any "single pin spanner" tools in a brief search or know how they would even work, just the torque screwdrivers and the fixed L-shaped pin wrenches but I did find some official (looks 3D printed) Zeiss plastic "XXT Stylii Assembly Pliers" that may prevent incorrect tightening and may be easier for whomever is assembling the stylii system to gauge the proper tightness: https://shop.metrology.zeiss.com/INTERSHOP/web/WFS/IMT-US-Site/en_US/-/USD/ViewProduct-Start?SKU=626109-0057-000&CategoryName=550000&CatalogID=500000&ExtendedNavigation=true

yeah.. not looking for the screw drivers.. can find those just about anywhere including zeiss... I am talking about the "single pin spanner" that is use to tighten the extensions and stylus to each other... I keep finding them either too loose or way overtighten to the point they are stripped.

endInspection() is better than cncBreak(). cncBreak will redlight the machine. There are cases though where cncBreak is the only thing that will stop a loop though.

@Lindsey Prestholdt GPT gives me this: wo = getRecordHead("u_Work_Order") IF STRLEN(wo) <> 10 THEN MESSAGE("WO must be exactly 10 characters.") STOP ENDIF Since the variable (wo) already exists ("u_Work_Order", entered manually at Run), you just need to validate it, not ask for it again. I do not have PCM to verify (might not be STOP, I think it is CNCBreak()?), but the logic makes sense. Been quite awhile since I have used PCM. From this core code, you can expand on it and enforce more rules (for instance, not allowing someone to just type '0000000000' 🤣)

@Marco Giraudo I did not know about the flipbook option, thank you! This is very useful.

Thanks for the responses. I too thought it was a strange requirement. Fortunately this is used internally so that'll be a few less hoops I need to jump through.

I am not seeing common datum anywhere in base alignment or true position. I am using version 8.

Got it. Was looking in the wrong place. Thanks.

for reference: https://www.gdandtbasics.com/angularity/

Jack, What do you select when you go to select one of the Datums with the new Engine?