Closed ThiagoAlencar22 closed 2 years ago
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 https://github.com/winder/Universal-G-Code-Sender/issues/1068#issuecomment-400734784, 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
Found the problem!
start.y in the second line was modified... oops. That's what I get for trying to knock out a quick prototype:
start.y = start.y * cosA - start.z * sinA;
start.z = start.y * sinA + start.z * cosA;
I'm still missing a minus sign somewhere, the text is backwards. (edit: turns out the text isn't backwards, all of the lines are drawn over the tool so it just looks like the letters are on the far side!)
@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 ? Even without showing in the vizualizer ?
@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!
@ThiagoAlencar22 Looking through that example 5-axis G-Code file, there are definitely some problems in it that need fixing.
*
character doesn't seem to be widely regarded as a valid comment character. Replacing those with a semi-colon would probably fix it. :smile:They'll probably need to be looked at. :wink:
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. Many CNC generation programs (that are affordable for hobbyist) just substitute an axis for the rotary axis (A - primary). An example where Y is mostly Zero except for some rounding is attached. It makes a small drive shaft for an HO train to couple motor in coal car to engine. Rotary table is mounted to the left on the table. I'll see about sending something that does all 4-axis later. I've used Bobcad (sometimes can get a good deal as hobbyist) with a GRBL g-code interpreter that I extended to 4-axis. Certainly having more than 4-axis would be a welcome addition to your program. Thanks for sharing this fine program. TrainDriveShaft_GRBL.txt
FourAxisSurface_finishPass.txt Here's g-code for a finishing pass on a convoluted surface. There is movement in x,y,z,a where the ball nose mill is vertical, and the table tips in A to keep the cutter perpendicular to the surface with shifts in x,y,z to make the cuts. UGS does a good job of showing the surface, without the tilting during running of the program of course.
Excellent. Eyeballing the FourAxisSurface_finishPass.txt file now quickly, it all looks good. No errors or other weirdness accidentally left in there. :grin:
Here's what the drive shaft should look like with the tool path, believe it was 3 passes.
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. Thanks
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?
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.
Sounds like you just need the buttons on the display for the A axis, and corresponding readout of it's position?
@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.
To make things a little more confusing, I'm actually targeting Grbl_ESP32 not GrblHAL.
@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. https://github.com/winder/Universal-G-Code-Sender/pull/1231
There are options for jogging the ABC axis in the keybindings menu, they haven't made it to the UI yet. https://github.com/winder/Universal-G-Code-Sender/pull/1515
The DRO has some support for displaying ABC axes, specifically with grbl_esp32. https://github.com/winder/Universal-G-Code-Sender/pull/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 https://github.com/winder/Universal-G-Code-Sender/pull/1231
There are options for jogging the ABC axis in the keybindings menu, they haven't made it to the UI yet. #1515 https://github.com/winder/Universal-G-Code-Sender/pull/1515
The DRO has some support for displaying ABC axes, specifically with grbl_esp32. #1540 https://github.com/winder/Universal-G-Code-Sender/pull/1540
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/winder/Universal-G-Code-Sender/issues/1068#issuecomment-804033913, 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:
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 https://github.com/winder/Universal-G-Code-Sender/pull/1231
There are options for jogging the ABC axis in the keybindings menu, they haven't made it to the UI yet. #1515 https://github.com/winder/Universal-G-Code-Sender/pull/1515
The DRO has some support for displaying ABC axes, specifically with grbl_esp32. #1540 https://github.com/winder/Universal-G-Code-Sender/pull/1540
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/winder/Universal-G-Code-Sender/issues/1068#issuecomment-804033913, 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: <Idle|MPos:1.000,2.000,3.000,4.000,5.000,6.0000|FS:0,0|Pn:XYZ>
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.