G95 feed per revolution

Here is where you can request new features or special features.

G95 feed per revolution

Postby Robertspark » Tue Jul 31, 2018 7:22 pm

As per title, g95 feed per revolution

Given g33 is available, there should be little to prevent this being implemented

Thanks
Robertspark
 
Posts: 1892
Joined: Sat Sep 03, 2016 4:27 pm

Re: G95 feed per revolution

Postby cncdrive » Tue Jul 31, 2018 8:13 pm

What is the usage of that in practise?
Can you give me an example when and how would anyone use this code?
cncdrive
Site Admin
 
Posts: 4887
Joined: Tue Aug 12, 2014 11:17 pm

Re: G95 feed per revolution

Postby Robertspark » Tue Jul 31, 2018 9:09 pm

I can give you two examples:

1) if you have a spindle it will allow the machine to slow the feedrate (which you enter as chipload X number of flues)

It will provide a better surface finish because the feedrate will adjust to machine load (spindle speed)

2) it will give you a consistent finish with lathe / turning applications given if I use an indexable carbide tool with say a 0.4 mm tool radius tip, I know that I can just enter g95 f 0.4 and I'll get a smooth surface finish with the correct chipload on the tool (the chip will be a continuous spiral with aluminium unless I use a chipbreaker tool insert.

Bedside uccnc already will do g33 (with a spindle encoder) seamlessly it allows for the feedrate to be automatically adjusted relative to the ACTUAL spindle speed so surface finish will be improved, why not use the benefits that are available at little time and cost to implement.
Robertspark
 
Posts: 1892
Joined: Sat Sep 03, 2016 4:27 pm

Re: G95 feed per revolution

Postby Robertspark » Tue Jul 31, 2018 9:10 pm

There are lots of posts on the net over it, here is one such discussion

https://www.practicalmachinist.com/vb/c ... od-265234/
Robertspark
 
Posts: 1892
Joined: Sat Sep 03, 2016 4:27 pm

Re: G95 feed per revolution

Postby Robertspark » Tue Jul 31, 2018 9:58 pm

Yup I agree.

If you already have a spindle encoder then it comes into its own, but it must not work off programmed feedrate but the actual feedrate.

Those with undersized spindles will see benefit and also at the start of the cut where spindle speed drops (ok that is relative to doc too and too high feedrate but units/rev should sort this)

Again it is similar to g33 so should not take much to implement exactly the same way... exalt you don't have X Z or Q
Just K which is the same as g95 fword (units/rev)... Pitch
Robertspark
 
Posts: 1892
Joined: Sat Sep 03, 2016 4:27 pm

Re: G95 feed per revolution

Postby Derek » Tue Jul 31, 2018 11:34 pm

Put me on the list.
Derek
 
Posts: 341
Joined: Mon Sep 05, 2016 9:57 am

Re: G95 feed per revolution

Postby cncdrive » Wed Aug 01, 2018 4:04 am

Thanks for the examples.
I don't think that implementing this is as similar to G33 as it looks.
G33 is handled by the motion controller when the motion controller measures the spindle position and syncronises one axis to it.
With the G95 optimally it would be required to calculate all the motion for all axes on the motion controller. (Because the motion is buffered)
In the UCCNC the motion data is calculated on the PC side and sent to the motion controller for execution. Modifying that data on the fly does not seems easy to implement.
Or if it is not done that way then there will be a few tens of milliseconds delay which might be a problem. (I don't know.)

I'm not sure if and when we can and will implement this, because as I mentioned earlier our plan is to soon freeze the developments because we want to upgrade the motion planner to S-curve profiling and the same time we want to simplify/optimise things in the API code so after we can continue other developments easier.
Also we still have the analog output closed loop controller half way finished and want to finish that too and it is also pretty complex and will require other UCCNC function developments to be frozen.
I'm just yet not sure about the order and time these developments will happen.
Currently we work with limited manpower, because Summer holidays are ongoing and so somebody is always missing, so I don't think that many things will happen in August. We will get back to full power in September.
cncdrive
Site Admin
 
Posts: 4887
Joined: Tue Aug 12, 2014 11:17 pm

Re: G95 feed per revolution

Postby Robertspark » Wed Aug 01, 2018 1:05 pm

Thanks Balazs for the explanation + planned path forward with UCCNC
Robertspark
 
Posts: 1892
Joined: Sat Sep 03, 2016 4:27 pm

Re: G95 feed per revolution

Postby cncdrive » Wed Aug 01, 2018 2:32 pm

I have just talked to my collegue about the G95 and he said that in mach3 it is planned with at least 100msec delay, so I think the mentioned few tens of milliseconds should be fine if it is OK how it works in mach3?! :)
If so then it is not that complicated to implement this, because then everything can be planned on the PC side, no need to modify the path calculations in the motion controller.
cncdrive
Site Admin
 
Posts: 4887
Joined: Tue Aug 12, 2014 11:17 pm

Re: G95 feed per revolution

Postby spumco » Wed Aug 01, 2018 2:34 pm

cncdrive wrote:Also we still have the analog output closed loop controller half way finished


That sounds interesting. Unless there's a post or thread I missed somewhere here I haven't heard of this. Can you give a quick explanation of what this is?
spumco
 
Posts: 306
Joined: Mon Oct 03, 2016 10:10 pm

Next

Return to Feature Request

Who is online

Users browsing this forum: No registered users and 4 guests