4th axis engraving ??

Post anything you want to discuss with others about the software.

Re: 4th axis engraving ??

Postby Gary Campbell » Fri Mar 16, 2018 10:00 pm

Balazs...
I agree that although more than viable, G93 practical uses are limited in todays world.

OK, of course I defer to your greater knowledge where my scenarios 1 and 2 do not apply. Please provide the line of code with either feedrate or execution time for the alternative, as I asked. An alternative may be more than adequate, but I simply am not aware of what it would be.

Your explanation leaves me wondering if UCCNC is truly "unitless". If this were the case, wouldn't the XY axes interrelate to the rotary axis in the way that the Z might to a 50 or 100 times longer Y or X that operates at a much higher feedrate? Z can be 6" travel with 100 u/min max, Y can be 240" travel with 1000 u/min and B can be 1,000,000 units travel with a 144,000 u/min feedrate. Can they all be given a G1 move and arrive at the same time based on the XY feedrates? If not, you are seriously behind the development of other controls.
Gary Campbell
CNC Technology & Training
Control & ATC Retrofits
gcnc411(at)gmail.com
https://www.youtube.com/user/Islaww1/videos
Gary Campbell
 
Posts: 50
Joined: Thu Nov 24, 2016 8:25 pm

Re: 4th axis engraving ??

Postby cncdrive » Fri Mar 16, 2018 10:13 pm

The path is not 720 units long, but the total vector lenght on the YZB axes, so execution time will be not 6 minutes, but more than that even if we neglect the acceleration and the decceleration path and assuming an infinate acceleration and decceleration then still it will be not 6 minutes, because the path is not 720 long.
And the axes ofcourse will finish the movement the same time, because G1 is linear interpolation.

I've made a drawing to let you see that the length of the path is not 1 when e.g. a G1 X1 B1 is coded, but the length of the path is 1.414.
And so programming a F1 will not finish that path in 1 minutes, but in 1.414 minutes, because the programmed feedrate is always the feedrate on the path and so going through a 1.414 units long path with 1 units/min feedrate will take 1.414 minutes and not 1 minute.
The same is when you code more axes, e.g. 6 axes. The movement vector is then on a 6 dimensions space and is not a single dimension line and so the length of the path in the space is not 720 when you code B to move from 0 to 720 and when you code other axes to move the same time creating a multidimensions path. So, the execution will not be 6 minutes but always more than that, because the path will be always longer as long as you coding other axes also.
I'm sure there are better ways to explain this, but I don't know how.
Attachments
2dimsmovement.png
2dimsmovement.png (3.92 KiB) Viewed 544 times
cncdrive
Site Admin
 
Posts: 1862
Joined: Tue Aug 12, 2014 11:17 pm

Re: 4th axis engraving ??

Postby cncdrive » Fri Mar 16, 2018 10:29 pm

Gary,

I don't really understand what you want to say or ask.
But G1 is linear interpolation. When you program a feedrate and a linear interpolation move then all axes will pick a speed to move the axes in the N dimensions space (where N is the number of axes programmed to move) on the summary vector in the N dimensions space with the programmed feedrate. So, ofcourse X will operate on a higher speed than Y if the X is more far from the endpoint than how far Y is from the Y end coordinate. If it was not like that then it was not linear interpolation.
The axes are syncronised together to do their own full distance of travel and to finish the same time with making the tool to travel with the F feedrate along the programmed line in the N dimensions space. This is how linear interpolation works in G94 mode with any CNC controls.
cncdrive
Site Admin
 
Posts: 1862
Joined: Tue Aug 12, 2014 11:17 pm

Re: 4th axis engraving ??

Postby cncdrive » Fri Mar 16, 2018 10:40 pm

Your explanation leaves me wondering if UCCNC is truly "unitless". If this were the case, wouldn't the XY axes interrelate to the rotary axis in the way that the Z might to a 50 or 100 times longer Y or X that operates at a much higher feedrate? Z can be 6" travel with 100 u/min max, Y can be 240" travel with 1000 u/min and B can be 1,000,000 units travel with a 144,000 u/min feedrate. Can they all be given a G1 move and arrive at the same time based on the XY feedrates? If not, you are seriously behind the development of other controls.


Sorry, but I don't really understand this. Please give me an example G1 code which would do that with any CNC controls?
Based on the RS274 standards a linear interpolation feedrate is always understood on the programmed path and not on the XY plane only.
And why the XY plane, why not the XZ or why not the YZ or why not the XYZ etc. I mean what defines which axes are the path and which axes are not the path for the path feedrate?
How would you program that in a CNC software? There is nothing for that g-code wise.
And again there is no specific rotary axes in UCCNC, but I have described it in details a few posts back.
cncdrive
Site Admin
 
Posts: 1862
Joined: Tue Aug 12, 2014 11:17 pm

Re: 4th axis engraving ??

Postby Gary Campbell » Sat Mar 17, 2018 2:22 pm

Balazs...
I will try to explain, best I can. Even tho it may be an unrewarded and near impossible task, as a Vectric beta tester I am trying to find a way to make wrapped rotary axis work appear simpler to the user. On as many controls as possible. Getting a fairly close feedrate into a wrapped file would/could go a long way. Please understand that the controllers I use for my systems to not suffer from any feedrate issues. Since I do use UCCNC on some lower cost offerings, I am looking to be able to offer rotary axes to these customers too.

First, you do not have to explain to me the path length. And in this case you have actually made a mistake. With the Z position at a constant 1" position, the cylinder diameter would be 2", and each revolution of the cylinder would result in 6.28" of travel resulting in12.56 inches surface travel for the B, or unwrapped as X. With 12.56" travel for the X and 10" for the Y the actual path length is 16.06" and at 120 ipm and not accounting for acceleration would result in 8.03 seconds elapsed time. Sorry, I posted those others from a phone during an airport layover. The point I was trying to make was a number of seconds to execute versus an number of minutes. Where most users would expect the shorter execution time as it most closely replicates programmed feedrates.

You stated that UCCNC would not execute my line of code as per either of my scenarios 1) or 2). Please provide an example of the actual feedrates or execution time for that alternative as I asked a number of posts up. That may be all that is needed for UCCNC users to adapt to rotary. This opens the door for possibly hundreds of frustrated Mach3 users to migrate to UCCNC. One good one in Australia, for sure.

When you say: "Sorry, but I don't really understand this. Please give me an example G1 code which would do that with any CNC controls?"
That example would be, as I offered above: G1 X0 Y10 Z1 B720 F120 from existing position X0 Y0 Z1 B0

And here is a video of it being executed: https://youtu.be/5SH4vtwLb4s

You will note that give or take, the motion starts at 15.53 seconds into the video and ends at 20.53 with a resulting execution time of 5.14 seconds. Allowing for accel/decel this is my exact scenario #2 from above. This results in a feedrate of 192.72 ipm. Which was acceptable in this case as my desired feedrate is 200-240 ipm, I simply reduced the lower of the 2 and reduced it by 1/3 and used 120 ipm. This is similar to how G93 would work, except that the inverse time is not calulated, it simply uses the time of execution for the XYZ and calcs an appropriate feedrate for the B. A kludge if you will, but in reality a very usefull one, if you think about it. Of course there is a formula to allow a programmer to acheive the "perfect" feedrate if needed that would involve vector length ratios, but in most cases a 1/3 reduction (or division by ~sqrt of 2) gets most of these rotary files humming along just fine.

This example, in case you didnt notice was using Centroid control. Along with a parameter setting that will allow you to "sync or slave" the rotary feedrate to the linear, there is another that keeps that feedrate modal in the event there is a rotary only command.

Other controls (ShopBot or WinCNC) uswe a different approach. Their feedrates are modal by axis. Feedrates are set in the header. Rotary Wrapped example: F 120 XY, F120Z and F (115 * {XY feed} / {wrapped_dia) B in the header. Those feeds are adhered to and interpolated as to maintain the fastest feedrate that does not exceed any of those settings. They use a parameter (adjustable) called "vmatch" or velocity matching that is enabled when a rotary axis requires it, which is most of the time for these small rotary axis equipped routers. Obviously different than would be required on a mill with a rotary table or trunion.

Hope this helps. Since I do not have a machine here running on UCCNC, and wont for a few weeks, please provide the toolpath times or actual executed feeds for your example that is contrary to the scenarios I posted above.
Gary Campbell
CNC Technology & Training
Control & ATC Retrofits
gcnc411(at)gmail.com
https://www.youtube.com/user/Islaww1/videos
Gary Campbell
 
Posts: 50
Joined: Thu Nov 24, 2016 8:25 pm

Re: 4th axis engraving ??

Postby ger21 » Sat Mar 17, 2018 3:04 pm

Not sure what the development schedule is for UCCNC, but perhaps it's a good time to implement rotary axis support? :)
Gerry
UCCNC 2017 Screenset - http://www.thecncwoodworker.com/2017.html
ger21
 
Posts: 960
Joined: Sat Sep 03, 2016 2:17 am

Re: 4th axis engraving ??

Postby cncdrive » Sat Mar 17, 2018 5:50 pm

Gary,

First, you do not have to explain to me the path length. And in this case you have actually made a mistake. With the Z position at a constant 1" position, the cylinder diameter would be 2", and each revolution of the cylinder would result in 6.28" of travel resulting in12.56 inches surface travel for the B, or unwrapped as X. With 12.56" travel for the X and 10" for the Y the actual path length is 16.06" and at 120 ipm and not accounting for acceleration would result in 8.03 seconds elapsed time. Sorry, I posted those others from a phone during an airport layover. The point I was trying to make was a number of seconds to execute versus an number of minutes. Where most users would expect the shorter execution time as it most closely replicates programmed feedrates.


Gary, first I did not explain the path lenght to you, but I have explained it to Terry when he asked why your example execution time is not 6 minutes.
Second, I was not talking about a cylinder nor anything about rotary axes, but linear interpolations when I explained that.
I understand your point you wanted to ask. The only little issue is that it seems that you did not understand my answer.
I also understand what you expect, I just said that linear interpolation works different from what you expect.
And now I understand from your current reply that there is an option in some software to exclude some axes from the linear interpolation's feedrate calculation and to use those axes then just to follow the path calculated on the feedrate of other axes and this option is available for so called "rotary axes". Basicly this was my only question which I did not understand or know.

I also know that WinCNC using different feedrate settings using a non-standard g-code syntax (I have learned this from you a few months ago from one of your posts), but that is not something which we want to follow, because it makes the software non-standard and incompatible with many CAM softwares, because their code syntax is unique and does not follow the RS274NGC standards and so if the CAM does not have a calculation method and a post processor for that software then it will not work properly with that software.
If and when we will implement rotary axes support then we will use a different approach for sure. The option to let "rotary" axes to just follow the linear interpolation's feedrate of the other linear axes is the approach which I like instead of the strange different feedrate per axis feature. :)
But currently there is no so called "rotary" axis support in the UCCNC as I explained you previously and so there is no such option either to exclude axes from the feedrate calculation, because for the software all axes are linear and so it can't distinguish between linear and rotary, because there is no rotary...

For the toolpath times I do not have the time at the moment to calculate it for your example, I'm off the grid now (that's why I could post a so bad drawing previously for my explanation), because we had a national holiday and a long weekend, so the only thing I have now is my cell phone with 4G internet... but I think it is enough to tell you that it will be not 5seconds and not exactly 6 minutes, but more than 6 minutes...I don't think it would be 6 minutes on any CNC controller in any scenarios except one, because if the controller do the calculation as linear interpolation using all axes as linear then the path is longer than 720 and if they excluding some axes from the linear interpolation then the lenght of the path depends on what axes are excluded. The only one scenario when the execution time would be 6 minutes is if only the B axis is considered a linear axis and only that plays role in the feedrate calculation and all the other axes you coded are all just following that in some way... ofcourse the accelerations and deccelerations are then still neglected.
cncdrive
Site Admin
 
Posts: 1862
Joined: Tue Aug 12, 2014 11:17 pm

Re: 4th axis engraving ??

Postby cncdrive » Sat Mar 17, 2018 5:59 pm

This opens the door for possibly hundreds of frustrated Mach3 users to migrate to UCCNC.


I don't think so, because as long as axes are all linear Mach3 would also not execute that code in exactly 6 minutes, but more than that. Mach3 is then doing the same what the UCCNC, there is no difference.
You just have to understand that all axes are considered in the linear interpolation (XYZABC) as a path element and so if you code multiple axes then the path is in a multidimension space and not along a line.
Again, I'm not talking about special cases like when you set the "rotary axis" option in Mach3, because then how it handles the axes feedrates may change depending on options, but those are not somethings which are implemented yet into the UCCNC, because as you might already noticed there is no "rotary axis" option in the UCCNC.
So, I don't think we confuse or frustrate anyboby, because there is no "rotary axis" option in the UCCNC, so anybody who takes a look at the software interface or the manual can see what exactly the software is capable of doing and will not expect rotary axis support when it is clearly non existent in the UCCNC interface nor in the manual.
cncdrive
Site Admin
 
Posts: 1862
Joined: Tue Aug 12, 2014 11:17 pm

Re: 4th axis engraving ??

Postby Gary Campbell » Sat Mar 17, 2018 7:57 pm

Balazs..
Understand that in many CNC machines there are "things that make stuff work". I was simply looking to see if UCCNC had a way to make this happen. Not looking to have the program changed nor call out you for something thats not there.

In fact the opposite is true. UCCNC is very similar to Mach, eerily so. Hopefully you dont follow the same path adding one off type stuff for this guy and that guy like Art did, until it got the best of him. Special features should never have priority over function. Make the program function to the best of your ability and let users use it, or not. If not, I am sure they same guys that had Mach wish lists will be here beating on you for the same things that they wanted Art to add.

We all know where that road leads. Neverending features and a million plugins and a core function that was buggy.

Rotary is an often wanted but seldom used features for a small percentage of the userbase. If I were you I wouldnt give it another thought.
Gary Campbell
CNC Technology & Training
Control & ATC Retrofits
gcnc411(at)gmail.com
https://www.youtube.com/user/Islaww1/videos
Gary Campbell
 
Posts: 50
Joined: Thu Nov 24, 2016 8:25 pm

Re: 4th axis engraving ??

Postby Vmax549 » Sat Mar 17, 2018 8:56 pm

NOW you know WHY I did the 4th wrapper for UCCNC :D ANY cam can output teh code and any UCCNC can run it. You just have to retrain teh USER a bit ;)

(;-)TP
Vmax549
 
Posts: 922
Joined: Sun Nov 22, 2015 3:25 am
Location: USA

PreviousNext

Return to General discussion about the UCCNC software

Who is online

Users browsing this forum: No registered users and 4 guests