4th axis ?

[LETARTARE]

Bonne année à tous.
Happy New Year everyone.
Frohes Neues Jahr alle.
Buen año a todos.

@chamnit
Is the 4th axis (rotary or linear) planned ?
Or do we have to wait for 'Gnea' ?

[dguerizec]

Hello @LETARTARE

You can check this PR for 4th axis, and if you can test it, I'd be happy to know the results :)

[electrokean]

Thanks @dguerizec for doing that. I've been meaning to update my fork, but just never got around to it.
I orginally created that 6-axis fork for some industrial testing robots I helped build with a couple of clients.
I currently only have a 3-axis 6040 CNC operational, and it is actually running off Mach 3 for a few reasons I won't go into. When I get some free time, I will pull out my Mega and prototype shield and also some additional small stepper motors and drivers for the A/B/C axes, and give this a test - but it probably won't be this month.

[LETARTARE]

Hello @dguerizec
Thanks for your answer.
Your svn648 Version (Grbl1.1e) loads very well and my Gui it triggers the onset of the 4th axis.
See attached images.
I will try at first hand controls and a program . Unfortunately I have no 3D view of the 4th axis for now.
I'll keep you informed.

[fcapuano]

Hi @LETARTARE where we can download your grbl controller GCV ?

[LETARTARE]

@kekko986
For now, GCV is not fully completed. It lacks the visualization of the 4th axis.
In addition you need a Grbl-4axes, and I'm not finished its development.
I am actively working on these projects that can not be separated.
Good night.

[109JB]

@dguerizec
I loaded up your most recent 4th axis fork of Grbl 1.1e and it seems to work well, but I do see one puzzling thing. First, I am just using a serial terminal to do this but I think I found an issue. I have echoes turned on and will post the entire thing at the end. I am using inch units in the example, but it does the same for mm as well.

What I found is that the A axis doesn't reach the same position as the X, Y or Z axes even though all of the stepper settings are identical. The steps/mm, accel, max rate, etc are all the defaults which have all axes configured the same. What I did in the example below is as as follows:

1. Issue G20 to place in inch units ($13=1 for inches already set
2. issue $$ to show EEPROM settings
3. Issue ? to get current position report (all axes start at 0 from a hard reset)
4. Issue G90G0X5Y5Z5A5 to move all axes 5 units positive
5. Wait a bit for motion to stop (I had an LED on the A-axis step pin)
6. Issue ? to get current position report

What I found is that the X, Y, and Z axes all report a final position of 5.0000, but the A axis reports 4.9998. I realize that this is only 0.0002, and it is not uncommon to see a small difference between the commanded position and the actual position due to step resolution. If the stepper settings were different I would probably have discounted the discrepency to step resolution, but since all axes have the same step settings they should all stop at the same position.

I don't understand the inner workings of Grbl all that much, and there may be a simple answer. What are your thoughts?

Here is the serial terminal output:

Grbl 1.1e ['$' for help]
[echo: G20]
ok
[echo: $$]
$0=10
$1=25
$2=0
$3=0
$4=0
$5=0
$6=0
$10=1
$11=0.010
$12=0.002
$13=1
$20=0
$21=0
$22=0
$23=0
$24=25.000
$25=500.000
$26=250
$27=1.000
$30=1000
$31=0
$32=0
$100=250.000
$101=250.000
$102=250.000
$103=250.000
$110=500.000
$111=500.000
$112=500.000
$113=500.000
$120=10.000
$121=10.000
$122=10.000
$123=10.000
$130=200.000
$131=200.000
$132=200.000
$133=200.000
ok
<Idle|MPos:0.0000,0.0000,0.0000,0.0000|FS:0.0,0|WCO:0.0000,0.0000,0.0000,0.0000>
[echo: ]
ok
[echo: G90G0X5Y5Z5A5]
ok
<Idle|MPos:5.0000,5.0000,5.0000,4.9998|FS:0.0,0|Ov:100,100,100>
[echo: ]
ok

[109JB]

Does anyone have any idea why the issue in my previous post is happening? There is a little more info below.

I decided to write a little test code to examine it further. What the test program does is send a random A-axis position command using a G0 command. The commanded position is the target. It then waits until Grbl reports Idle and then compares the actual position to the target and gets the difference. It repeats this any number of times. In the results below I did a 30 test run.

Note: I changed the Grbl setting to $103=1000 steps/mm and used G21 and $13=0. So each 0.001mm equals 1 step. As you can see below the A axis always stops short of the target. In these 30 tests it was always 0.004mm from the commanded target position, or 4 steps. However, more testing showed that it could be anywhere between 4 steps off in one direction to 1 step off in the other. This was determined using a run of 2000 target positions.

Also, since an A-axis in machining terms is generally a rotation axis, it should be steps/deg or something like that and changing $13 should not change the A-axis output. This isn't a big deal to me as I have already comensated for this in my newest GUI.

Here is tat test run I mentioned
#, target, actual, difference
1, 14.111, 14.107, 0.004
2, 10.668, 10.664, 0.004
3, 11.59, 11.586, 0.004
4, 5.791, 5.787, 0.004
5, 6.039, 6.035, 0.004
6, 15.495, 15.491, 0.004
7, 0.28, 0.276, 0.004
8, 15.214, 15.21, 0.004
9, 16.29, 16.286, 0.004
10, 14.181, 14.177, 0.004
11, 0.907, 0.903, 0.004
12, 8.281, 8.277, 0.004
13, 17.252, 17.248, 0.004
14, 15.81, 15.806, 0.004
15, 7.471, 7.467, 0.004
16, 19.239, 19.235, 0.004
17, 17.429, 17.425, 0.004
18, 1.125, 1.121, 0.004
19, 18.991, 18.987, 0.004
20, 7.28, 7.276, 0.004
21, 10.497, 10.493, 0.004
22, 15.342, 15.338, 0.004
23, 1.07, 1.066, 0.004
24, 11.849, 11.845, 0.004
25, 9.374, 9.37, 0.004
26, 5.963, 5.959, 0.004
27, 12.454, 12.45, 0.004
28, 12.956, 12.952, 0.004
29, 5.276, 5.272, 0.004
30, 5.587, 5.583, 0.004

[dguerizec]

Hello @109JB

Indeed this is weird.
I'll check my setup sometimes this week to see if I get the same results and investigate.

[dguerizec]

@109JB
You are absolutely right. I tried a simple test, with $103=100 then g0a10 and it goes to 10.37.
I then enter g0a0 and it goes to 0.37 :/
Entering g0a-0.37 goes back to 0.00 so there is something wrong.

[109JB]

@dguerizec

I wish I could help you diagnose this but unfortunately I am not a good enough at C programming to be of any help. I do ok with Visual Basic, but have no C skills.

I did notice something in one of my test runs that I want to check further. It appears that the deviation between the programmed position and the actual position may be converging to 0 over many A axis movements. I saw in my 2000 move test run that the deviation started at 4 steps off, went to 3 then 2 then 0 then -1 then back to 0. I am going to set my test program to run about 100 k moves to see if this was just a fluke or if it actually converges an stays there. I will report back the results. I also want to do this to see what the a max deviation is. If it is 4 steps max, I could still use it in my application since 4 microsteps would only be a deviation of 0.01 degrees on my rotary table.

[109JB]

@dguerizec I did some more testing and it appear that the deviation between commanded position and the actual position does indeed converge for some reason to zero. When it first started the deviation was 5 steps, then went to 4 steps after just 3 commanded moves, then went to 3 steps deviation after 46 commanded moves, then to -1 steps deviation after 345 commanded moves, and then to 0 steps deviation after 1441 commanded moves. It remained at 0 deviation for the remainder of the 30,000 commanded moves.

If I start another run without resetting the arduino it starts and stays at 0 steps deviation. If I reset the arduino the deviation again is present.

Puzzling, as I would not expect any kind of convergence such as this.

[dguerizec]

@109JB I'm not sure I see any convergence, but I haven't done thousands of tests.

I checked the patches, and looked at the code for something more or less obvious, but I found nothing.
All the code added for the A axis is the same as for X, Y and Z (and they behave correctly).

I've added the real steps to the status line, and I've seen a very curious behavior, despicted in the following session:

Grbl 1.1e ['$' for help]
[MSG:'$H'|'$X' to unlock]
[MSG:Caution: Unlocked]
STATUS: <Idle|MPos:0.000,0.000,0.000,0.000|Bf:35,255|FS:0,0|WCO:0.000,0.000,0.000,0.000|STEPS:0,0,0,0>
g0a0
STATUS: <Idle|MPos:0.000,0.000,0.000,0.000|Bf:35,255|FS:0,0|STEPS:0,0,0,0>
a1
STATUS: <Idle|MPos:0.000,0.000,0.000,0.990|Bf:35,255|FS:0,0|STEPS:0,0,0,99>
a0
STATUS: <Idle|MPos:0.000,0.000,0.000,-0.010|Bf:35,255|FS:0,0|STEPS:0,0,0,-1>
a0.01
STATUS: <Idle|MPos:0.000,0.000,0.000,0.070|Bf:35,255|FS:0,0|Ov:100,100,100|STEPS:0,0,0,7>
a0
STATUS: <Idle|MPos:0.000,0.000,0.000,-0.010|Bf:35,255|FS:0,0|STEPS:0,0,0,-1>
a1
STATUS: <Idle|MPos:0.000,0.000,0.000,0.990|Bf:35,255|FS:0,0|WCO:0.000,0.000,0.000,0.000|STEPS:0,0,0,99>
a0.01
STATUS: <Idle|MPos:0.000,0.000,0.000,0.000|Bf:35,255|FS:0,0|STEPS:0,0,0,0>
a0
STATUS: <Idle|MPos:0.000,0.000,0.000,-0.080|Bf:35,255|FS:0,0|STEPS:0,0,0,-8>

What puzzles me is these +8 steps jump between A0 and A0.01, and -8 beetween A0.01 and A0.
Are you sure to have only 4 steps off ?

@chamnit, I guess you know grbl better that anyone else, any chance you would know what's happening here ?
I've looked around calls to ceil() and floor(), but the algorithm is pretty huge to grasp in a few hours :/

[dguerizec]

@109JB If you want to check the step reporting, I've pushed a patch on https://github.com/dguerizec/grbl-Mega-4axis/tree/4axis-debug

[dguerizec]

@109JB I finally found the bug, it was a missing initialization of a step counter on the A axis:

dguerizec@0046fa9

Can you try and confirm it works for you ?