-
Notifications
You must be signed in to change notification settings - Fork 230
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
4th axis ? #15
Comments
Hello @LETARTARE You can check this PR for 4th axis, and if you can test it, I'd be happy to know the results :) |
Thanks @dguerizec for doing that. I've been meaning to update my fork, but just never got around to it. |
Hello @dguerizec |
Hi @LETARTARE where we can download your grbl controller GCV ? |
@kekko986 |
@dguerizec 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:
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] |
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 |
Hello @109JB Indeed this is weird. |
@109JB |
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. |
@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. |
@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. I've added the real steps to the status line, and I've seen a very curious behavior, despicted in the following session:
What puzzles me is these +8 steps jump between A0 and A0.01, and -8 beetween A0.01 and A0. @chamnit, I guess you know grbl better that anyone else, any chance you would know what's happening here ? |
@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 |
@109JB I finally found the bug, it was a missing initialization of a step counter on the A axis: Can you try and confirm it works for you ? |
Thank you. I am travelling for work right now, but will be able to test it this evening. I will report back the results. BTW, Thank you for going to the work of creating this fork and making it available. |
@dguerizec and @109JB And I'll chime in with a thank you to you both. I'm adapting this code for Mega + RAMPS (currently testing). I can vouch that the fix worked for me (although I've got other issues that I've created for myself). David |
@dguerizec |
I just got done running the new 4th axis version through my testing program and I can report that there were no deviations. I ran several 1000 command runs, resetting the arduino between each run, and then I ran it using my test program set to 30000 commanded moves and got no errors. Looks like it is fixed. Thanks @dguerizec |
Thanks to @dguerizec which allowed me to remove this error, I can present you the update of an old 4-axis version of Grbl which is here GrblQ . |
@dguerizec and @LETARTARE A question for you guys. I have been playing with @dguerizec version and it works great. I have only been experimenting without it hooked to a machine yet. This brings me to a few questions.
Thank you guys for your hard work. |
Nice job you two guys! I will flash Mega asap! |
@109JB
you can use A or B or C : see the wiki, I started some explanation. 2- I would answer you later... @kekko986 |
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' ?
The text was updated successfully, but these errors were encountered: