Calypso CNC User Forums

Dave,

With regards to the angle measurement probing function, which I love having built into MSM, is there a way you know of to utilize that measurement angle in re-orientating the X/Y axes to mill a part which is on an angle?

What I mean is that I develop a G Code based on a part that has the XYZ axes based on the top surface of the part in the fwd left corner (what you sometimes refer to as quadrant 1 in your videos). However when I mount the part to the table of the mill (without a vice) and clamp it down without ensuring it is perfectly aligned with respect to the machine axis there will be a deviation between the part axis and the machine axis (X and Y for each axis will be angled to one another. I would like to utilize the angle measuring script in MSM to somehow ensure the part gets machined to its respective axis without having to ensure alignment of the axes.

Do you know of a way to accomplish this? I have seen it in some CNC Router software packages and would love to have this same functionality from MSM.

Thanks,
Arthur

Hi Arthur,
I understand the desire! In fact, internally MSM has code to do just that.... but it is turned off and not included in MSM.
The core problem is that Mach is very broken wrt to the use of G68 (Coordinate rotations).
The bugs are pretty severe in Mac3, and The support issues they caused made it necessary to disable that rotated coordinate features.

This is item 4.22 of the known and verified mach3 bug list in the MSM release notes:
4.22 G68 related bugs
The following bugs discovered have been verified on Mach 3.43.22:
1) The Mach vars that report probe points do not handle G68 rotated XY WCs. They report non-rotated WCs even though the WC is rotated.
2) There is no interface to get the current G68 rotation parameters from mach.
a. You can get the G68 angle but not the G68 rotation point. This makes it impossible to do the math outside of Mach to compensate for the incorrect Probe point coordinates reported by Mach.
3) The WC DROs in Mach do not give correct coordinates when G68 is active.
4) The Multimode DROs do compensate for a rotated WC, but these can not be used in many cases as the mode can be asynchronously be changed from WC to MC or DTG. That would blow up calculations that expect WCs and might get MCs or DTGs instead.
a. Essentially the mode setting of the MultiMode DROs needs to be treated as a critical resource and protected with a lock – but Mach has no such concept.
5) The Zero X and Zero Y OEM button calls are broken in Mach if G68 is active. They appear to set the WCO for the axis as if the WC was not rotated. This makes the WC position of both X and Y incorrect (even from the multi mode DROs) if you zero either X or Y while G68 is active.
6) Mach does not jog correctly when XY is rotated. Mach always does no-rotated jogs (square to the Machine axes). Since Jog movements (step distances etc) are specified in WC, it should jog along X and Y WC axes. If G68 is active, this really mess up machine operation as people do not realize that they are not jogging in the WC direction that they commanded. Jog motions are specified as WC movements, but are not correct when G68 is active.

USE OF G68 WITH MACH V3 IS NOT RECOMMENDED until such time as G68 handing in Mach is repaired.
MSM bug reports with G68 active will be declined due to the state of Mach v3 G68 implementation.
Verified on Mach 3.43.22 (and not still not fixed as of mach 3.43.66)

So alas, while I like the idea, it is not going to be possible to do this due to the Mach3 G68 bugs.

Dave