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
5 or more Axis in UGS #1068
Comments
What are you using for firmware? I've been thinking about how to add ABC axes to the visualizer recently, but GRBL doesn't support that yet as far as I know. |
I own a GRBL fork which in conjunction with the RAMPS 1.4 commands 5 axes
Em 27 de jun de 2018 1:11 PM, "Will Winder" <notifications@github.com>
escreveu:
… What are you using for firmware?
I've been thinking about how to add ABC axes to the visualizer recently,
but GRBL doesn't support that yet as far as I know.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1068 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/Akxdu7MTUhZXWLemA74-DgTTnx61y7cRks5uA66wgaJpZM4U5sUj>
.
|
Thanks, I started looking into this about a week ago and have made some progress already. The ABC axes are now being parsed and made available to the different UGS widgets. I'm starting with the visualizer, this morning I started working on the XYZ + ABC location to an XYZ plot. There seems to be a problem with my trigonometry somewhere, but I'm pleased to have something vaguely resembling the part. If anyone wants to double check my math, this is what I made this morning: private static LineSegment toCartesian(LineSegment p) {
Position start = new Position(p.getStart().x, p.getStart().y, p.getStart().z);
Position end = new Position(p.getEnd().x, p.getEnd().y, p.getEnd().z);
if (p.isRotation()) {
double startA = p.getStart().a;
double startB = p.getStart().b;
double startC = p.getStart().c;
double endA = p.getEnd().a;
double endB = p.getEnd().b;
double endC = p.getEnd().c;
// X-Axis rotation
// x1 = x0
// y1 = y0cos(u) − z0sin(u)
// z1 = y0sin(u) + z0cos(u)
if (startA != 0) {
double sinA = Math.sin(Math.toRadians(startA));
double cosA = Math.cos(Math.toRadians(startA));
start.y = start.y * cosA - start.z * sinA;
start.z = start.y * sinA + start.z * cosA;
}
if (endA != 0) {
double sinA = Math.sin(Math.toRadians(endA));
double cosA = Math.cos(Math.toRadians(endA));
end.y = end.y * cosA - end.z * sinA;
end.z = end.y * sinA + end.z * cosA;
}
// Y-Axis rotation
// x2 = x1cos(v) + z1sin(v)
// y2 = y1
// z2 = − x1sin(v) + z1cos(v)
if (startB != 0) {
double sinB = Math.sin(Math.toRadians(startB));
double cosB = Math.cos(Math.toRadians(startB));
start.x = start.x * cosB + start.z * sinB;
start.z = -1 * start.x * sinB + start.z * cosB;
}
if (endB != 0) {
double sinB = Math.sin(Math.toRadians(endB));
double cosB = Math.cos(Math.toRadians(endB));
end.x = end.x * cosB + end.z * sinB;
end.z = -1 * end.x * sinB + end.z * cosB;
}
// Z-Axis rotation
// x3 = x2cos(w) − y2sin(w)
// y3 = x2sin(w) + y2cos(w)
// z3 = z2
if (startC != 0) {
double sinC = Math.sin(Math.toRadians(startC));
double cosC = Math.cos(Math.toRadians(startC));
start.x = start.x * cosC - start.y * sinC;
start.y = start.x * sinC + start.y * cosC;
}
if (endC != 0) {
double sinC = Math.sin(Math.toRadians(endC));
double cosC = Math.cos(Math.toRadians(endC));
end.x = end.x * cosC - end.y * sinC;
end.y = end.x * sinC + end.y * cosC;
}
}
LineSegment next = new LineSegment(start, end, p.getLineNumber());
next.setIsArc(p.isArc());
next.setIsFastTraverse(p.isFastTraverse());
next.setIsRotation(p.isFastTraverse());
next.setIsZMovement(p.isZMovement());
next.setSpeed(p.getSpeed());
next.setToolHead(p.getToolhead());
return next;
} |
I took a quick look at your math, from what I saw was to be right, I'll stop to analyze it calmly and try to come up with a solution |
@ThiagoAlencar22 do you have a 5-axis gcode file that I could test with? I think the code I have should work but I don't have a good way of checking. |
This is exciting. I might be able to create a 5 axis gcode file, but it would take a few days. |
Hey, good morning. This is very exciting. I started create a gcode file but it would take a few days too because I'm using the EdgeCam but I never had any contact with this software before. |
One question. If I load one Gcode for 5 axis in the normal program with the GRBL that I sent up. Will it run ? |
@ThiagoAlencar22 yes, it should stream just fine. For UGS >3 Axis support means updating widgets like the DRO, Visualizer, Jog Controler, etc, to display be aware of rotation axes. |
@winder I just got a Gcode file from my friend. I will post and put his link here |
I just want to thank you guys for addressing this. In the beginning, it was all about XYZ, but axis;' have really developed into individual motor control. To move to the next level, we need to be able to move each motor separately with no regard for axis. The human hand has about 17 'axis'. To be able to make really awesome robotics, we need unlimited axis, and move to "how many steppers are you running?" mode. I currently have a 5 motor robotic arm that is just sitting here hoping that programming comes along to a point where I can use G-code to move all of them. Thanks again! |
Just a comment. Probably most hobbyists can get to 4-Axis by the addition of a rotary table, typically mounted perpendicular to the Y table. The MaxNC 4-axis machine is one example. In addition to the above mentioned GRBL implementation, there is also GRBLQ (quatro) which is for the Mega 2560 boards, more pins. I've used this and works. |
FourAxisSurface_finishPass.txt |
Excellent. Eyeballing the FourAxisSurface_finishPass.txt file now quickly, it all looks good. No errors or other weirdness accidentally left in there. 😁 |
Thanks for the files. Just gave them a try with the ABC branch, and the code I have so far couldn't parse them. So they will be extremely helpful for improving the parser when I get back to this. |
So, does 4(5) axis work now? And how can I get it? |
Any chance of a brief summary of where you guys are on this at this time. I would like to implement a RAMPS 1.6 / Mega build so I can run a rotary axis without having to unplug x or y axis. What I have seen in this post looks great and would love to give it a try. |
Has there been any further progress in adding more axes to UGS? I have a Sherline Mill with a rotary table (axis A), and I'd give my right arm to see UGS with 4th asix capability. I tried many other open source g-code senders lately, and all except UGS have major shortcomings for my application. I imagine the visualizer is the most difficult part to write. I would be happy to have 4th axis control without the visualizer. I would only need 4 axis jogging, and 4 axis display readout. But thanks for UGS as it is, it is a great program. |
@TonyZLR Sounds like you just need the buttons on the display for the A axis, and corresponding readout of it's position? |
Hi @TonyZLR, the visualizer should work if you use the latest nightly build and you should be able to send that program to the controller. There has been some work getting the DRO and jog controller to support additional axises in Wills (yet to be merged) #1540 but currently only works with GrblHAL. Once that is in place it should be pretty easy to add the same functionality to other controllers. What type of controller are you using? |
Hi @breiler, thanks for your reply. I am currently trying to setup https://github.com/fra589/grbl-Mega-5X, which is a 5 axis version of grbl. I hadn't heard of GrblHAL until you mentioned it. I will take a look at GrblHAL. I live in the US, and we use that inferior, crappy Imperial system (LOL), and I've noticed that the majority of Gcode senders only support metric. This is why I'm heavily leaning toward UGS, which supports inches. Anyway, do you happen to know if Wills is actively being developed, and approximately when something stable will be available? Thanks again. |
@justinclift yes, that would work for me. |
@TonyZLR yes, I'm still trying to wrap up this PR hopefully in the next week the DRO will support ABC. To make things a little more confusing, I'm actually targeting Grbl_ESP32 not GrblHAL. As @breiler mentioned it should be much easier to support ABC on other controllers once we have the first one working. The nightly version of UGS currently supports keybindings for the ABC jog operations, so you could try starting with that. Proper buttons in the Jog Controller is the next step. |
@winder, I would actually rather use an ESP32 module instead of an Arduino Mega, which I'm playing with now. So I look forward to your code updates. |
i understand and yet i dont understand.......i am a cnc machinist, just starting on the hobby side, who wishes he understood the code you all are talking about.........i so would like to help out.......... the best help i have, til i learn enough to contribute is this comment : ...........you all are awesome and inspiring...thank you for your great work!!!! |
Very interesting thread. I have been using bCNC and have been seeking a multi-axis G-code sender... One question from a UGS newbie - can UGS be setup for lathe diameter and radius modes? @winder how much closer are you to releasing the multi-axis UGS? |
Hi @rajivtctech, we have made a lot of progress since opening this issue but there is still a ways to go before we support any advanced features. I googled diameter/radius modes and it looks like that would be something the CNC controller would need to support - and currently outside the scope of what we usually try to support in UGS. I could be mistaken, maybe you could describe what "setup for lathe diameter and radius modes" would mean for UGS? The main pieces added so far: The visualizer has had its first round of updates to support displaying gcode files with ABC axis motions. There are still bugs, please report any that you see. #1231 There are options for jogging the ABC axis in the keybindings menu, they haven't made it to the UI yet. #1515 The DRO has some support for displaying ABC axes, specifically with grbl_esp32. #1540 |
Thanks for the response. I'll write a detailed feedback tomorrow... 🙂
RT
…On Mon, 22 Mar, 2021, 18:17 Will Winder, ***@***.***> wrote:
Hi Rajiv, we have made a lot of progress since opening this issue but
there is still a ways to go before we support any advanced features. I
googled diameter/radius modes and it looks like that would be something the
CNC controller would need to support - and currently outside the scope of
what we usually try to support in UGS. I could be mistaken, maybe you could
describe what "setup for lathe diameter and radius modes" would mean for
UGS?
The main pieces added so far:
The visualizer has had its first round of updates to support displaying
gcode files with ABC axis motions. There are still bugs, please report any
that you see. #1231
<#1231>
There are options for jogging the ABC axis in the keybindings menu, they
haven't made it to the UI yet. #1515
<#1515>
The DRO has some support for displaying ABC axes, specifically with
grbl_esp32. #1540
<#1540>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1068 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AG3ML3ULZCVSCBAKUI47HPLTE434TANCNFSM4FHGYURQ>
.
|
Hello...
Sorry for the late response.
In lathe mode, there are two axes - the long axis, with the tool moving
toward the chuck, is the Z-axis, and the cross-slide is the X-axis.
Lathe operation has a radius and a diameter mode. Most people program in
the diameter mode. GRBL does not have any code that can differentiate
between diameter and radius mode. So it is left to the Gcode sender to
implement radius and dia modes.
Essentially, the problem is with the diameter mode. To realize it, jogging
and gcode motion execution has to be at HALF the intended diameter. For
example, if I wish to move X from a dia of 20mm to a dia of 10 mm, my
X-axis will move only 5mm, not 10mm.
So now, to implement a lathe controller, the following has to be done:
1. For local (non Gcode) control of the machine, there has to be a "Lathe
Mode" which displays only an X-axis (UP/DOWN arrows) and a Z-axis
(LEFT/RIGHT arrows). Or maybe an executable called ugsplatform_lathe.
2. There has to be an explicit selection for Radius and Diameter Mode, so
that UGS knows what MDI command to send to GRBL during a jog.
3. Now here is where it gets complex... examine the code below:
G1 X20 Z0 F100 (WE HAVE SET THE TOOL AT SAY THE OUTER EDGE OF THE JOB)
G1 X18 (FEED CROSS SLIDE TO DIA 18. HERE X HAS TO FEED TO 9MM NOT 18MM)
G1 Z-10 (FEED Z TO -10. HERE Z HAS TO MOVE 10MM)
So UGS will have to examine the gcode it has to send to GRBL, and send GRBL
the exact measure for Z but HALF the measure for X, if DIA mode is
selected, because GRBL is not aware of lathe diameter mode... In case of
radius mode, no complexity - you just send whatever gcode comes in. So in
this example, UGS reads X18, but sends X9, when diameter mode is selected.
Do consider, for every 3/4-axis machine, there are at least 20 lathes out
there...
Given that lathe spindle feedback has been implemented on a fork of GRBL,
if you implement lathe mode, UGS and GRBL will immediately be in
competition with Mach3, for a very large part of lathe functionality...
I think a setup that configures 3-5 axis milling style machines as well as
a 2-axis lathe with spindle feedback, might be an idea you might like to
examine...
Please write back if you need more of this conversation...
Congratulations on a wonderful product and best wishes for the future...
Have a nice day.
Regards,
Rajiv
On Thu, 25 Mar 2021 at 02:24, CTO / T&C Technology (India) Pvt. Ltd. <
***@***.***> wrote:
… Thanks for the response. I'll write a detailed feedback tomorrow... 🙂
RT
On Mon, 22 Mar, 2021, 18:17 Will Winder, ***@***.***> wrote:
> Hi Rajiv, we have made a lot of progress since opening this issue but
> there is still a ways to go before we support any advanced features. I
> googled diameter/radius modes and it looks like that would be something the
> CNC controller would need to support - and currently outside the scope of
> what we usually try to support in UGS. I could be mistaken, maybe you could
> describe what "setup for lathe diameter and radius modes" would mean for
> UGS?
>
> The main pieces added so far:
>
> The visualizer has had its first round of updates to support displaying
> gcode files with ABC axis motions. There are still bugs, please report any
> that you see. #1231
> <#1231>
>
> There are options for jogging the ABC axis in the keybindings menu, they
> haven't made it to the UI yet. #1515
> <#1515>
>
> The DRO has some support for displaying ABC axes, specifically with
> grbl_esp32. #1540
> <#1540>
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#1068 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AG3ML3ULZCVSCBAKUI47HPLTE434TANCNFSM4FHGYURQ>
> .
>
--
Rajiv Tyagi
CTO
T&C Technology (India) Pvt. Ltd.
17 Mission Compound,
Meerut, UP 250 001
INDIA
+91 (121)-405-8357 (Office)
+91 98373 30108 (Mobile)
|
This should now be possible with GRBL-based controllers reporting extra axes in the status report, ex: Controllers that I have tried:
If you find anything weird, please let us know. It is currently available in the nightly build and will be available in version 2.0.12. |
Hi, I've been thinking of adding to UGS the alternative of being able to work with more than 3 axes. Add auxiliary axes. My machine has 5 axes and I do not have software to run it. I wonder if that would be possible. Thanks for listening.
The text was updated successfully, but these errors were encountered: