1. ## rotary axis control

I'm looking to write some G-code for the 4th axis rotary. The 4th axis will be doing a lot of unidirectional rotation.

Looking at Mach3, if I jog in a circle, the A-axis value just gets bigger and bigger as it completes rotations. But of course 20deg=380deg=740deg. Then again, I see where the machine wouldn't otherwise understand whether a command to go from 20 deg to 340 deg meant go -40 deg or +320 deg. Actually General Logic Config does have the A-axis marked as rotational, but the Motor Tuning still says "inches" not "degrees" too.

Is this simply going to mean constantly increasing the A-axis coordinates in the G-code without limit? This could mean extremely large values in the G-code. Is there a G-code/Mach3 limit on number size? In fact if I run one part and it increments the axis by 10 jillion units and need to run the same part again, I only need need to return that stepper to zero deg, not back up 10 jillion units to zero which would be a bunch of pointless rotations.

Or am I doing it wrong?

2. Play around with the rotational setting in General Config.

Rot 360 rollover

and

Ang Short Rot on G0

Also, 20° does not always equal 740°.

G1 X10 A20

is not

G1 X10 A740

3. Ahhh.. ok. So that'll make it go CW/CC based on whichever way is shorter. What if it's a straight 180deg?

For that matter, what happens if you don't select Ang Short Rot on G0? The Mach3 manual doesn't seem to say. I could see the need to simply say "do everything a CW rotations", because it seems practical to avoid fighting inertia by going the long way around, or consistency of finish- but there's no "take everything as CW" or "take everything as CCW". Well I could always force it to take "the long way around" by giving it 0 to 50 deg then 50 to 100 deg instead of 0 to 100, which would make turn in the negative dir.

4. That's only for rapid moves. For regular feedrate moves, you always need to specify + or - angles for direction.

I don't have actual answers, so I suggest playing around a little to see how it actually works.

• Hmm got another couple of problems here.

One, I have the stepper actually direct-driving the work, which makes it 0.18deg/microstep, or 5.555555555(...) steps per deg. But it seems to get goofy when I enter fractional values. If I enter an absurdly large speed expecting the system to reduce it to the max allowed by the current freq, it won't reduce it and I get errors. Well, I'm just gonna do whole numbers for now and ignore the units.

But here's the significant one- when I hit Tab and bring up the Jog window, then hit 4+/4-, the 4th Axis stepper spins and the coordinate window shows 4th incrementing. Great.

I ran G-code and the "A" moves incrementing the coordinate window- but the stepper does not move. I tried entering it from the MDI. Again, coordinates show movement, but the stepper will not move. Entered Y1.0 in MDI and the Y-axis moved. Hit Tab, and the control makes the 4th Axis stepper move along with the coordinates as intended.

I've got no idea on this one! Why does it accept the G-code and move the coordinates but not physically step? It's clearly hooked up ok since the Jog can move it around.

• Hmm got something... the 4th axis will work with G-code when I change the units from 40 per "inch/mm" and a really large max speed to something similar to what was in the other X/Y/Z. This may take awhile to figure out!

• Is your rotary a Sherline and are you setup for inches or metric?

• Neither! There's NO rotary table. There's a mandrel and a pair of bearing blocks and the workpiece is just foam. Foam which can and should turn fast. So the 1.8deg/fullstep, 0.18deg/microstep stepping motor is just coupled straight onto the mandrel. Thus the 5.55555(...) steps per degree.

Ah I see what you're saying. Mach3 has no sense of "degrees" in Motor Tuning. So in motor tuning we're just taking the inch/mm units and thinking of them as a degree by as far as Mach3 knows, it's still an "inch". If the Native Units field and the G-code are both in inches, all is good and you can call these degrees. But if the Native Units are inches G-code invokes MM units with G71, then Mach3 converts the current coordinates and interpretations of G-code coordinates to MM on ALL axes. Ouch. That means it'd try to make "metric degrees" out of it by multiplying by 25.4 mm/in which is nonsense.

Or does the selection of the A-axis being "Angular" in General Config fix that problem? Hmm... checking... no, it does not fix that. Well, all my files are in inches anyways.

• Try setting it for 200 x 18 = 3600 steps per inch.

CR.

• Originally Posted by Crevice Reamer
Try setting it for 200 x 18 = 3600 steps per inch.

CR.
Well if the "inch/mm" field != whole degrees, there's no way to enable the 360-rollover feature.

I gave up on the 360 rollover for now and disabled it. I have 2000 steps/unit, so A0 to A1 is one clockwise rotation which works fine for me.

Now I have this problem. Again, manually written G-code here. I have a bunch of steps and say each one needs to be 10 rotations of A.

I could write out move1 A10, move2 A20, move3 A30...
Problem is, the code cannot easily be maintained. If I insert an extra line in there between move1 and move2, then I'd have to use a move to A20 to get the rotation. Then the move2 would see no rotations because it's already at A20. Basically any change in the code requires modifying the code all the way down. For that matter, at the end of the code A could be at 1000. Change parts and restart the G-code and it tries to jog back 1000 turns for no real reason unless you manually click on Zero 4 beforehand.

So I thought, "hey I don't give a rat's ass about absolute position of A, so can't I just zero it after every move, wherever it is?
I tried the G10 L2 P1 Axxx command, but that adds/subbs an offset to whatever the cumulative value of A has become. So I can't do:
(assuming A=0 and P1 Aoffset=0 to start out)
G1 X1 A10 (does 10 turns)
G10 L2 P1 A10 (becomes zero)
G1 X2 A10 (does to turns)
G10 L2 P1 A10 (has no effect because offset is already 10, needs to be 20, but this would create the exact same problem of having to change every following line in the file after adding a line mid-file)
G1 X3 A10 (since the last line didn't do what I wanted it won't turn at all because we're already at A10)

G52 offset control produces the same situation. If A=30, and we try G52 A30, A does go to zero- but then G1 A30 and it turns, then G52 A30 has no effect because that's an offset from machine coord not offset off current coords.

• In General config, do you have "A axis is angular" checked. If i switch from inch to mm, the linear axis' all change, but the A stays the same.

Also, if you use G91, you can rotate incrementally. However, I just spent 30 minutes playing around and was getting really strange results. Also tried creating a macro to zero the A axis between moves (DoOEMButton (1011) ) and caling it between moves, but it didn't seem to work correctly.

• Originally Posted by ger21
In General config, do you have "A axis is angular" checked. If i switch from inch to mm, the linear axis' all change, but the A stays the same.

Also, if you use G91, you can rotate incrementally. However, I just spent 30 minutes playing around and was getting really strange results. Also tried creating a macro to zero the A axis between moves (DoOEMButton (1011) ) and caling it between moves, but it didn't seem to work correctly.
A is Angular is checked, but it doesn't seem to work.
I'm just gonna stick with inches. This isn't a big thing. None of my stuff is mm.

G91 wouldn't work well because all coordinates in the command become relative. To do a mill-turn, you must specify 10 rotations and move to a new X & Y in the same motion. It would be impractically confusing to write code with all X Y relative to the previous positions.

OH HEY I MISSED IT. G92 will do the job! I don't know how I overlooked that! OK, I can just G92 A0 before each turning-move. That zeroes the A and the next A30 always means 30 rotations. SWEET!

• Page 1 of 2 12 Last