I think you are misunderstanding what that setting does. If Rot Rollover is selected it will move the shortest distance to the position specified but if rot rollover is not chosen then the axis will be temporarily seen as a position in relation to 0 and 360 degrees and it will move to that position by the shortest route, it will not zero the DRO which I think you are wanting.
To zero the DRO you could use the screen button or write a custom macro and insert the m code for it in your G code at the appropriate point.
Hood

Sorry Hood,
I don't think I am misunderstanding the function.  It should be shortest path to the -commanded- position while avoiding unnecessary turns. This normally assumes that not only the move is executed to bring the mechanics to this position, but also that position counters are set to whatever was the end-position of the move.
If not, please tell me what advantage is has to keep the old position instead of the new one.
By the way - it is not 'zeroing the axis' in general. Just in this example it was to return to the position '0'.

No doubt, a macro may correct this problem.  But I am really advocating MACH3 and I'd love to understand why this works as it works. And if it's not a design intend, why it is not seen as a problem/mistake.

Uli

Well I will try and explain as I understand. The feature is really meant for use when using Rotational Roll over so that it will move the shortest distance to the position you command. Now because you do not have that checked it will temporarily treat the position it is at as a position of a rotation, eg if at 3599 degrees and you commanded a G0A0 it would move one degree forward and the DRO would read 3600 degrees, if you were at 3601 degrees and commanded the G0A0 it would move back one degree and the DRO would read 3600 as before.
 If you want to reset the zero position on the axis you will either need to do a home move, press the zero axis button or if wanting to do it from within code you can as said write a ciustom macro and have the m code for that macro in your G Code.

Hood

Hood,

please let me know, what use I can make of the fact that a move G0 A0 ends at a position of A3600 ?
This makes no sense for me. If I say 'G0 Ax' I expect the axis to be at x at the ende of the move. Both, mechanical and logical.

Uli

Uli
 What you are attempting to use this function for, is as far as I can see, NOT what it is intended for. I see it as a means of indexing the rotational axis to a desired position  within its rotation, if you are wishing to reset the DRO to zero then you should write a macro which will do what you want.
Hood

Hood,

it looks like we'll not find together...

Anyways. For me, it makes no sense to misuse a command to to something that is completely different from it's normal function just because a switch is set.
I'd have no problem with whatever additional G-command to do something like 'move rotational axis to a modulo position'.
A G0 command has to end at the commanded position, completely independend from what else could be desirable in very specific other situations.

But let's stop here before this discussion is going to be the neverending story.

I have my opinion, you have your's.

Thanks
Uli

I have the opinion that it is meant to be used in conjunction with the rotational rollover mode and when used with that it acts exactly as it should do. It may well be that it is meant to work differently if you do not have rotational rollover chosen.

Hood

what use I can make of the fact that a move G0 A0 ends at a position of A3600

I see what you mean, once A is set to home ( Zero world A axis here ) / there are no offsets for  A, machine coordinates will / are  keeping track of ALL the rotations.
You can at any time change A to 0 for the  program coordinates and that will not change the machine coordinates, if you do a G28 A0 it will home the A axis back to 0 doing  as many rotations as you have totaly moved.  Now if you G0 A-3600 for example it will go back to A = 0.

Thinking we / you / I need to look at Program and Machine coordinates and  get a better understanding of how things are being kept track of and then relate the appropriate G0 A... move for what needs to be done with different settings.

That said, just don't assume how something is supposed to work, need to see how it all works in light of it all. Not saying that anybody is right or wrong, just that from a simplistic read of the definitons of those posted config settings.....well, can get confusing if you go beyond them.

Will also add, not knowing the logic of the program writer,guess will need to figure it out, accept it or make recommendation for change which is more logical if logical. Hmm....sounds like Spock from StarTrek. 

RICH
 

I have the opinion that it is meant to be used in conjunction with the rotational rollover mode and when used with that it acts exactly as it should do. It may well be that it is meant to work differently if you do not have rotational rollover chosen.

Hood

I think Hood nailed it here.
Perhaps the need never arose or it was never considered to zero the axis after the short trip to the nearest increment of 360.
Would be a shame to request Brian to drop what he's doing to look into fixing it in the code when a simple "DoOEMButton 1025" in a M call works beautifully.

I learned some good stuff here today,
Thanks

Folks,

I certainly can live with any call in a macro.

I did not want to stress it again, but as it appears over and over ....
No, I do not expect to zero the axis after a short move just because it's target position is by chance at a mechnical zero position.
What I expect is that whatever move I make, the result in the DROs is the commanded position. No matter it there was a physical move, it this was clockwise or counter-clockwise, short or long.

My English language will never meet Rick's sophisticated constructions. Hopefully the long discussion is not the result of me sounding like Dr. Strangelove. ;-)

Uli