[handlewanker]

Hi, I'm totally new to any 4th axis moves, so am under some assumptions that may be wrong or right.

I'm also in the process of building a 4th axis so when the day comes I want to have the knowledge to make the correct move etc.

Assuming I'm creating simple hand coded moves and not working with a CAM generated rotation.

The question is........is a 4th axis move the same as an X axis linear move in an absolute mode, but around an object?

Can you have an incremental 4th axis move around an object?

If it is possible to have an incremental degree movement around the work piece where every stopping point becomes A0.....then that would cut out the need to wind back to the A0 starting point each time.......provided you noted how many times and how many degrees you moved in each move if you wanted to wind back to the original A0 beginning.

EG, from A0 if you moved 30 deg in a CW direction and then 20 degrees more this would mean you are now 50 deg from your starting point but at a new A0 point when you stopped and every time you stopped after that.

Also, what would the move be to rotate back ACW from any A0 position........incrementially speaking?
Ian.

[mountaindew]

Hi MD. If you're using the homing kit and home the A axis I wouldn't expect the 4th axis to rewind any further than the homing sensor (I don't use the sensor so I can't test this assumption). However if you enter A0 it will continue to rewind until the initial angle has been covered i.e. if the A DRO reads 3600 degrees the axis will rotate 10 times until A0 is reached. The homing switch should play no role in this.
The G-code I provided in post 7 should eliminate the unnecessary whole rotations, leaving no more than a half rotation to zero.

G10 L20 P[#5220] A[#5423-360*ROUND[#5423/360]]

The #5220 isn't the most important parameter here. It simply represents the current coordinate system i.e. '1' for G54, '2' for G55 etc. If you're working in G54 you could simply use a '1' instead:

G10 L20 P1 A[#5423-360*ROUND[#5423/360]]

The parameter #5423 represents the current A position. The equation is actually very simple. If the current A position is say 3636 degrees (10 full turns plus 36 degrees) the division on the right would divide this value 3636 by 360 giving 10.1. Then ROUND rounds to the nearest whole number giving 10 exactly. Multiplying this rounded result with 360 gives 3600 degrees which is subtracted from the original value of 3636 to give 36 degrees. G10 L20 sets the A position to the result of this calculation i.e. 36 degrees - just like entering this value in the DRO. The A axis hasn't moved yet. Commanding A0 now only needs to rotate the A axis by 36, instead of 3636 degrees.
If this code is used in a subroutine or a post processor you'll have to ensure that the current coordinate system is used - which is where the parameter #5220 comes in handy.
If you enter a large number in the A DRO and type or copy/paste this line of code in the MDI you should see what happens.
I hope this has clarified something (a little?).
Unfortunately I haven't found a way of automatically adding a line of code like this within a Sprut program without modifying the post. The Auxiliary INSERT almost works, but it doesn't add the line number.
Step

Thanks for the help !
I understand the topic better, now for application. I tried to aux insert in Sprutcam and as you stated it does not put a line number in the compiled code. Might work with that or work on that.
Again thanks for the insight !

[IMT]

Does PP require line numbers? I'm still using Mach3 and it doesn't care if there is line number or not, and the Sprutcam post only outputs line numbers to 4 digits and starts over again so they are of no value to me.

[TurboStep]

Does PP require line numbers? I'm still using Mach3 and it doesn't care if there is line number or not, and the Sprutcam post only outputs line numbers to 4 digits and starts over again so they are of no value to me.

Good point! I'd always thought that either you had line numbers or you didn't, but if you had them they had to be correct. I don't know where I got that from but it's apparently untrue - at least for PathPilot. I just tested lines mixed with and without numbers and counting up and down in the same code. The code looks horrible but PathPilot doesn't appear to care.
I'd actually prefer to turn them off altogether because I've never needed them either - how to do that in Sprut?
Thanks for the pointer...
Step

[TurboStep]

Well that didn't take long...
For those of you with the All Post version, in the post processor generator open the Machine Information dialog and deselect NC block numbers:
Attachment 370956
Step

[IMT]

Well that didn't take long...
For those of you with the All Post version, in the post processor generator open the Machine Information dialog and deselect NC block numbers:
Attachment 370956
Step

Excellent!! Thanks

BTW. Mach3 seems to completely ignore line numbers as well. You can add lines of code with no numbers while all the other lines have numbers, copy complete sections of code with numbers and paste elsewhere so the numbers are out of order. Has no affect.
Good to know PP works the same, for when I finally decide it is time to switch (and re-write all my macros).