PiWeb Report, MMC with 0 Given Tolerance.

[[Mi...]]

Curious about this... the extra M Calculation breaks here. The given tolerance is 0, the bonus makes up the entirety of the tolerance

Since the formula for the extra M is (GivenTol/(TotalTol))*Actual In this case that means it will always be 0, making it useless.

For anybody familiar with the Ford Residual Tolerance Mirror method, that method is more complicated but it doesn't break with a 0 (or even negative) given tolerance like this seems to.

Am I correct? or am I missing something. Can I disable the extra M? so I can save confusion and add the RTM method for our SPC requirements via a result element.

PiWeb Bonus Tolerance.PNG

[[To...]]

Don't have an answer for the first part of your post.

Courtesy of Richard Shomaker

Screenshot 2024-10-23 101301.jpg

[[Mi...]]

Please sign in to view this quote.

Bleh so I would have to turn it off for all programs... or create a custom template for the few specific specific programs that require it... a 0(M) tolerance isn't common but Ford likes them now so it keeps happening.

You know... it seems like this would be an extra setting within the "Additional Printout" menu so it can be controlled on a per program basis... so big facilities that focus on standardization don't have to create and maintain unnecessary report templates.

[[Ha...]]

We have a KB article explaining how that result is calculated for the .M characteristic in case anyone is interested.

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

[[Mi...]]

Please sign in to view this quote.

That knowledge base article doesn't answer either of my questions. It's also quite confusing to the point I think it's wrong. I downloaded the program and opened it, there's a metric conversion in the formula yet the program is already metric. And the metric conversion is only on part of the formula ( the bonus tolerance) Not the entire thing.

(getNominal("Position_Circle1").tolerance.upperTolerance/((getActual("Position_Circle1").tolerance.upperTolerance)/25.4))* getActual("Position_Circle1").deviation

Adding a unit conversion into the teaching tool of an already unclear feature isn't great.... even worse if I'm right and it's incorrect.

Regardless it still breaks when you have 0(MMC) as 0 X anything is 0.

[[Ri...]]

Apparently I was last told that I should create a MyVoice to correct something that is broken fundamentally. 🙁

The .(M) would be perfectly fine if they didn't multiply it by the base tolerance. Works great for every base tolerance except for 0. Hahahaha.

[[Ri...]]

https://portal.zeiss.com/my-voice/softw ... 6c86bfcd77

Please upvote and make material modifiers great again.

[[Mi...]]

Please sign in to view this quote.

So I'm not crazy.

the .M is a great idea... except it's not an easy option to turn on and off like "Additional Printout" and it's a fundamentally flawed calculation that straight up doesn't work with a completely legal and not even that weird MMC callout.

Why couldn't it be a simple % of total tolerance used? if they were going to put in a blanket "better-than-nothing" option I would think that's what I would pick as that would satisfy a lot more people's basic needs I would think... and doesn't break with a 0 Given Tolerance.

The Residual Tolerance Mirror method that we have to use for some things is better, but a lot more complicated. I'd love to see that as a option built in, but it's simple enough to do with a result element after doing it once if needed.

Since this breaks in some cases, I have to disable it in all cases because I can't explain to a plant a 700 people why it appears on this program, but another one can't have it... making it completely useless to us and I will have to create a result element for the places we want the value for SPC built in, or continue to calculate it outside of Calypso.

Edit: Upvoted your MyVoice