Machsupport Forum
Mach Discussion => VB and the development of wizards => Topic started by: DaveCVI on April 06, 2011, 12:24:06 PM
-
When a G68 rotation is active, there are interfaces to
1) know that this is is the situation (a LED)
2) get the Rotation angle (a DRO)
What I'm not finding is an interface to get the XY point that is the rotation axis...
Does anyone know how to get the rotation point?
Dave
-
Well if you did not specify a point then it is the current xy point.I will look to see IF there is a set of points available in mach hidden away.
HIYA DAVE, (;-) TP
-
Hi Terry,
The situation I'm trying to deal with is one where when the script starts up, it looks and finds that G68 is active.
The Rotation may have been set by the operator via MDI or something before the script is started.
I can tell G68 is active, & I can get the rotation angle from Mach - but I need to be able to find the point the WC was rotated about in order to do the math.
I even went looking into EMC docs to see if it was stashed in a gcode var someplace in the early EMC days and then might still be hanging around in mach.... I didn't find any such thing - but I'm not sure I knew where to look.
Dave
-
Dave
Would it not simply be the active X0Y0
Maurice
-
Alas, no - it could be any point.
The syntax is G68 X<coord> Y<coord> R<angle in degrees> (there is also an optional I param - not relevant to this issue) - so the XY plane WC can be rotated about any arbitrary point -
The problem I have is that the rotation could have been applied long before the script/button/ etc is invoked.
A user may have rotated things days before (say via MDI) - so to do the right thing when I find myself with a rotated WC, I need to find out what the rotation parameters are - but it appears that mach only provides a way to get the angle and not the rotation point.
This is part of a list of issues I'm finding about Mach's handling of rotated WC. IF I can get the rotation point, I can do the transform to compensate for what mach doesn't do correctly - as with the point known I can do the matrix math - but I'm stuck as I'm missing the rotation point's location.
Dave
Would it not simply be the active X0Y0
Maurice
-
Dave
Just to analyse a little further: I agree with you that the axes could have been or could be rotate at any time but the X0Y0 of the part, is the only point that is common to the rotated or non- rotated axis. So it is always a known center point of rotation and it doesn't matter when the rotation was setted.
Maurice
-
Maurice,
I'm not sure I am following you - Are you assuming that the rotation is always around the origin?
If so, that's not a valid assumption.
Example: It's valid to do G68 X1 Y1.414 R45 - in this case the rotation point is (1, 1.414).
To do the transformation to/from the rotated/non-rotated coordinate system you have to know the rotation point and the rotation angle.
Dave
-
HIYA DAVE I looked back throught all the notes and did not see a solution for you sorry. Also checked the EMC2 code as well, no luck.
I can tell you from past experiences IF you are trying to incorporate the G68 into a macro you are in for a treat. The G68 does not play well in MACH a lot of things do not work when in G68 mode and from inside a macro you may not get ANY error codes from mach telling why it quits.
Best to test IF it is active and simply turn it off OR IF you insist (;-) just reset it to a known CR base coor on the fly.
Let me know if I can help test for you (;-) TP
-
Thanks for looking Terry.
I was afraid that was the case. You're right about G68 - I've concluded that it's implementation is rather incomplete in Mach. I've accumulated a list of multiple verified bugs related to g68 rotations. I'm guessing that not very many people use G68 - as some of the bugs are really obvious once you try it.
I was really hoping to find a way to find the rotation point - one of the bugs is that the mach's touch vars ignore any active rotation. If you rotate the WC 45 degrees and then try G31 X1 – well, the movement is done in the correct direction, but the touch vars ignore the rotation and report an incorrect touch location. If I had the rotation point I could do the transformation to correct for the bug - but w/o knowing where the rotation is centered that's not possible. I was actually considering having to do this:
1) see if a rotation is active
2) get the rotation angel and axis point
3) cancel the rotation
4) do the probe “non-rotated” (as the only way mach works correctly for G31)
5) get the non-rotated touch location
6) convert that back to the orig rotated WC
7) restore the rotation
8 ) report the “rotated” touch point
That would have been a royal PITA – but I could be done – if I just had the rotation point…
This all means I probably have to decide to disallow any active coordinate rotations when probing - which is a bummer as that creates a whole class of situations that can't be handled with Mach. :'(
Dave
-
The reason Art disallowed the G31 in a rotated state was everyone at the time only used it for 3d probing a surface. And to 3d probing it is simply points in 3d space it had no relation to a known setpoint or point of origin.
In 2.5D and CMM probing a known setpoint is vital to the process. It took a while to convince Art to allow the A axis (rotary) to be probed with G31(;-)
I think a lot more people would be using it now IF it were a bit more stable. It can be a blessing to plasma and router work where it is NOT easy to rotate the full size sheet on the work table(;-). BUT it is what it is.
As a reference in 35 yrears I have never had to probe a part in rotated space (;-) . I have probed parts and then corrected rotation alignment in CAD. But that was just a convenence not a neccesity.
Just a thought, (;-) TP
-
Dave IF youare buiilding more probing routines I still have a bunch we developed years ago that might be usefull. The probing arrays were the cats meow and simple to use.
(;-) TP
-
Hi Terry,
Here is some more info to add to your notes:
I've verified these as of mach 3.43.22 - there are more problems I've discovered than I've listed here. If you want the full G68 related list I can send it to you.
The model is that G31 is done in the current WC system. The WC is the entire universe from the G31 viewpoint, it just calls for movement in the WC and gets touch points reported in the same WC. At the level of the G31, it does not know if the WC is rotated or not wrt to the machine axes - the WC is just whatever it is - and the G31 should neither care or know how the WCs relate to the MCs.
G31 is allowed with G68 active (as it should be). The problems arise because mach does not implement handling of a rotated WC in a way that is mathematically consistent. Unfortunately, Mach's implementation only works correctly if a WC is not rotated (wrt to the machine axes).
Problem 1: Mach does not apply the rotation transformation when reporting the probe touch point - so when G68 is active, the touch points are not reported wrt to the active WC. This is what drove me to look for the rotation point, as with it I could correct for mach's reporting.
...but the problems are not all G31 specific - if you want to get surprised try this:
G53 X0 Y0
G54 X0.07071 Y0.7071
G68 Y0 Y0 R45
you should get a WC of X=1, Y=0 after the rotation. If you look at the multimode DROs, that's what you'll see for values (when they are in WC display mode). Now go look at the WC DROs - they will be wrong.
Problem 2: The WC DRos don't comprehend G68
Now for kicks go press the "X Zero" button.... You just told mach to zero the WC X axis - that should place the X0 point at the current position in the WC (which is rotated wrt to the MC). You expect to see the X DRO (and only the X DRO) go to 0 and the offsets change - That's not what happens.
Problem 3: Functions that cause offsets to change ignore G68.
Basically I've concluded that any use of G68 should cause a blinking "Warning, there be dragons here...." message ;-)
Oh, well, not much I can do except write it all up, report it to Brian and hope that fixes make it into a release sometime. In the mean time, I'm going to make my stuff check for G68 and either refuse to do some things or reset the system to G69 as a side effect - those seem to be the only available choices for now.
Dave
-
(;-)
"Warning, there be dragons here...."
Love it Dave I will make a poster for the shop.
One of the problems for the plasma crowd is you cannot HOME the Z in a rotated state . A lot of users use the G28.1 Z to find the top of material and set the Z work height. Needless to say they can't use a G68 to rotate a part to fit a space. I understand the need to not be able to home X/Y but Z cannot effect the G68 (;-)
Maybe Brian will correct some of this .
(;-) TP
-
Please is there for OEMcode "auto tool zero"external button
Tankyou