Few months ago I got an PocketNC V2-50 machine.
One issue that I’m having is that it’s rewinding it’s B-axis back. And that takes a lot of time. On top of that, there is a limit of -9999 +9999 degrees that I can rotate. Any value over those, the machine will do an rewind. This is configured to Fusion post-processor. I have had small medical parts that rewind 3 times in a part and this quickly multiplies to hours of time when I have done multiple parts. So this is something that I would like to solve.
PocketNC / LinuxCNC configuration
I read from [1] that there is an configuration item called WRAPPED_ROTARY in LinuxCNC. So I tested it, simply changed it from my PocketNC configuration, see image below. After tests, I got either positive or negative rotation ok, not both. Other direction always gave “B-axis outside of negative (or positive) limits” error. Based on [2] I increased MAX_LIMIT and MIN_LIMIT to 1e99 and -1e99. After that errors were gone. Here is my current configuration:

Testing with MDI-commands to see how this works.
- Home
- MDI commands as follows:
1) G90 B0 F1000

2) G90 B350 F1000 // makes an 350 degree motion counterclock to absolute position 350
Both DRO and MDI at the same until this position, eg. B position is 350 as to be expected.

3) G90 B340 F1000 // makes again an 350 degree motion counterclock to obtain absolute position 340. Coordinates 700 at this point (360 + 340 = 700 == correct)

4) G90 B0 F1000
When we then move to 0, then the way machine is configured from the factory it would unwind all the way back, almost two full rotations clockwise. But with this new configuration, movement is only 20 degrees and that is what we really want. Position is 720 as is 2×360 as 2 full rotations (2×360).

So this is all good. And if we want to another way, eg. clockwise, we just output negative signs:

5) G90 B-10 F1000
This moved clockwise 350 degrees to position B-10 and new DRO is 370.
6) G90 B-0 F1000
This resulted 10 degree motion in clockwise and DRO is reading 360 as is ok.

So in summary we have an working unlimited rotary axis. We need to discuss with PocketNC support if calibration tables would be valid in this case as it seems from the post [3] that they might not be.
Fusion Post configuration
But I can’t figure how to modify Fusion 360 post processor to output to output my g-code correctly.
I tried to run small tests of rotary toolpaths with Fusion. I have subscribed to Manufacturing Extension and would like to utilize that handy rotary toolpath. I managed to get G-code partially working. Another direction is working and another direction is not. Depending on my configuration, either climb-milling or conventional-milling is working ok.

Depending on axis configuration on Fusion Post I can get either Climb milling or Conventional milling working.
Lets look at Conventional Rotary toolpath start:
%
(AXIS,stop)
(1001)
N10 G21
N15 G90 G94 G40 G17 G91.1
N20 G53 G0 Z0.
(ROTARY1 CONV)
N25 G49
N30 M5
N35 G53 G0 X63.5 Y63.5
N40 M0
N45 T18 M6
N50 S40000 M3
N55 G54 G0N60 G0 A0. B-90.
N65 M7
N70 G1 X0.599 Y48.814 F10000.
N75 G43 Z24.993 H18
N80 G1 A0. B-90.
N85 X0.295 Z12.3 F10000.
N90 X0.292 Z12.203 F400.
N95 Z10.3
N100 X0.279 Z10.213 F800.
N105 X0.238 Z10.128
N110 X0.17 Z10.059
N115 X0.087 Z10.015
N120 X0. Z10.
N125 B-87.035 F916.73
N130 Z9.998 B-82.192
N135 Z9.997 B-82.185
N140 Z10. B-80.607
N145 Z9.997 B-79.265
N150 B-79.258
N155 Z10. B-76.933
N160 Z9.997 B-76.03
N165 B-76.022
N170 Z10. B-74.166
N175 Z9.996 B-72.696
N180 B-72.688
N185 Z10. B-70.493
N190 Z9.996 B-69.273
N195 B-69.266
N200 Z10. B-67.738
N205 Z9.996 B-65.858
N210 B-65.851
N215 Z10. B-64.064
N220 Z9.996 B-62.443
N225 B-62.436
N230 Z10. B-60.391
N235 Z9.995 B-58.992
N240 B-58.985
N245 Z10. B-57.636
N250 Z9.995 B-55.52
N255 B-55.512
N260 Z10. B-53.963
N265 Z9.996 B-52.054
N270 Z9.995 B-52.047
N275 Z10. B-50.289
N280 Z9.997 B-48.912
N285 B-48.905
N290 Z10. B-46.616
N295 B-39.269
N300 Z9.997 B-38.294
N305 B-38.287
N310 Z10. B-36.515
N315 Z9.997 B-34.082
N320 Z9.995 B-31.005
N325 Z10. B-29.252 F915.92
N330 Z9.996 B-27.566
N335 B-27.559 F917.14
N340 Z10. B-25.579 F915.85
N345 Z9.996 B-24.144
N350 B-24.137 F917.13
N355 Z10. B-22.824 F915.8
N360 Z9.996 B-20.764
N365 B-20.757 F917.12
N370 Z10. B-19.15 F915.57
N375 Z9.996 B-17.428
N380 B-17.421 F917.11
N385 Z10. B-15.477 F915.38
N390 Z9.996 B-14.135
N395 B-14.128 F917.1
N400 Z10. B-12.722 F915.11
N405 Z9.996 B-10.899
N410 B-10.892 F917.07
N415 Z10. B-9.119 F914.51
N420 Z9.996 B-7.713
N425 B-7.706 F917.06
N430 Z10. B-6.364 F913.71
N435 Z9.996 B-4.599 F912.81
N440 B-4.592 F917.06N445 Z10. B-2.691 F910.26
Up to this point rotation is wrong, it’s climb milling. B is decreasing up until this point and sign is negative. Why is this, that is something I don’t know ?
From this point onwards it’s conventional milling as supposed to be. B is increasing and sign is positive.
N450 B12.916 F916.71
N455 Z9.997 B13.877 F915.76
N460 B13.884 F916.99
N465 Z10. B15.671 F915.77
N470 Z9.997 B17.156
N475 B17.163 F917.
N480 Z10. B19.344 F915.98
N485 Z9.997 B20.542
N490 B20.549 F917.02
N495 Z10. B22.762 F916.03
N500 B26.023 F916.72
N505 Z9.996 B27.558 F915.89
N510 B27.565 F917.14
N515 Z10. B29.696 F916.02
N520 Z9.995 B31.009
N525 B31.016 F917.14
N530 Z10. B32.451 F916.03
N535 Z9.995 B34.481
N540 B34.489 F917.15
N545 Z10. B36.125 F916.07
...
N10560 Z9.996 B265.418
N10565 B265.425
N10570 Z10. B267.169 F916.54
N10575 Z9.997 B268.482
N10580 B268.489 F917.05
N10585 Z10. B270. F916.53
N10590 X-0.086 Z10.015 F800.
N10595 X-0.17 Z10.059
N10600 X-0.238 Z10.128
N10605 X-0.279 Z10.213
N10610 X-0.292 Z10.3
N10615 Z12.203 F10000.
N10620 X-0.598 Z24.993 F10000.
N10625 G49
N10630 M9
N10635 G49
N10640 G53 G0 Z0.
N10645 G53 G0 X63.5 Y63.5
N10650 A0. B0.
N10655 M30
(AXIS,stop)
%
After this program is run, there is only about 45 degree rotation to zero, no rewinding. DRO is reading 2520 and that is ok since that is 7 x 360.

Motion is somewhat jerky and I suspect this is due to G61 and/or G64 path blending or excact stop and axis kinematics configured start/stop accelerations. I need to look into this later, I have seen videos with LinuxCNC configured ok for rotational axis and smooth milling but this seems to be complicated subject.
Here’s Climb milling toolpath that is not at all working:
%
(AXIS,stop)
(1001)
N10 G21
N15 G90 G94 G40 G17 G91.1
N20 G53 G0 Z0.
(ROTARY1 CLIMB 2)
N25 G49
N30 M5
N35 G53 G0 X63.5 Y63.5
N40 M0
N45 T18 M6
N50 S40000 M3
N55 G54 G0
N60 G0 A0. B-90.
N65 M7
N70 G1 X-0.598 Y48.814 F10000.
N75 G43 Z24.993 H18
N80 G1 A0. B-90.
N85 X-0.294 Z12.3 F10000.
N90 X-0.292 Z12.203 F400.
N95 Z10.3
N100 X-0.279 Z10.213 F800.
N105 X-0.238 Z10.128
N110 X-0.17 Z10.059
N115 X-0.086 Z10.015
N120 X0. Z10.
N125 Z9.996 B-91.516 F916.53
N130 Z9.997 B-91.523 F917.05
N135 Z10. B-93.604
N140 Z9.996 B-94.58
N145 B-94.587
N150 Z10. B-96.359 F916.55
N155 Z9.999 B-109.744
N160 Z9.996 B-110.899
N165 B-110.906 F917.06
…
N10480 Z9.996 B-82.29
N10485 B-82.297 F917.08
N10490 Z10. B-84.414 F916.57
N10495 Z9.996 B-85.418
N10500 B-85.425
N10505 Z10. B-87.169
N10510 Z9.997 B-88.482
N10515 B-88.489
N10520 Z10. B-90.
N10525 X0.086 Z10.015 F800.
N10530 X0.17 Z10.059
N10535 X0.238 Z10.128
N10540 X0.279 Z10.213
N10545 X0.292 Z10.3
N10550 Z12.203 F10000.
N10555 X0.598 Z24.993 F10000.
N10560 G49
N10565 M9
N10570 G49
N10575 G53 G0 Z0.
N10580 G53 G0 X63.5 Y63.5
N10585 A0. B0.
N10590 M30
(AXIS,stop)
%
B-motion does not move in correct direction.
Between these lines
N125 Z9.996 B-91.516 F916.53
N130 Z9.997 B-91.523 F917.05
B-axis rotates almost full 360 degrees clockwise. As we saw from earlier g-code, correct behaviour would be B to decrease while sign is negative to have correct motion.
PocketNC Fusion360 PostProcessor has an line
// var previousABC = new Vector(0, 0, 0); // previous ABC position if maintained in post, don't define if not used
That could be related or not, I tried to uncomment it but did not understand yet what it does by reading the post-processor code.
To understand better, I checked LinuxCNC docs and they have this comment regarding WRAPPED_ROTARY:
WRAPPED_ROTARY
When this is set to 1 for an ANGULAR axis the axis will move 0-359.999 degrees. Positive Numbers will move the axis in a positive direction and negative numbers will move the axis in the negative direction.
To be sure, I looked into LinuxCNC code:
interp_convert.cc:
CHKS((block->b_flag && settings->b_axis_wrapped &&
(block->b_number <= -360.0 || block->b_number >= 360.0)),
(_("Invalid absolute position %5.2f for wrapped rotary axis %c")),
block->b_number, 'B');
interp_find.cc:
if(block->b_flag) {
if(s->b_axis_wrapped) {
CHP(unwrap_rotary(BB_p, block->b_number,
block->b_number - s->BB_origin_offset - s->BB_axis_offset - s->tool_offset.b,
s->BB_current, 'B'));
} else {
*BB_p = block->b_number - s->BB_origin_offset - s->BB_axis_offset;
}
} else {
*BB_p = s->BB_current;
}
And here seems to be actual calculation:
interp_find.cc:
/* Find the real destination, given the axis's current position, the
commanded destination, and the direction to turn (which comes from
the sign of the commanded value in the gcode). Modulo 360 positions
of the axis are considered equivalent and we just need to find the
nearest one. */
int Interp::unwrap_rotary(double *r, double sign_of, double commanded, double current, char axis) {
double result;
int neg = copysign(1.0, sign_of) < 0.0;
CHKS((sign_of <= -360.0 || sign_of >= 360.0), (_("Invalid absolute position %5.2f for wrapped rotary axis %c")), sign_of, axis);
double d = floor(current/360.0);
result = fabs(commanded) + (d*360.0);
if(!neg && result < current) result += 360.0;
if(neg && result > current) result -= 360.0;
*r = result;
return INTERP_OK;
}
Here are some tests with PocketNC WRAPPED_ROTARY = 1:
- Home
- G90 B-45 F3000 Moves clockwise 315 degrees to reach position 45
- Home
- G90 B-315 F3000 Moves clockwise 45 degrees to reach position 315
- Home
- G90 B10 F3000 Moves counterclockwise 10 degrees
- Home
- G0 G90 B350 F3000 Moves counterclockwise 350 degrees
- G0 G90 B330 F3000 Moves counterclockwise 340 degrees to reach 330 absolute position
Current Fusion output when Rotary climb is like this:
G0 G90 B-91.000 F3000 – clockwise 270-1=269 degree
G0 G90 B-95.000 F3000 – clockwise 360-4 = 356 degree
So this is not good. Should be
G0 G90 B-95.000 F3000
G0 G90 B-91.000 F3000
to get clockwise rotation of 4 degrees, so a) negative sign (this is ok) and b) decreasing numbers, not increasing. How to modify post processor to obtain this ?
Summary
positive sign = conventional milling, counterclockwise motion
negative sign = climb milling, clockwise motion
If called
a) G0 G90 B-10
b) G0 G90 B-20 # this would result clockwise motion of 350 degrees
c) G0 G90 B-10 # this would result clockwise motion of 10 degrees
Climb milling with clockwise rotation would be obtained with this sort of G-code:
G0 G90 B-359.99
G0 B-350
G0 B-340
G0 B-330
Documents:
[1] LinuxCNC posts discussing WRAPPED_ROTARY-axis: https://forum.linuxcnc.org/10-advanced-configuration/34908-unlimited-rotary-axis?start=10
[2] LinuxCNC configuration options: http://linuxcnc.org/docs/2.7/html/config/ini-config.html#_axis__lt_num_gt_section
[3] PocketNC Google Group post regarding B-axis rollover: https://groups.google.com/g/pocket-nc/c/JWkws7rWxL4/m/q4fwT6RqBQAJ
http://linuxcnc.org/docs/html/gcode/g-code.html#gcode:g90-g91
https://www.mail-archive.com/machinekit@googlegroups.com/msg01772.html