bdring
Add UVW Linear Axis
Hi, I just saw I should open a issue first. Let me know if I can leave this here. Also, I already did the work for additional rotary axis so wasn't sure if we can repurpose "D" command to bring in D E F rotary axis and use a different letter instead?
You can leave this PR open and refer to an issue that you create after the fact.
D, E, F are not available. https://linuxcnc.org/docs/html/gcode/overview.html#_word
The only real difference between linear and rotary axes is that linear axes are scaled in G20 (inches) mode, while rotaries aren't. If you only work in one G21 (mm) mode, there will not be a problem
Next steps, if the PR is accepted:
- Edit the wiki to acknowledge the new axes
- Check to see if the new axes break WebUI and WebUI-3 and possibly fix them
- Check to see if various senders (http://wiki.fluidnc.com/en/support/gcode_senders) either support or choke on the new axes and document the results in the wiki.
ok i already tested on tinybee and webui shows the new axis in settings and gcode works. I only tested webui and UGS - UGS doesn't show the UVW in the GUI (same with webui) but manually entering gcode works. I will look for the wiki docs.
I added a W axis to my XYZ machine config. This created ABCUV to fill in the missing axes.
I can move all axes except for the W
Grbl 3.9 [FluidNC v3.9.8 (pr/1552-414e4d4c) (wifi) '$' for help]
$X
[MSG:INFO: Caution: Unlocked]
ok
G0 x10 y10 z10 a10 b10 c10 u10 v10 w10
ok
<Idle|MPos:10.000,10.000,10.000,10.000,10.000,10.000,10.000,10.000,0.000|FS:0,0|Pn:Z|WCO:0.000,0.000,0.00
If I add V as the last axis, V does move.
Have you tried all axes?
Hi, admittedly I hadn't tested W axis yet and I can reproduce your issue, W also doesn't work for me.
./Machine/Axes.h:77: static void step(uint8_t step_mask, uint8_t dir_mask); ./Stepper.cpp:34: uint8_t direction_bits; ./Stepper.cpp:70: uint8_t step_bits; // Stores out_bits output to complete the step pulse delay ./Stepper.cpp:71: uint8_t execute_step; // Flags step execution for each interrupt. ./Stepper.cpp:72: uint8_t step_outbits; // The next stepping-bits to be output ./Stepper.cpp:73: uint8_t dir_outbits; ./Stepping.cpp:123:void IRAM_ATTR Stepping::step(uint8_t step_mask, uint8_t dir_mask) { ./Stepping.cpp:126: static uint8_t previous_dir_mask = 255; // should never be this value ./Stepping.h:76: static void step(uint8_t step_mask, uint8_t dir_mask);
I'm not going to pretend like I know what I'm doing but it seems to work now
I did some more testing. I made a XYUW machine. I tested homing with various cycle configs. So far, all work fine.
Changing MAX_N_AXIS causes issues with saved values (coordinate systems). It seems to work when upgrading, but caused a crash when reverting. I had to force a reinstall of a clear partition in order for old versions to work again.
We probably need some sort of version control of the settings. Grbl does that with ...
// Version of the EEPROM data. Will be used to migrate existing data from older versions of Grbl
// when firmware is upgraded. Always stored in byte 0 of eeprom
#define SETTINGS_VERSION 10 // NOTE: Check settings_reset() when moving to next version.
We would need to figure out how to deal with existing releases.
We might consider adding other values as well. (Tool Num and TLO)
I have been doing a lot of type sanitization in the S3OldCompiler branch. I got rid of most bare "int" types in favor of more explicit types, to avoid complaints from modern compilers. Then I changed a lot of things that used uint8_t "just because" into finer-grained types like axis_t, motor_t, AxisMask, MotorMask, objnum_t and pinnum_t. axis_t, which is now an enum, was particularly invasive, and resulted in finding quite a number of potentially-dubious usages. After making those changes, I incorporated the UVW extensions into the S3OldCompiler branch.