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 > _______________________________________________ > 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
