Re: [Emc-users] max_velocity during execution - multiple axis

[Jon Elson]

On 11/07/2016 09:51 AM, Tomaz T. wrote:
> I'm very very sorry, I really did't want to blame anyone, especially 
> developers, I really appreciate your work an effort to bring Lcnc this far. I 
> just wanted to present my situation and what triggered to open this 
> discussion. Anyway I'm using my machine for afternoon job opportunities which 
> are appearing from time to time, but I was wondering if there are users who 
> are running Lcnc on sirius (retrofitted) machines with more than 3-axis.
>
>
>
Sirius?  Do you mean serious?  Try this one:
https://www.youtube.com/watch?v=Nn1bJ3YAQdI

And

https://www.youtube.com/watch?v=35tHYaDUmZQ

Then, contact Stuart Stevenson (the guy adjusting the 
LocLine hose in 2nd video) about how he did it.
You can find his postings on the Developer's list.

Just got back from the LinuxCNC codefest meeting at Stuart's 
place in Wichita.

Jon

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] max_velocity during execution - multiple axis

[Todd Zuercher]

I believe there are.  There is this very old video of a monstrous old 5 axis 
Cincy after it was retrofitted to Linuxcnc.
https://www.youtube.com/watch?v=mxxdq6y8z8M
If you google 5-axis Linuxcnc for videos you get lots of hits.

- Original Message -
From: "Tomaz T." <tomaz_...@hotmail.com>
To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
Sent: Monday, November 7, 2016 10:51:02 AM
Subject: Re: [Emc-users] max_velocity during execution - multiple axis

I'm very very sorry, I really did't want to blame anyone, especially 
developers, I really appreciate your work an effort to bring Lcnc this far. I 
just wanted to present my situation and what triggered to open this discussion. 
Anyway I'm using my machine for afternoon job opportunities which are appearing 
from time to time, but I was wondering if there are users who are running Lcnc 
on sirius (retrofitted) machines with more than 3-axis.



From: Todd Zuercher <zuerc...@embarqmail.com>
Sent: Monday, November 7, 2016 3:05 PM
To: Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] max_velocity during execution - multiple axis

Unfortunately this is a limitation that has always existed with Linuxcnc.  The 
new TP helped relieve the problem with 3 axis carving, but these limitations 
have always been there.   I don't think the developers can be blamed for you 
not knowing the limitations of your machine (and its software) when you bid 
your jobs.

- Original Message -
From: "Tomaz T." <tomaz_...@hotmail.com>
To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
Sent: Monday, November 7, 2016 9:35:34 AM
Subject: Re: [Emc-users] max_velocity during execution - multiple axis

It surprises me that there were not much discussion about this "drawback" 
regarding TP, when trying to use it on machine and g-code with rotary axis 
moves. For example in my case I have to do an offer for milling PU foam pieces, 
where I could use higher speeds for cutting (like 2500mm/min), but 
unfortunately geometry of final pieces demands full 5-axis final cut where I 
can now reach only about 650mm/min, that means my machining time exceeds way 
over budget and I'm "out of business".



From: Klemen Zivkovic <klemen.zivko...@gmail.com>
Sent: Monday, November 7, 2016 8:05 AM
To: Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] max_velocity during execution - multiple axis

It should complete whole combined move in 1/F minutes.
So if F=2 whole move with acc dec takes 30 secs.

In my gcode processor I calculate it from speed/distance and unit is 1/min
for each segment of toolpath. Beeing axis unitless it can be applied to
axis with different distance units.

On 7 Nov 2016 5:19 a.m., "Danny Miller" <dan...@austin.rr.com> wrote:

> How does inverse-time work?
>
> Say you specify 1 sec to do 1" for a single vector not connected to
> other cuts, so it starts/stop fully at the ends.
>
> Is that the same as F=60ipm, which will take longer due to accel/decel?
>
>
> Or does it guarantee that the whole cut will take 1 sec, which will go
> faster than 60 ipm in the middle?
>
> Danny
>
>
> On 11/6/2016 2:23 PM, andy pugh wrote:
> > On 6 November 2016 at 20:09, Danny Miller <dan...@austin.rr.com> wrote:
> >> Huh, ok, yeah inverse-time does make sense.
> > A little less sense than not-inverse time. In my opinion.
> >
>
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
Emc-users Info Page - 
SourceForge<https://lists.sourceforge.net/lists/listinfo/emc-users>
lists.sourceforge.net
This list is for users of the Enhanced Machine Controller (EMC). Topics include 
how to obtain, install, configure, and use EMC, as well as other general EMC 
related ...




--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
Emc-users Info Page - 
SourceForge<https://lists.sourceforge.net/lists/l

Re: [Emc-users] max_velocity during execution - multiple axis

[Tomaz T .]

I'm very very sorry, I really did't want to blame anyone, especially 
developers, I really appreciate your work an effort to bring Lcnc this far. I 
just wanted to present my situation and what triggered to open this discussion. 
Anyway I'm using my machine for afternoon job opportunities which are appearing 
from time to time, but I was wondering if there are users who are running Lcnc 
on sirius (retrofitted) machines with more than 3-axis.



From: Todd Zuercher <zuerc...@embarqmail.com>
Sent: Monday, November 7, 2016 3:05 PM
To: Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] max_velocity during execution - multiple axis

Unfortunately this is a limitation that has always existed with Linuxcnc.  The 
new TP helped relieve the problem with 3 axis carving, but these limitations 
have always been there.   I don't think the developers can be blamed for you 
not knowing the limitations of your machine (and its software) when you bid 
your jobs.

- Original Message -
From: "Tomaz T." <tomaz_...@hotmail.com>
To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
Sent: Monday, November 7, 2016 9:35:34 AM
Subject: Re: [Emc-users] max_velocity during execution - multiple axis

It surprises me that there were not much discussion about this "drawback" 
regarding TP, when trying to use it on machine and g-code with rotary axis 
moves. For example in my case I have to do an offer for milling PU foam pieces, 
where I could use higher speeds for cutting (like 2500mm/min), but 
unfortunately geometry of final pieces demands full 5-axis final cut where I 
can now reach only about 650mm/min, that means my machining time exceeds way 
over budget and I'm "out of business".



From: Klemen Zivkovic <klemen.zivko...@gmail.com>
Sent: Monday, November 7, 2016 8:05 AM
To: Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] max_velocity during execution - multiple axis

It should complete whole combined move in 1/F minutes.
So if F=2 whole move with acc dec takes 30 secs.

In my gcode processor I calculate it from speed/distance and unit is 1/min
for each segment of toolpath. Beeing axis unitless it can be applied to
axis with different distance units.

On 7 Nov 2016 5:19 a.m., "Danny Miller" <dan...@austin.rr.com> wrote:

> How does inverse-time work?
>
> Say you specify 1 sec to do 1" for a single vector not connected to
> other cuts, so it starts/stop fully at the ends.
>
> Is that the same as F=60ipm, which will take longer due to accel/decel?
>
>
> Or does it guarantee that the whole cut will take 1 sec, which will go
> faster than 60 ipm in the middle?
>
> Danny
>
>
> On 11/6/2016 2:23 PM, andy pugh wrote:
> > On 6 November 2016 at 20:09, Danny Miller <dan...@austin.rr.com> wrote:
> >> Huh, ok, yeah inverse-time does make sense.
> > A little less sense than not-inverse time. In my opinion.
> >
>
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
Emc-users Info Page - 
SourceForge<https://lists.sourceforge.net/lists/listinfo/emc-users>
lists.sourceforge.net
This list is for users of the Enhanced Machine Controller (EMC). Topics include 
how to obtain, install, configure, and use EMC, as well as other general EMC 
related ...




--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
Emc-users Info Page - 
SourceForge<https://lists.sourceforge.net/lists/listinfo/emc-users>
lists.sourceforge.net
This list is for users of the Enhanced Machine Controller (EMC). Topics include 
how to obtain, install, configure, and use EMC, as well as other general EMC 
related ...



--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] max_velocity during execution - multiple axis

[Todd Zuercher]

Unfortunately this is a limitation that has always existed with Linuxcnc.  The 
new TP helped relieve the problem with 3 axis carving, but these limitations 
have always been there.   I don't think the developers can be blamed for you 
not knowing the limitations of your machine (and its software) when you bid 
your jobs.

- Original Message -
From: "Tomaz T." <tomaz_...@hotmail.com>
To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
Sent: Monday, November 7, 2016 9:35:34 AM
Subject: Re: [Emc-users] max_velocity during execution - multiple axis

It surprises me that there were not much discussion about this "drawback" 
regarding TP, when trying to use it on machine and g-code with rotary axis 
moves. For example in my case I have to do an offer for milling PU foam pieces, 
where I could use higher speeds for cutting (like 2500mm/min), but 
unfortunately geometry of final pieces demands full 5-axis final cut where I 
can now reach only about 650mm/min, that means my machining time exceeds way 
over budget and I'm "out of business".



From: Klemen Zivkovic <klemen.zivko...@gmail.com>
Sent: Monday, November 7, 2016 8:05 AM
To: Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] max_velocity during execution - multiple axis

It should complete whole combined move in 1/F minutes.
So if F=2 whole move with acc dec takes 30 secs.

In my gcode processor I calculate it from speed/distance and unit is 1/min
for each segment of toolpath. Beeing axis unitless it can be applied to
axis with different distance units.

On 7 Nov 2016 5:19 a.m., "Danny Miller" <dan...@austin.rr.com> wrote:

> How does inverse-time work?
>
> Say you specify 1 sec to do 1" for a single vector not connected to
> other cuts, so it starts/stop fully at the ends.
>
> Is that the same as F=60ipm, which will take longer due to accel/decel?
>
>
> Or does it guarantee that the whole cut will take 1 sec, which will go
> faster than 60 ipm in the middle?
>
> Danny
>
>
> On 11/6/2016 2:23 PM, andy pugh wrote:
> > On 6 November 2016 at 20:09, Danny Miller <dan...@austin.rr.com> wrote:
> >> Huh, ok, yeah inverse-time does make sense.
> > A little less sense than not-inverse time. In my opinion.
> >
>
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] max_velocity during execution - multiple axis

[Tomaz T .]

It surprises me that there were not much discussion about this "drawback" 
regarding TP, when trying to use it on machine and g-code with rotary axis 
moves. For example in my case I have to do an offer for milling PU foam pieces, 
where I could use higher speeds for cutting (like 2500mm/min), but 
unfortunately geometry of final pieces demands full 5-axis final cut where I 
can now reach only about 650mm/min, that means my machining time exceeds way 
over budget and I'm "out of business".



From: Klemen Zivkovic <klemen.zivko...@gmail.com>
Sent: Monday, November 7, 2016 8:05 AM
To: Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] max_velocity during execution - multiple axis

It should complete whole combined move in 1/F minutes.
So if F=2 whole move with acc dec takes 30 secs.

In my gcode processor I calculate it from speed/distance and unit is 1/min
for each segment of toolpath. Beeing axis unitless it can be applied to
axis with different distance units.

On 7 Nov 2016 5:19 a.m., "Danny Miller" <dan...@austin.rr.com> wrote:

> How does inverse-time work?
>
> Say you specify 1 sec to do 1" for a single vector not connected to
> other cuts, so it starts/stop fully at the ends.
>
> Is that the same as F=60ipm, which will take longer due to accel/decel?
>
>
> Or does it guarantee that the whole cut will take 1 sec, which will go
> faster than 60 ipm in the middle?
>
> Danny
>
>
> On 11/6/2016 2:23 PM, andy pugh wrote:
> > On 6 November 2016 at 20:09, Danny Miller <dan...@austin.rr.com> wrote:
> >> Huh, ok, yeah inverse-time does make sense.
> > A little less sense than not-inverse time. In my opinion.
> >
>
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] max_velocity during execution - multiple axis

[Klemen Živkovič]

It should complete whole combined move in 1/F minutes.
So if F=2 whole move with acc dec takes 30 secs.

In my gcode processor I calculate it from speed/distance and unit is 1/min
for each segment of toolpath. Beeing axis unitless it can be applied to
axis with different distance units.

On 7 Nov 2016 5:19 a.m., "Danny Miller"  wrote:

> How does inverse-time work?
>
> Say you specify 1 sec to do 1" for a single vector not connected to
> other cuts, so it starts/stop fully at the ends.
>
> Is that the same as F=60ipm, which will take longer due to accel/decel?
>
>
> Or does it guarantee that the whole cut will take 1 sec, which will go
> faster than 60 ipm in the middle?
>
> Danny
>
>
> On 11/6/2016 2:23 PM, andy pugh wrote:
> > On 6 November 2016 at 20:09, Danny Miller  wrote:
> >> Huh, ok, yeah inverse-time does make sense.
> > A little less sense than not-inverse time. In my opinion.
> >
>
>
> 
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] max_velocity during execution - multiple axis

[Danny Miller]

How does inverse-time work?

Say you specify 1 sec to do 1" for a single vector not connected to 
other cuts, so it starts/stop fully at the ends.

Is that the same as F=60ipm, which will take longer due to accel/decel?


Or does it guarantee that the whole cut will take 1 sec, which will go 
faster than 60 ipm in the middle?

Danny


On 11/6/2016 2:23 PM, andy pugh wrote:
> On 6 November 2016 at 20:09, Danny Miller  wrote:
>> Huh, ok, yeah inverse-time does make sense.
> A little less sense than not-inverse time. In my opinion.
>


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] max_velocity during execution - multiple axis

[andy pugh]

On 6 November 2016 at 20:09, Danny Miller  wrote:

> Huh, ok, yeah inverse-time does make sense.

Someone has written a utility that tries to convert existing G-code to
inverse-time G-code:
https://www.youtube.com/watch?v=d0ffiCekhpE

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] max_velocity during execution - multiple axis

[Klemen Živkovič]

I think what Robert propose is great - to push current TP little bit
further so planning could take care of ABC axes could be used along XYZ in
inverse time (g93) mode and with g01 moves.

In my case rotational axis A is actually rotating workpiece around Y axis
and radius of A is always easy obtainable as sqrt(x^2 + z^2). For passing
radius of rotation to tp - I would prefer to have some dynamic method wich
means that change of radius will not require restarting lcnc.

I am willing to test such tp as it become available. I have machinekit
simulation in place so with two gcodes results could be seen quite fast - I
could record video or take output on some other intermidiate results.
Test case goal would be, that also with small rotational acceleration and
big rotational velocity limit, tp could plan it in a way that this large
velocities are reached in such cobined small segments of gcode.

I think we should focus to workpiece velocities (as I know all tool
limitations like max speeds or recomended speeds are refering to tool to
workpiece relationship) - but I think:
*motion.current-vel* (OUT FLOAT Current cartesian velocity) refers only to
vector sum of v_x,v_y and v_z. It doesnt take into account rotational
angular speed of A.



On Sun, Nov 6, 2016 at 10:46 PM, Chris Albertson 
wrote:

> If you can compute inverse kinematics for the general case then the
> software in effect "moves" the TP at the desired rate while using inverse
> kinematics to compute the required motor rates.   Planning has to consider
> the motor rates and if the rate is within limits.   Perhaps (I've not read
> the code) LinuxCNC works in a machine centric cordinate system
>
> I think if the goal is to limit TP rate/acceleration relative to the metal
> being cut then you need work in the stock-metal's coordinate system
> The hard part might be transforming the DH from machine centric to stock
> centric.
>
> I think this is the same problem a two handed human might have if
> "machining" a block of wood held in one hand with a die grinder tool in the
> other hand.  Best to do the computation as if the woodblock were stationary
> and the human was spinning around somethings with feet in the air.
>
> I admit IK is a hard problem.   I have a six leg, 18 DOF machine but I
> cheated and hard coded the IK.
>
> On Sun, Nov 6, 2016 at 1:14 PM, andy pugh  wrote:
>
> > On 6 November 2016 at 20:54, Chris Albertson 
> > wrote:
> > > There is already an industry standard for describing the general case
> of
> > > rotary and translational links bolted together serially and even better
> > > already software for working out the kinematics and joint and movement
> > > rates and accelerations
> >
> > LinuxCNC supports general serial kinematics defined by
> > Denavit-Hartenberg parameters using the genserkins module.
> >
> > This is a somewhat different problem.
> >
> > If using genserkins (or any other TCP kinematics) then the existing
> > XYZ blending is all that is needed, as _only_ XYZ moves result in a
> > tool tip motion. ABC moves simply alter the tool orientation abit that
> > point.
> >
> > The problem to be addressed here is somewhat different.
> >
> > --
> > atp
> > "A motorcycle is a bicycle with a pandemonium attachment and is
> > designed for the especial use of mechanical geniuses, daredevils and
> > lunatics."
> > — George Fitch, Atlanta Constitution Newspaper, 1916
> >
> > 
> > --
> > Developer Access Program for Intel Xeon Phi Processors
> > Access to Intel Xeon Phi processor-based developer platforms.
> > With one year of Intel Parallel Studio XE.
> > Training and support from Colfax.
> > Order your platform today. http://sdm.link/xeonphi
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
> >
>
>
>
> --
>
> Chris Albertson
> Redondo Beach, California
> 
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list

Re: [Emc-users] max_velocity during execution - multiple axis

[Chris Albertson]

If you can compute inverse kinematics for the general case then the
software in effect "moves" the TP at the desired rate while using inverse
kinematics to compute the required motor rates.   Planning has to consider
the motor rates and if the rate is within limits.   Perhaps (I've not read
the code) LinuxCNC works in a machine centric cordinate system

I think if the goal is to limit TP rate/acceleration relative to the metal
being cut then you need work in the stock-metal's coordinate system
The hard part might be transforming the DH from machine centric to stock
centric.

I think this is the same problem a two handed human might have if
"machining" a block of wood held in one hand with a die grinder tool in the
other hand.  Best to do the computation as if the woodblock were stationary
and the human was spinning around somethings with feet in the air.

I admit IK is a hard problem.   I have a six leg, 18 DOF machine but I
cheated and hard coded the IK.

On Sun, Nov 6, 2016 at 1:14 PM, andy pugh  wrote:

> On 6 November 2016 at 20:54, Chris Albertson 
> wrote:
> > There is already an industry standard for describing the general case of
> > rotary and translational links bolted together serially and even better
> > already software for working out the kinematics and joint and movement
> > rates and accelerations
>
> LinuxCNC supports general serial kinematics defined by
> Denavit-Hartenberg parameters using the genserkins module.
>
> This is a somewhat different problem.
>
> If using genserkins (or any other TCP kinematics) then the existing
> XYZ blending is all that is needed, as _only_ XYZ moves result in a
> tool tip motion. ABC moves simply alter the tool orientation abit that
> point.
>
> The problem to be addressed here is somewhat different.
>
> --
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is
> designed for the especial use of mechanical geniuses, daredevils and
> lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1916
>
> 
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>



-- 

Chris Albertson
Redondo Beach, California
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] max_velocity during execution - multiple axis

[Robert Ellenberg]

On Sun, Nov 6, 2016 at 4:18 PM Chris Albertson 
wrote:

Just to clear up,  DH allows you to specify any set of translation and
rotation devices, one mounted on the other.   The normal XYZ mill is very
simple case, but as soon as you bolt on a rotary table, especially if the
axis of ration is not parallel to the XYZ axis is gets complex.

The best feature of DH is that is already list software that can compute
forward and inverse kinematics from a file of DH parameters, you don't need
to write that very dificult part.

In fact you can have high acceleration rates of the tool path even while
the motors are running at constant speed.  Computing a motor speed so as to
keep acceleration and velocity under a specified limit is non-trivial.  But
the problem is solved.  Google will return thousands of hits


Naturally, there are many such solutions. My point was that integrating
them into LinuxCNC will require a major overhaul. If we want something
workable quickly, a hack solution to the existing trajectory planner may be
enough for simple cases like a fixed rotary axis.

If our long-term goal is optimal motion planning for a general robot, then
it would be smart to use an existing motion planning library, rather than
to roll our own.
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] max_velocity during execution - multiple axis

[andy pugh]

On 6 November 2016 at 20:54, Chris Albertson  wrote:
> There is already an industry standard for describing the general case of
> rotary and translational links bolted together serially and even better
> already software for working out the kinematics and joint and movement
> rates and accelerations

LinuxCNC supports general serial kinematics defined by
Denavit-Hartenberg parameters using the genserkins module.

This is a somewhat different problem.

If using genserkins (or any other TCP kinematics) then the existing
XYZ blending is all that is needed, as _only_ XYZ moves result in a
tool tip motion. ABC moves simply alter the tool orientation abit that
point.

The problem to be addressed here is somewhat different.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] max_velocity during execution - multiple axis

[Chris Albertson]

Just to clear up,  DH allows you to specify any set of translation and
rotation devices, one mounted on the other.   The normal XYZ mill is very
simple case, but as soon as you bolt on a rotary table, especially if the
axis of ration is not parallel to the XYZ axis is gets complex.

The best feature of DH is that is already list software that can compute
forward and inverse kinematics from a file of DH parameters, you don't need
to write that very dificult part.

In fact you can have high acceleration rates of the tool path even while
the motors are running at constant speed.  Computing a motor speed so as to
keep acceleration and velocity under a specified limit is non-trivial.  But
the problem is solved.  Google will return thousands of hits



On Sun, Nov 6, 2016 at 12:54 PM, Chris Albertson 
wrote:

>
>
> On Sun, Nov 6, 2016 at 9:48 AM, Robert Ellenberg  wrote:
>
>>
>> The hard part is making the effective radius change with tool tip
>> position.
>> That's my long-term goal with this fix, but it may still be a big
>> improvement to assume a constant effective radius.
>>
>
> I assume what you need is to know the location of the axis in XYZ space.
> This would have to be input for each set up and would depend on how you
> bolted the rotary table to the mill table.  In the general case the rotary
> table might be bolted to some other rotary table and so on.  This actually
> happens in the case of an industrial robots
>
> There is already an industry standard for describing the general case of
> rotary and translational links bolted together serially and even better
> already software for working out the kinematics and joint and movement
> rates and accelerations
>
> A good introduction is here: https://en.wikipedia.org/wiki/
> Denavit–Hartenberg_parameters
>
> If you google Denavit-Hartenburg you will find software to read this
> description and to visualize it to a computer screen
>
> The job then of supporting the full general case because one of software
> integration, not inventing new methods
>
> Think of apian spray machine where the paint nozzle must always be kept at
> a fixed distance and angle from the car fender being sprayed and must
> always move at a fixed rate measured tangent to the surface.  These spray
> machine are made mostly of rotary joints were the servo motors are
> controlled to a given angular rate.   A walking robot has the same
> problem.  Its foot must stay on the ground while the robot translates in
> the direction of motion.  The problem is common and open source solution
> exist
>
>
>
>
>>
> --
>
> Chris Albertson
> Redondo Beach, California
>



-- 

Chris Albertson
Redondo Beach, California
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] max_velocity during execution - multiple axis

[Chris Albertson]

On Sun, Nov 6, 2016 at 9:48 AM, Robert Ellenberg  wrote:

>
> The hard part is making the effective radius change with tool tip position.
> That's my long-term goal with this fix, but it may still be a big
> improvement to assume a constant effective radius.
>

I assume what you need is to know the location of the axis in XYZ space.
This would have to be input for each set up and would depend on how you
bolted the rotary table to the mill table.  In the general case the rotary
table might be bolted to some other rotary table and so on.  This actually
happens in the case of an industrial robots

There is already an industry standard for describing the general case of
rotary and translational links bolted together serially and even better
already software for working out the kinematics and joint and movement
rates and accelerations

A good introduction is here:
https://en.wikipedia.org/wiki/Denavit–Hartenberg_parameters

If you google Denavit-Hartenburg you will find software to read this
description and to visualize it to a computer screen

The job then of supporting the full general case because one of software
integration, not inventing new methods

Think of apian spray machine where the paint nozzle must always be kept at
a fixed distance and angle from the car fender being sprayed and must
always move at a fixed rate measured tangent to the surface.  These spray
machine are made mostly of rotary joints were the servo motors are
controlled to a given angular rate.   A walking robot has the same
problem.  Its foot must stay on the ground while the robot translates in
the direction of motion.  The problem is common and open source solution
exist




>
-- 

Chris Albertson
Redondo Beach, California
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] max_velocity during execution - multiple axis

[andy pugh]

On 6 November 2016 at 20:09, Danny Miller  wrote:
> Huh, ok, yeah inverse-time does make sense.

A little less sense than not-inverse time. In my opinion.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] max_velocity during execution - multiple axis

[Danny Miller]

On 11/6/2016 1:57 PM, Robert Ellenberg wrote:
> On Sun, Nov 6, 2016 at 2:46 PM Danny Miller  wrote:
>
>> I did some rotary stuff on Mach3 and was baffled by similar issues.
>>
>> Seems like it'd be CAM's job to manage the feedrate, and calculate for
>> the work radius.  That would make sense if you were cutting a cylinder
>> and the G-code move was "X moves 3 inches, A rotates 100 times, feed X
>> at 1.5 inches/min"
>>
>> But if the cartesians aren't moving- which is common- the F value has no
>> meaning at all if it's cartesian.  There is no way for G-code language
>> to communicate "polar Feed =  200 deg/sec" and it's nonsense to combine
>> polar and cartesian vectors into a single scalar for a feedrate.
>>
> The F word is overloaded. If there's no cartesian motion, then it treats
> the number as degrees per min instead of in per min.
That sounds like a bad idea.  The interp of F jumps around to a totally 
different thing if there's no cartesian motion?
So if you MDI in  "G1 X1 A200 F3" it does one thing if you're at X=2 and 
a totally different thing if you're at X=1?  Or does the inclusion of 
any linear axis mode it over to cartesian?  Well, but, you couldn't do 
that- if you're already at X=1, F3 is all polar and it's impossible to 
interpret as a linear feedrate since there's no linear motion.

What if X moves 0.001" and that gets optimized out?
>
> Seems like the logical answer is amending G-code Feedrate with syntax
>> for an angular vector in addition to cartesian, but no CAM pkg would
>> support it.
>
> The "proper" way as I understand it is to use inverse time when doing both
> linear and angular moves. It's perfectly sensible to say "move X inches and
> A degress within T seconds".

Huh, ok, yeah inverse-time does make sense.
>


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] max_velocity during execution - multiple axis

[Robert Ellenberg]

On Sun, Nov 6, 2016 at 2:46 PM Danny Miller  wrote:

> I did some rotary stuff on Mach3 and was baffled by similar issues.
>
> Seems like it'd be CAM's job to manage the feedrate, and calculate for
> the work radius.  That would make sense if you were cutting a cylinder
> and the G-code move was "X moves 3 inches, A rotates 100 times, feed X
> at 1.5 inches/min"
>
> But if the cartesians aren't moving- which is common- the F value has no
> meaning at all if it's cartesian.  There is no way for G-code language
> to communicate "polar Feed =  200 deg/sec" and it's nonsense to combine
> polar and cartesian vectors into a single scalar for a feedrate.
>

The F word is overloaded. If there's no cartesian motion, then it treats
the number as degrees per min instead of in per min.

Seems like the logical answer is amending G-code Feedrate with syntax
> for an angular vector in addition to cartesian, but no CAM pkg would
> support it.


The "proper" way as I understand it is to use inverse time when doing both
linear and angular moves. It's perfectly sensible to say "move X inches and
A degress within T seconds".
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] max_velocity during execution - multiple axis

[Danny Miller]

I did some rotary stuff on Mach3 and was baffled by similar issues.

Seems like it'd be CAM's job to manage the feedrate, and calculate for 
the work radius.  That would make sense if you were cutting a cylinder 
and the G-code move was "X moves 3 inches, A rotates 100 times, feed X 
at 1.5 inches/min"

But if the cartesians aren't moving- which is common- the F value has no 
meaning at all if it's cartesian.  There is no way for G-code language 
to communicate "polar Feed =  200 deg/sec" and it's nonsense to combine 
polar and cartesian vectors into a single scalar for a feedrate.

Seems like the logical answer is amending G-code Feedrate with syntax 
for an angular vector in addition to cartesian, but no CAM pkg would 
support it.

Then again, the alternative is soft-declaring an axis and calculating 
surface speed and interpret the F as surface speed. Which would also not 
be supported by CAM AFAIK.  Well how DO commercial 4/5 axis CAM tools 
declare feedrates?   I presume they have a solution, as the tech's been 
in wide commercial use for a long time.

Danny


On 11/6/2016 11:48 AM, Robert Ellenberg wrote:
> As of now, circular arc blending doesn't work with the ABC axes (which is
> why it's running so slowly for you with short segments), but I'm working on
> a fix. I had an extensive discussion with Andy Pugh a while back, which led
> to some great ideas on how to solve this problem. There are two big reasons
> it doesn't work now:
>
> 1) ABC units are degrees, whereas linear axes (XYZUVW) are in distance. A
> spherical arc doesn't make physical sense between axes of different units.
>
> 2) "Velocity" as defined by the TP is actually velocity in either XYZ, ABC,
> or UVW axes, depending on the context, but a spherical arc in general would
> involve change in all 9 axes, so the arc length (and it's derivatives, TP
> velocity and acceleration) needs to be expressed in terms of all axes.
>
> What I'm working on now is to treat ABC axis motion as an equivalent tool
> tip motion in distance units. For example, if the tool is 10 inches above
> the physical A axis, then the A axis has an effective radius of 10 inches.
> Therefore it's easy to convert the angular motion to an equivalent tool top
> motion. Ex: a 90 deg rotation would be similar to a linear move of pi / 2 *
> 10 ~= 15.71 in.
>
> The good news is, if we assume some constant effective radius for all ABC
> axes, I think it's possible to implement with the same basic structures as
> the ones in my my experimental UVW axes blending branch
> <https://github.com/robEllenberg/linuxcnc-mirror/tree/feature/uvw-blending-dev>
> .
>
> The hard part is making the effective radius change with tool tip position.
> That's my long-term goal with this fix, but it may still be a big
> improvement to assume a constant effective radius.
>
> Best,
> Rob
>
> On Sun, Nov 6, 2016 at 10:51 AM Tomaz T. <tomaz_...@hotmail.com> wrote:
>
> So for now there is no solution to speed this up till TP will be modified
> in the way that it will take and "optimize" also moves with rotary axis ...?
>
>
> PS. yes I'm from Slovenia.
>
>
> 
> From: klemenzivko...@gmail.com <klemenzivko...@gmail.com> on behalf of
> Klemen Zivkovic <klemen.zivko...@gmail.com>
> Sent: Sunday, November 6, 2016 2:10 PM
> To: tomaz_...@hotmail.com
> Subject: [Emc-users] max_velocity during execution - multiple axis
>
> Hello,
>
>
> I think your problem is that linuxcnc have x,y,z trajectory planning. As
> soon as you add rotary axis to have combined move you end up with single
> lookahead in tp, so this limits velocity.
> Check this out:
> https://forum.linuxcnc.org/20-g-code/29662-coordinated-motion-involving-rotary-axis
>
>
> According to your name - I need to ask you are you native slovenian speaker?
>
>
> regards
> KLemen
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> 

Re: [Emc-users] max_velocity during execution - multiple axis

[Robert Ellenberg]

at 10:51 AM Tomaz T. <tomaz_...@hotmail.com> wrote:
>
> So for now there is no solution to speed this up till TP will be modified
> in the way that it will take and "optimize" also moves with rotary axis
> ...?
>
>
> PS. yes I'm from Slovenia.
>
>
> 
> From: klemenzivko...@gmail.com <klemenzivko...@gmail.com> on behalf of
> Klemen Zivkovic <klemen.zivko...@gmail.com>
> Sent: Sunday, November 6, 2016 2:10 PM
> To: tomaz_...@hotmail.com
> Subject: [Emc-users] max_velocity during execution - multiple axis
>
> Hello,
>
>
> I think your problem is that linuxcnc have x,y,z trajectory planning. As
> soon as you add rotary axis to have combined move you end up with single
> lookahead in tp, so this limits velocity.
> Check this out:
> https://forum.linuxcnc.org/20-g-code/29662-coordinated-
> motion-involving-rotary-axis
>
>
> According to your name - I need to ask you are you native slovenian
> speaker?
>
>
> regards
> KLemen
> 
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
> 
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] max_velocity during execution - multiple axis

[Klemen Živkovič]

It seems that real motion and speeds are to be viewed from workpiece
coordinate system since one of the main requirements in CNC is to have
constant speed of tool over surface.
Also there is a need to somehow define generic way of calculating real
workpiece coordinates from dX,  dY, dZ and dA, dB, dC dU, dV, dW since
linuxcnc could not know,
what is machine geometry or tool movement dependency on different axis.

Since change A,B,C and U,V,W axes each separately or in combination result
in X,Y,Z movement
would it be possible to put in INI a math expression that would be kind of:

X(dA;dB;dC;dU,dV,dW) = dX + [name of radius A pin] * sin(dA*PI/180) + [name
of radius A pin] * cos(dA*PI/180) + ... (formulas of X dependency from
other axes) ...
Y(dA;dB;dC;dU,dV,dW) = 0
Z(dA;dB;dC;dU,dV,dW) = dZ + [name of radius A pin] * cos(dA*PI/180) + [name
of radius A pin] * sin(dA*PI/180) + ... (formulas of Z dependency from
other axes) ...

final movement would be then

Xnew = X_from_queue + X(dA;dB;dC;dU,dV,dW)
and similar for Y and Z axis.

In this way user could define dependencies of main cartesian axes XYZ from
angular ABC or linear UVW axis.

It seems that would require adding some symbolic computation library...
(check
http://stackoverflow.com/questions/11715162/symbolic-computation-library-in-pure-c
).

I hope I am not too much off topic and ideas are not too extreme to
implement.
Also if this is to be part of kinematics module of lcnc please somebody
correct me or direct me how this is to be aproached...





On Sun, Nov 6, 2016 at 6:48 PM, Robert Ellenberg <rwe...@gmail.com> wrote:

> As of now, circular arc blending doesn't work with the ABC axes (which is
> why it's running so slowly for you with short segments), but I'm working on
> a fix. I had an extensive discussion with Andy Pugh a while back, which led
> to some great ideas on how to solve this problem. There are two big reasons
> it doesn't work now:
>
> 1) ABC units are degrees, whereas linear axes (XYZUVW) are in distance. A
> spherical arc doesn't make physical sense between axes of different units.
>
> 2) "Velocity" as defined by the TP is actually velocity in either XYZ, ABC,
> or UVW axes, depending on the context, but a spherical arc in general would
> involve change in all 9 axes, so the arc length (and it's derivatives, TP
> velocity and acceleration) needs to be expressed in terms of all axes.
>
> What I'm working on now is to treat ABC axis motion as an equivalent tool
> tip motion in distance units. For example, if the tool is 10 inches above
> the physical A axis, then the A axis has an effective radius of 10 inches.
> Therefore it's easy to convert the angular motion to an equivalent tool top
> motion. Ex: a 90 deg rotation would be similar to a linear move of pi / 2 *
> 10 ~= 15.71 in.
>
> The good news is, if we assume some constant effective radius for all ABC
> axes, I think it's possible to implement with the same basic structures as
> the ones in my my experimental UVW axes blending branch
> <https://github.com/robEllenberg/linuxcnc-mirror/
> tree/feature/uvw-blending-dev>
> .
>
> The hard part is making the effective radius change with tool tip position.
> That's my long-term goal with this fix, but it may still be a big
> improvement to assume a constant effective radius.
>
> Best,
> Rob
>
> On Sun, Nov 6, 2016 at 10:51 AM Tomaz T. <tomaz_...@hotmail.com> wrote:
>
> So for now there is no solution to speed this up till TP will be modified
> in the way that it will take and "optimize" also moves with rotary axis
> ...?
>
>
> PS. yes I'm from Slovenia.
>
>
> 
> From: klemenzivko...@gmail.com <klemenzivko...@gmail.com> on behalf of
> Klemen Zivkovic <klemen.zivko...@gmail.com>
> Sent: Sunday, November 6, 2016 2:10 PM
> To: tomaz_...@hotmail.com
> Subject: [Emc-users] max_velocity during execution - multiple axis
>
> Hello,
>
>
> I think your problem is that linuxcnc have x,y,z trajectory planning. As
> soon as you add rotary axis to have combined move you end up with single
> lookahead in tp, so this limits velocity.
> Check this out:
> https://forum.linuxcnc.org/20-g-code/29662-coordinated-
> motion-involving-rotary-axis
>
>
> According to your name - I need to ask you are you native slovenian
> speaker?
>
>
> regards
> KLemen
> 
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> Emc-use

Re: [Emc-users] max_velocity during execution - multiple axis

[Robert Ellenberg]

As of now, circular arc blending doesn't work with the ABC axes (which is
why it's running so slowly for you with short segments), but I'm working on
a fix. I had an extensive discussion with Andy Pugh a while back, which led
to some great ideas on how to solve this problem. There are two big reasons
it doesn't work now:

1) ABC units are degrees, whereas linear axes (XYZUVW) are in distance. A
spherical arc doesn't make physical sense between axes of different units.

2) "Velocity" as defined by the TP is actually velocity in either XYZ, ABC,
or UVW axes, depending on the context, but a spherical arc in general would
involve change in all 9 axes, so the arc length (and it's derivatives, TP
velocity and acceleration) needs to be expressed in terms of all axes.

What I'm working on now is to treat ABC axis motion as an equivalent tool
tip motion in distance units. For example, if the tool is 10 inches above
the physical A axis, then the A axis has an effective radius of 10 inches.
Therefore it's easy to convert the angular motion to an equivalent tool top
motion. Ex: a 90 deg rotation would be similar to a linear move of pi / 2 *
10 ~= 15.71 in.

The good news is, if we assume some constant effective radius for all ABC
axes, I think it's possible to implement with the same basic structures as
the ones in my my experimental UVW axes blending branch
<https://github.com/robEllenberg/linuxcnc-mirror/tree/feature/uvw-blending-dev>
.

The hard part is making the effective radius change with tool tip position.
That's my long-term goal with this fix, but it may still be a big
improvement to assume a constant effective radius.

Best,
Rob

On Sun, Nov 6, 2016 at 10:51 AM Tomaz T. <tomaz_...@hotmail.com> wrote:

So for now there is no solution to speed this up till TP will be modified
in the way that it will take and "optimize" also moves with rotary axis ...?


PS. yes I'm from Slovenia.



From: klemenzivko...@gmail.com <klemenzivko...@gmail.com> on behalf of
Klemen Zivkovic <klemen.zivko...@gmail.com>
Sent: Sunday, November 6, 2016 2:10 PM
To: tomaz_...@hotmail.com
Subject: [Emc-users] max_velocity during execution - multiple axis

Hello,


I think your problem is that linuxcnc have x,y,z trajectory planning. As
soon as you add rotary axis to have combined move you end up with single
lookahead in tp, so this limits velocity.
Check this out:
https://forum.linuxcnc.org/20-g-code/29662-coordinated-motion-involving-rotary-axis


According to your name - I need to ask you are you native slovenian speaker?


regards
KLemen
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] max_velocity during execution - multiple axis

[Tomaz T .]

So for now there is no solution to speed this up till TP will be modified in 
the way that it will take and "optimize" also moves with rotary axis ...?


PS. yes I'm from Slovenia.



From: klemenzivko...@gmail.com <klemenzivko...@gmail.com> on behalf of Klemen 
Zivkovic <klemen.zivko...@gmail.com>
Sent: Sunday, November 6, 2016 2:10 PM
To: tomaz_...@hotmail.com
Subject: [Emc-users] max_velocity during execution - multiple axis

Hello,


I think your problem is that linuxcnc have x,y,z trajectory planning. As soon 
as you add rotary axis to have combined move you end up with single lookahead 
in tp, so this limits velocity.
Check this out:
https://forum.linuxcnc.org/20-g-code/29662-coordinated-motion-involving-rotary-axis


According to your name - I need to ask you are you native slovenian speaker?


regards
KLemen
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] max_velocity during execution - multiple axis

[Klemen Živkovič]

I think it is quite similar issue like in:
https://forum.linuxcnc.org/20-g-code/29662-coordinated-motion-involving-rotary-axis


On Sun, Nov 6, 2016 at 2:59 PM, Tomaz T.  wrote:

> I'm doing some tests on sim.vismach.5axis running full 5-axis code
> (milling sphere with spiral tool path). I have entered max_velocity and
> max_acceleration for each axis same as I have on my real machine and also
> in TRAJ section. So, when I'm running code, machine (sim) it reaches only
> half of its max_velocity, and only thing that helps is to "insanely"
> increase max_acceleration for both angular axis.
>
> So why is there such a big difference, and what else could help to speed
> it up?
>
>
> If there is anyone interest to test this (in sim), here is code:
>
> https://dl.dropboxusercontent.com/u/11501489/5x-test02.ngc
>
>
> My INI settings for linear axis are:
>
> MAX_VELOCITY:   90
>
> MAX_ACCELERATION: 100
>
>
> and for angular axis:
>
> MAX_VELOCITY:   20
>
> MAX_ACCELERATION: 35
> 
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] max_velocity during execution - multiple axis

[Tomaz T .]

I'm doing some tests on sim.vismach.5axis running full 5-axis code (milling 
sphere with spiral tool path). I have entered max_velocity and max_acceleration 
for each axis same as I have on my real machine and also in TRAJ section. So, 
when I'm running code, machine (sim) it reaches only half of its max_velocity, 
and only thing that helps is to "insanely" increase max_acceleration for both 
angular axis.

So why is there such a big difference, and what else could help to speed it up?


If there is anyone interest to test this (in sim), here is code:

https://dl.dropboxusercontent.com/u/11501489/5x-test02.ngc


My INI settings for linear axis are:

MAX_VELOCITY:   90

MAX_ACCELERATION: 100


and for angular axis:

MAX_VELOCITY:   20

MAX_ACCELERATION: 35
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users