ADDITIONAL 4th AXIS and other changes

[robomechs]

Changes

1. 4th axis was added (tested)
2. grbl.h issue#36 (not tested)
3. main.c issue#38 (tested)
4. planner.h issue#41
5. probe.c uint16_t probe_invert_mask
6. serial.c, serial.h, usb_endp.c issue#46 now can use old and changed code by chooseing #define USB_CHANGED_DEBUG in serial.h (tested not in depth)
7. system.c issue#40
8. system.c EXTI_InitStructure.EXTI_Trigger is Rising_Falling instead of EXTI_Trigger_Falling (for NC and NO buttons. Need more tests)
9. stepper.c issue#41
10. stepper.c issue#49
11. stepper.c (config.h) NEW: STP_DRIVERS_ENABLE_DELAY (tested. see description in config.h)
12. stepper.c (config.h) issue#48 STEP_PULSE_DELAY now works (tested, but need more tests)
13. stepper.c issue#50 (tested)
14. system.c GPIO_PinRemapConfig(GPIO_Remap_SWJ_JTAGDisable, ENABLE); // to enable PA15, PB3, PB4 pins (tested)

[robomechs]

15. 5th axis was added (tested not in depth)
16. G10 L20 bug for 4 (and more axis) fixed
17. NEW: USE_RESET_BTN_AS_ESTOP (tested not in depth. see description in config.h)
18. STEP_PULSE_DELAY tested and improved
19. improved performance and stability in stepper.c
20. minor fixes
21. bug when using normally closed switch for hard limits #60, Bug in homing when an axis uses a pin between 8 and 15 for as step pin #61 in stm32grbl11_11122018.zip

for atollic truestudio:

stm32grbl11_31072018.zip

stm32grbl11_11122018.zip

[klembaris]

Hi,
nice work! Axis move smooth.

Thanks

[robomechs]

Not yet tested thoroughly!
In addition, sometimes for some unknown reason the response from the controller to the request is delayed for a noticeable time (up to 1-2 seconds). This is rare and only affects the display of the current position. It does not affect to the code execution.
Therefore, improvements are required.

[klembaris]

Several times had gcode terminated before end, but now seems its ok.

[robomechs]

Several times had gcode execution before end

What do you mean?

[klembaris]

Before finished cut, gcode was terminated.

[robomechs]

could you send G-code example and GRBL settings?

[klembaris]

Before i used another control soft, and maybe its was control software problem.
test files.zip

[robomechs]

Ok, thanks! Please, report me if the error will be repeated.

[klembaris]

Sure!

[robomechs]

21. 6th axis was slightly tested
    Connection diagram (Modified "The generic stm23f103 pinout diagram" by Rasmus Friis Kjeldsen reblag.dk/stm32)
    ONLY for ABC_AXIS_EXAMPLE cpu map (not for default usbcnc CPU_MAP_STM32F103 cpu map)

ONLY for ABC_AXIS_EXAMPLE cpu map (not for default usbcnc CPU_MAP_STM32F103 cpu map)

[LETARTARE]

Hello,
@yaroslavVl
thank you for this work on the 4th axis.

@klembaris
thank for the file 'aspkr.nc'.
Here is a representation of the path of the tool and the axis of rotation 'A' : with 'Mega2560' and 'grblQ'

I will try to do it with the version 'Stm32F103' ...

Have a good day

[ArsBinarii]

Hey guys, might be a stupid question but I can't find the branch or any configuration for the 4th and 5th axis in 7e3308b. Where is the code for the 4th and 5th axis?

Thanks

[robomechs]

There are no branches for the 4th and 5th axis.
Unfortunately @usbcnc has no activities since January 2017.
See #51 (comment) to get version for 4/5/6 axis, and #51 (comment) for pinout.

[ArsBinarii]

Thanks

[hruijin]

I need 4 axis. How do I change the 4 axis number to "C"? In which file? How to modify? Thank you very much!

[robomechs]

4th axis is A.
For obtain 4th axis see post above.
4-A, 5-B, 6-C.

[siy]

I think it worth to apply all changes to your fork and create pull request. This will simplify maintenance of the updates for you and enable forking from your repo with all changes applied.

[robomechs]

I think it worth to apply all changes to your fork and create pull request. This will simplify maintenance of the updates for you and enable forking from your repo with all changes applied.

I will create a new repo, after I fix 5 and 6 axes.

[Alfrederson]

1. 5th axis was added (tested not in depth)
2. G10 L20 bug for 4 (and more axis) fixed
3. NEW: USE_RESET_BTN_AS_ESTOP (tested not in depth. see description in config.h)
4. STEP_PULSE_DELAY tested and improved
5. improved performance and stability in stepper.c
6. minor fixes
7. bug when using normally closed switch for hard limits #60, Bug in homing when an axis uses a pin between 8 and 15 for as step pin #61 in stm32grbl11_11122018.zip

for atollic truestudio:

stm32grbl11_31072018.zip

stm32grbl11_11122018.zip

What should I do in order to compile this from Platformio instead of from Atollic?
Man, IDE's for Arm really are bad

[robomechs]

Ok, it seems like 5 and 6 axis work now, I've shared new repository with all changes.

[dbxzjq]

HI @yaroslavVl
Through the following tests, the actual frequency is obtained:
With 1605 ball screw, 5 mm lead, 1.8 degree stepping motor, 40 pulse per millimeter.

Under 8 subdivisions, 320 pulses are set at $100 - $103 = 320, $110 - $113 = 2000 to test G1x1000y1000Z1000A1000F2000. It takes 60 seconds to run the program. The uniaxial frequency is only 320 * 1000 / 60 = 5.333KHZ. The frequency calculated by F2000 is 320 * 2000/60 = 10.666KHZ per axis. The actual time of G1x1000y1000Z1000A1000F2000 should be 30 seconds, but it is twice as slow as that of the uniaxial G1X1000F2000 code. Complete, this is correct, using G0X1000Y1000Z1000A1000 can run in 30 seconds to complete, the time is very correct!

G0 is executed according to the maximum F value. The running time can be 30 seconds. That's right. Why set F2000 under G1 to run twice as long as 30 seconds? And the operating frequency of each axis is only about 10KHZ, so the performance of STM32 can't be like that, can it? Is it the problem of G interpreter algorithm or what?

The test parameters are as follows：
$100=320.000
$101=320.000
$102=320.000
$103=320.000
$110=1000.000
$111=1000.000
$112=1000.000
$113=1000.000
$120=200.000
$121=200.000
$122=200.000
$123=200.000
TEST: G0X1000Y1000Z1000A1000 = 60 seconds END is Correct time
G1X1000Y1000Z1000A1000F1000 =120 seconds END is Error time

$100=320.000
$101=320.000
$102=320.000
$103=320.000
$110=2000.000
$111=2000.000
$112=2000.000
$113=2000.000
$120=200.000
$121=200.000
$122=200.000
$123=200.000
TEST：G0X1000Y1000Z1000A1000 = 30 seconds END is Correct time
G1X1000Y1000Z1000A1000F2000 =60 seconds END is Error time

Use larger subdivisions, such as 640 pulses per millimeter, 1280 pulses per millimeter, 2560 times the time to execute, and the higher the number of pulses, the longer it takes.

How much frequency can the STM32 6 axis support now?

[robomechs]

Did you test the usbcnc/grbl firmware or native grbl firmware (on Arduino)?
Is there a same result as with my version of firmware?

[dbxzjq]

hi @yaroslavVl
native grbl firmware (on Arduino 328)TEST：
$100=320.000
$101=320.000
$102=320.000
$110=2000.000
$111=2000.000
$112=2000.000
$120=200.000
$121=200.000
$122=200.000
G0X1000Y1000Z1000 = 30 seconds END
G1X1000Y1000Z1000F2000 =52 seconds END
The three parameters of $100 - $102 = 160 or 320 or 640 were tested in exactly the same way. G0 took 30 seconds and G1 52 seconds.
usbcnc/grbl firmware and native grbl firmware The results are basically the same.

Is this due to the forward-looking algorithm? But I don't know why G0 is right. Even the reason of forward-looking algorithm can't be that G1 instruction time is so slow. Can this problem be improved?

In addition, the acceleration did not seem to have any effect on the execution time.

[dbxzjq]

native grbl firmware (on Arduino 328)TEST：
$100=320.000
$101=320.000
$102=320.000
$110=2000.000
$111=2000.000
$112=2000.000
$120=200.000
$121=200.000
$122=200.000
G0X1000 30 seconds END <Run|MPos:916.447,0.000,0.000|FS:2000,0> F is 2000
G0X1000Y1000 30 seconds END <Run|MPos:993.769,993.769,0.000|FS:2828,0> F is 2828
G0x1000Y1000Z1000 30 seconds END <Run|MPos:992.644,992.644,992.645|FS:3464,0> F is 3464

This is the feed rate F of executing G0 feedback from single or multiple axes, which means that the maximum feed rate of single or multiple axes is not the maximum feed rate set by $110 - $112. So when using G code with F parameter like G1, it does not match the actual rate, and the actual execution time is all slowed down. This question is not known whether it is the BUG of native RGBL code?
Relevant rate control found on RGBL instruction introduction：
Feed Overrides

Immediately alters the feed override value. An active feed motion is altered within tens of milliseconds.
Does not alter rapid rates, which include G0, G28, and G30, or jog motions.
Feed override value can not be 10% or greater than 200%.
If feed override value does not change, the command is ignored.
Feed override range and increments may be changed in config.h.
The commands are:
0x90 : Set 100% of programmed rate.
0x91 : Increase 10%
0x92 : Decrease 10%
0x93 : Increase 1%
0x94 : Decrease 1%

I use 0x91 instruction to increase the feed rate to 200%. When I execute G1X1000Y2000Z2000F2000, the F value of feedback is 3464, the F value of feedback of G1X1000F2000 is 2000, and the feedback of feedback of G1X1000Y1000F2000 is 2828. All three kinds of execution time can be completed in 30 seconds.

This variable feedback feed rate is the same as the maximum rate set at $110 - $112. It is correct. For example, the feedback f is 3464, the execution time is 30 seconds, and the actual running time of G1X1000F2000 is 30 seconds, but 3464 = F2000, and the single axis feedback is different from the multi-axis feedback, and the maximum setting is $110 = 2000. The value is totally different

Does this translate the value of the timer into a BUG when it enters the F value? Of course, the process of acceleration and deceleration is changing. Feedback message can also see that the F value of the process of acceleration and deceleration is changing. After entering a constant rate, the value is fixed. Would this be wrong in this calculation process to calculate the maximum F value? After multi-axis, the F-value of BUG is wrong, because it is completely correct under single axis, the F-value feedback and execution time are correct, and this phenomenon occurs after multi-axis running at the same time.

The usbcnc / grbl firmware part of the code is the same as the original GBRL, so the problem is exactly the same.