4th axis engraving ??

[Gary Campbell]

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.

[ger21]

Not sure what the development schedule is for UCCNC, but perhaps it's a good time to implement rotary axis support?

[cncdrive]

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]

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.

[Gary Campbell]

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.

[cncdrive]

Gary,

Ofcourse we not adding stuff on first demands. I even had a bad affair on cnczone a long time ago because some guys demanded things and I said that we have a scheudle of it, but it is not on the top of our todo list and they did not like that answer. But that's OK, because we will not change our scheudles just because one or two guys start demanding to do something else.

How we add new things to the software is we have a todo/to be developed list. What we think is the most important gets to the top and the importance is lower and lower as we go to the bottom of the list.
When somebody gives us a good idea or advice what to develop or if we figure out something ourselves then we make a note of that and it may or may not go onto our list, depends on a later discussion.
Also when we end a development cycle we reconsider the order of items on the list, because things could change about the priority of things as the time goes.
Ofcourse we also take into account if a thing was asked by X people or 10*X people or 100*X people. The more people asks about something will likely move that thing up on our list and so then it will be developed earlier.
We also taking the complexness of the list items into account and if something is very complex and could easily influance other things if badly implemented then we likely move that lower on the list, because then the development of that item can delay the development of other smaller items if we make a mistake with the complex one and so we have to correct things in the next test releases after developing that.
Just think about the G41/G42, it was planned for years and finally it was developed, but afterwards still minor changes and additional codes were required and there are still a few things we want to change and add, so it was a similarly if not even more complex development than the rotary axis or the S-curve profiling. We have to be and are very careful when we decide and when we add these type of complicated new functions.

And ofcoure bug and problem fixes always go above of everything on our list, so when we receive bug reports we have to stop with what we actually develop and have to fix that bug and this is why we consider the complexnex of items on our todo list, because more complex items can possibly make more bugs which could delay us more in adding other things...

If we concretize and talking about the 4th axis feature or I would say features because as I have mentioned it is not only one boolean option, but requires many sub-options to work in enough scenarios to make it useful for most applications and most machines, then I can say that it is already on our list, but it is not yet decided if we want to develop it before or after we will extend the motion planner to support S-curves profiling.
Both things require complex changes and added codes and so we do not see yet what is the better to do first, but will further dig into it and will make a decision once we will get there, but a few items still to be done on our list before we reach that.

And our development is probably better than Art's because we are not a "one man army". I mean even the best programmer can make mistakes especially when working alone and even the best programmer can get a tunnel vision when doing something too long. I often see this on myself and I also see this sometimes on collegues. Sometimes I work on a thing for days and I can't figure out an issue and then I ask a collegue about his opinion and the issue is new to him, but he figures it out in minutes giving a fully new perspective for me. And the same can happen with other collegues too.
We working with a team and so we can correct eachother in the planning phase and in the coding phase. Our creed is the "more eyes see more".
And sometimes even guys on the forum (I could say friends by now I think) or even customers correct our ideas which is also great. We always think about and consider useful and proper reasonings which is not equal to that we are easy to be convinced, but we always listening and considering and we doing it as a company, as a team and not as a single person.

[cncdrive]

Hi Terry,

Yes, ofcourse we are friends, it's not a question.
A new puppy would be nice to get, it's a pitty that an ocean is in the way between us.