Re: [Emc-users] Acceleration Settings?

[Robert Ellenberg]

A few quick tests to try to narrow this down:

   1. Does running the same command with G61 fix the issue?
   2. In G64, if you call a subroutine via MDI that does multiple moves, is
   just the last move at reduced acceleration?
   3. Does the last move of a program accelerate slowly as well?

If the answer to some or all of these is yes, then it might be the
trajectory planner's blending behavior. In G64 mode, incoming motions to
the trajectory planner are blended with parabolic blends by default (the
old linuxcnc 2.6 and earlier method). Parabolic blending works by dropping
accelerations of segments to 50% of max, so that prev / next segments can
be run simultaneously without violating acceleration constraints.
Unfortunately, the last motion is stuck waiting for a "next" motion that
will never come, so it ends up at 50% of max acceleration.

The fix for this is not trivial, but you may be able to work around it by
doing your testing in G61.

-Rob

On Thu, May 16, 2024 at 8:58 AM Todd Zuercher via Emc-users <
emc-users@lists.sourceforge.net> wrote:

> Maybe I spoke too soon.  I did a little more searching and found that
> there is an issue with MDI commands that they are executed with half of the
> acceleration of the settings.  Is this intentional for some reason, or is
> it a bug?
>
> I confirmed with this machine that yes, regular G-code programs and
> jogging moves use the correct acceleration limits, but MDI commands only
> use half.  Why is that?  2.7 didn't have this behavior.
>
> It kind of makes testing machine settings a pain in the...
>
> Todd Zuercher
> P. Graham Dunn Inc.
> 630 Henry Street
> Dalton, Ohio 44618
> Phone:  (330)828-2105ext. 2031
>
> -Original Message-
> From: Jon Elson 
> Sent: Wednesday, May 15, 2024 7:20 PM
> To: emc-users@lists.sourceforge.net
> Subject: Re: [Emc-users] Acceleration Settings?
>
> [EXTERNAL EMAIL] Be sure links are safe.
>
> On 5/15/24 12:23, Todd Zuercher via Emc-users wrote:
> > I'm trying to figure out something goofy that seems to be going on with
> my acceleration settings.
> > I'm running Linuxcnc 2.9.0 and Axis ui.
> > I have all of the max_acceleration settings set for 20.0 (and
> stepgen_maxaccel = 25), and for some reason everything only  moves with an
> acceleration of 10 ipsps for G0 and G1 moves (confirmed with Halscope), but
> jogging does go at 20.  Is there normal behavior or am I missing some
> setting somewhere that is limiting the acceleration?
> >
> In the latest LinuxCNC there are TWO places that have accel and max
> velocity settings.  Jogging is in the JOINT_x part, and CNC moves are in
> the AXIS_x section.  In general, you want the same settings in both JOINT
> and AXIS sections.
>
> Jon
>
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Spindle speed changes with threading.

[Robert Ellenberg]

Hi John,

Good catch! Andy also pointed out that multi-start threading is of course
possible if you do a Z offset like you describe. I was thinking of "native"
support for multi-start in G33 / G33.1, like with a word specifying the
start location in degrees.

-Rob

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Spindle speed changes with threading.

[Robert Ellenberg]

Ahh, good point! It would be nice to be able to explicitly specify a
spindle angle too, but that's a good workaround.

On Wed, Jan 20, 2021, 1:50 PM Andy Pugh  wrote:

>
>
> > On 20 Jan 2021, at 18:14, Robert Ellenberg  wrote:
> >
> >
> > Note that multi-start threading is not currently possible
>
>
> You can do it by offsetting the start point.
> (If there is room)
>
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Spindle speed changes with threading.

[Robert Ellenberg]

Hi All,

As others have said, during position-synched moves, the axes follow the
spindle position, so you don't need fine control of spindle speed. However,
you should have both a stable spindle RPM and a high-ish resolution encoder
to get the best results. John, for your example, as each encoder pulse
arrives, the TP will be constantly accelerating / decelerating to try to
track that position signal. Luckily, it can't get too far off because of
the axis acceleration limits, but the amplitude of the jitter will
definitely be higher with a low resolution encoder.

Here's how spindle synchronization broadly works from within the TP (i.e.
what occurs in motion after START_FEED_SPEED_SYNCH)

   1. The TP waits (with axes stopped) for a spindle index mark.
   2. Once the spindle has just passed the mark, the machine axes
   accelerate until they reach (spindle speed * requested units/rev).
   3. Once the axes reach the expected velocity, then synchronization is
   declared, and the TP maintains position synchronization from that point
   onwards. At higher spindle RPM, synchronization takes longer, so the
   spindle rotates farther before the axes are synchronized. Multiple
   threading passes at different spindle RPM will not quite follow the same
   path.
   4. After synchronization, the TP computes a position error based on the
   measured spindle position. The axis velocity is nominally spindle speed *
   uu / rev, but that velocity is corrected up or down as needed to drive the
   position error toward zero.

Note that multi-start threading is not currently possible (because the TP
always synchs at 0 deg, i.e. at the index mark), but we could modify the TP
to start synchronization at some angle after the index mark.

Finally, the obvious fix for the inconsistency in the acceleration phase is
to just declare synchronization at the index mark right away. With the axes
starting from rest, there would be a huge initial velocity error for the TP
to correct. It will do so eventually, but there are large position over- /
under-shoots until it stabilizes. Luckily, we know what the axis
acceleration looks like (based on axis max acceleration and nominal spindle
speed), so you can anticipate this and start the axes moving before the
spindle reaches the index mark. That way, the axes are moving at the
nominal speed just as the spindle reaches zero. This removes most of the
position error at the start, and the TP corrects for any residual error
very quickly. This is roughly the approach we used in PathPilot, and I
think LinuxCNC 2.8 or 2.9 would benefit from it as well.

Best,
Rob

On Wed, Jan 20, 2021 at 12:47 PM John Dammeyer 
wrote:

>
>
> > From: andy pugh [mailto:bodge...@gmail.com]
> >
> > On Wed, 20 Jan 2021 at 16:09, Kirk Wallace 
> wrote:
> >
> > > I left the trail here:
> > > >
> https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/rs274ngc/interp_convert.cc#L4881-L5028
> >
> > There seems to have been a lot of time spent investigating theory that
> > could have been settled in 5 minutes with an experiment.
> >
> > --
> > atp
>
> Dropping an apple from a tree and observing that it falls and smashes on
> the ground doesn't splatter into the words that spell out laws of motion
> made up of bits of peel and apple.
>
> I'm assuming that the authors of this code were clever enough to take into
> account the motor acceleration relative to spindle speed on each pass.  But
> that doesn't explain how they do that.
>
> And if there are 60 teeth on the spindle encoder with a single sensor then
> 120 edges are the most you get.  That's 3 degrees per edge assuming the
> slots are symmetrical and I don't think there's a rule that they must be.
> Might be 1 and 5 degrees.  So assume then an index single rising edge is
> used every 6 degrees.
>
> A half inch shaft has a circumference of 0.3925" and each 6 degree index
> is 0.00654".  The implication is depending on spindle speed and motor
> acceleration you might be off by almost 0.006".  That's a lot isn't it?
>
> John
>
>
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Halscope Log Files

[Robert Ellenberg]

Andy,

Try this branch here:


https://github.com/LinuxCNC/linuxcnc/tree/rellenberg/halscope

It adds native CSV-saving capability to halscope (if you specify a .csv
file in the save dialog). It's much easier to parse in something like
octave (and also much faster). It won't do much for the reading-back-in
part, unfortunately.

-Rob

On Thu, Oct 22, 2020 at 12:44 PM andy pugh  wrote:

> On Thu, 22 Oct 2020 at 16:50, Nicklas SB Karlsson  wrote:
> >
> > Did not read very carefully, if you need maybe I could spend a few other
> > try to get the halscope log file into Octave.
>
> I would be much more interested in getting a halcope log back in to
> halscope.
>
> --
> 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, 1912
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G93 minimum value/behaviour

[Robert Ellenberg]

There is a quirk with G93 in one specific case that causes trouble. G93 for
reasons unknown enforces a minimum feedrate of 0.1 units / min:

https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/rs274ngc/interp_inverse.cc#L65

...
  length = find_arc_length(x1, y1, z1, cx, cy, turn, x2, y2, z2);
  rate = std::max(0.1, (length * block->f_number));
  enqueue_SET_FEED_RATE(rate);
...

This causes trouble because of how LinuxCNC understands feed rates / motion
distances
.
As long as there is any XYZ motion longer than 1e-7 inches, the length of
the motion is computed solely in terms of XYZ distance, and the ABC axes
move at whatever feed is necessary to be in phase with the XYZ motion.

An extreme example:
N1 G20 G0 X0 Y0 Z0 A0
N2 G93 G1 Z-0.01 A[360*5] F1.0 (1 minute for 5 revolutions)

The "length" in move N2 is 0.01 in. Based on the code above, the natural
feed rate for this would be 0.01, but it's forced to be 0.1, or 10x higher
than you'd expect.

I think a smarter approach would be to check if the effective feed rate is
too small (like below what a machine can actually execute) and throw an
error, rather than silently "fixing" it like this.

-Rob

On Mon, Sep 14, 2020 at 10:44 AM Gene Heskett  wrote:

> On Monday 14 September 2020 10:24:49 Scott Harwell via Emc-users wrote:
>
> >  Andy
> > I agree this seems more trouble than needed, but if you can get
> > working G code for an example it should help in fixing the post.
> >
> > Could it be a problem with axis wrap (going past 359.999) in the
> > formatting? I understand you can program multiple turns on the rotary
> > axis but what dose the next move expect for an endpoint after rollover
> > on actual position? From A0 to A720 is two rotations but is the next
> > line for two rotations A 720 or A1440?
> >
> > Scott
>
> In my setups, others could be different, but angles are absolute using
> home as a zero reference.
>
> Homeing on a rotary however is to the home switch, you can run it 45000
> degrees as in this thread, but it will rehome to 0, or whatever offset
> from the switch is programmed, in under a turn.
>
> To answer the question, if you have run it to 720 previously, then a cmd
> to go 1440, will turn it two more turns and conversely a cmd to
> goto -1440 will turn it 6 turns in the opposite direction.
> >
> > On Monday, September 14, 2020, 4:30:45 AM CDT, andy pugh
> >  wrote:
> >
> >  On Mon, 14 Sep 2020 at 04:38, Scott Harwell via Emc-users
> >
> >  wrote:
> > >  I found this it might help.
> > > Scott
> > > Rapid Rotary
> >
> > Along the same lines, there is a filter file here that automatically
> > converts XY UV G-code to G93 based on which end is bigger.
> > https://forum.linuxcnc.org/38-general-linuxcnc-questions/35141-a-head-
> >scratcher-for-me?start=10#120524
> >
> > The only reason I mention this is that it runs automatically as the
> > G-code file is opened, rather than being a separate application.
> > (And, to be fair, this isn't an option for RapidRotary as it needs to
> > be able to query the working radius)
>
>
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> If we desire respect for the law, we must first make the law respectable.
>  - Louis D. Brandeis
> Genes Web page 
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

[Robert Ellenberg]

I totally agree that a silent failure mode (especially one that can break
taps) is bad news. Perhaps thankfully, we've gotten away with it for a long
time: based on the git history, the 10-rev overshoot limit and this silent
failure mode has been around at least since the 2.6 days, maybe earlier.

I have a few ways in mind to fix this:

   1. Throw an error and abort motion if it reaches some threshold of
   overshoot (say 90% of the maximum), or maybe if the position tracking error
   exceeds some threshold.
   2. Check if the rigid tap motion + max overshoot exceeds the axis limits
   (currently we check before adding the overshoot allowance, which in theory
   could lead to motion past the soft limits)
   3. (optional) Tell motion what the expected spindle acceleration is (via
   HAL pin), so that it can start reversing before it hits the bottom of the
   hole (reducing the overshoot). Leaving this pin at zero (default) would
   give you the current behavior.

 -Rob

On Tue, Jul 21, 2020 at 2:17 PM Gene Heskett  wrote:

> On Tuesday 21 July 2020 13:09:16 andy pugh wrote:
>
> > On Tue, 21 Jul 2020 at 18:03, Robert Ellenberg 
> wrote:
> > >1. The rigid tapping cycle allows a hard-coded 10 revolutions
> > >
> > > <https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/tp/tc.c#L8
> > >56> of overtravel beyond the nominal bottom of the hole when
> > > reversing direction.
> >
> > That feels like there should be an error message.
> >
> > "Maximum rigid tapping limit exceeded. And furthermore I have just
> > broken your tap"
>
> "Maximum rigid tapping limit exceeded. And furthermore I have just
>  broken your $85 carbide tap"
>
> There, I fixed it for you. :(
>
> 10 turns is way too far. I cut air at least once to measure the
> turnaround (I have that stuff in my .hal file) and in what I have done,
> that has led me to set a personal limit of 2 turns. Taking a broken tap
> out of a valuable blind hole via EDM is a genuine PITA and I will do
> whatever it takes to avoid that. But, I would not uncouple the spindle
> from the tap either, killing the spindle drive ASAP instead, then one
> might be able to  back the tap out of the hole with the spindle,
> salvaging the part so maybe the hole could be finished by hand.
>
> 10 turns, breaking the tap is the wrong thing to do. Shutting down,
> leaving it coupled before the tap breaks is the best thing to do.
>
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> If we desire respect for the law, we must first make the law respectable.
>  - Louis D. Brandeis
> Genes Web page <http://geneslinuxbox.net:6309/gene>
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Problem with Rigid Tapping on USC Equipped Bridgeport

[Robert Ellenberg]

Based on the videos and your descriptions of the behavior, you may be
running into a TP issue I've seen (in simulation) with very sluggish
spindles or very high spindle speeds. Here's what I think is going on:

   1. The rigid tapping cycle allows a hard-coded 10 revolutions
   
   of overtravel beyond the nominal bottom of the hole when reversing
   direction.
   2. The spindle starts reversing direction only after the Z axis has
   reached the bottom, so the spindle has to be able to stop in 10 revolutions
   to stay within the budgeted overtravel.
   3. If the TP hits the end of the overtravel, it prematurely declares the
   motion to be complete and stops following the spindle motion.

Do you still see this behavior if you run the spindle slower? Your spindle
seems to take a long time to reverse, so at high speeds you may be hitting
this limit.

Best,
Rob


On Tue, Jul 21, 2020 at 11:18 AM Matthew Herd  wrote:

> Ahh, so I do use limit switches and a homing routine.  So it’s homing to
> the same position (plus or minus a few thousandths or so).
>
> > On Jul 21, 2020, at 11:07 AM, Jon Elson  wrote:
> >
> > On 07/21/2020 04:20 AM, andy pugh wrote:
> >> On Tue, 21 Jul 2020 at 10:18, andy pugh  wrote:
> >>
> >>> We are not looking for noise, we are looking for spurious encoder
> count resets.
> >> But, thinking further, even if there _is_ noise on the index line, the
> >> encoder counter should ignore it. It ignores all the _real_ indexes
> >> unless index-enable is set true in HAL.
> >>
> > Yes, the only thing I can think of is he's hitting his soft limits. Over
> time, starting and stopping LinuxCNC,
> > without homing, the machine limits will drift.  If you have rational
> limits in the .ini file, you will eventually reach the end of them and have
> really strange behavior.  it can be fixed by homing in a safe position,
> > but best to put in home switches and actually home the machine to a
> repeatable position every time.
> >
> > Jon
> >
> >
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
>
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Version 2.7 positioning problem during cnc operations

[Robert Ellenberg]

I agree on both counts, that G0 should always be exact stop, and that the
behavior should be  configurable via an INI setting (maybe not HAL, because
switching settings online would have weird side effects). It should be an
easy change (there is one location in the TP that does pre-checks for
blending, so it would be simple to make it reject G0 moves).

Rob

On Wed, Mar 29, 2017, 2:05 PM sam sokolik  wrote:

> I agree somewhat.  :)  I think it should be a hal pin or a ini setting
>
> sam
>
> On 3/29/2017 12:43 PM, Todd Zuercher wrote:
> > My personal opinion is that all G0 moves should always be exact stop
> positioning moves not blended moves.  To treat them as anything else seems
> silly.  If the previous behavior of Linuxcnc was to blend them, then it is
> just plane wrong and should be corrected.  Having multiple G0 moves
> executed after each other is somewhat of an unusual situation to start
> with.  And is the reason I had never noticed that G0 moves were blended in
> the old planner.  But neither planner blends a move between a G0 and G1
> move as far as I know.  Because of this most people never notice.  I am
> pretty sure G0 moves are exact stop positioning moves in all the other CNC
> controls I have worked with (Fanuc, and others).
> >
> > - Original Message -
> > From: "sam sokolik" 
> > To: "Enhanced Machine Controller (EMC)"  >
> > Sent: Wednesday, March 29, 2017 11:22:10 AM
> > Subject: Re: [Emc-users] Version 2.7 positioning problem during cnc
>  operations
> >
> > The cheap and dirty way would be to add
> > add in the TRAJ sectio/n
> >
> > ARC_BLEND_ENABLE = 0
> >
> > /This puts the trajectoy planner into pre 2.7 mode (pre circular arc
> > blend - 1 segment look ahead)
> >
> > You obviously lose x segment look ahead.  During testing exact stop mode
> > happened between G0 and contouring moves - but that changed the behavior
> > of linuxcnc so I think it was taken out. (now it blends between all
> > segments types.)
> >
> > Currently the fix is adding G64Px.xxx at the beginning of all programs.
> >
> > sam
> >
> > //
> > On 3/29/2017 9:37 AM, Stuart Stevenson wrote:
> >> Gentlemen,
> >> This is connected to the G64 question I asked on the developers list
> >> yesterday.
> >>
> >> G64 P0 does not change the positioning problem on the machine.
> >>
> >> Problem description:
> >> desired machine motion
> >>position XY with Z above the material/work level
> >>move Z to material/work level
> >>face mill top of material
> >>
> >>  encountered machine motion
> >>position XY with Z above the material/work level
> >>  result as expected
> >>move Z to material/work level
> >>  result not as expected - as the tool approaches the final Z
> >> position
> >> the tool moves an
> amount
> >> toward the final XY position
> >> and cuts into the
> >> material/stock
> >> face mill top of material
> >>   result as expected
> >>
> >> The work around has been to add an intermediate point after the z move
> that
> >> will cause the rounding to fall short of the material/stock
> >> The BIG problem is the customer has many proven/certified programs
> making
> >> parts on this machine. The quality manual requires a full first article
> >> inspection procedure to be performed on the resultant machined part
> after
> >> ANY change in the process. This is not acceptable to the customer.
> >> Customer wants the machine to just perform like it did with the previous
> >> (old) linuxcnc version.
> >> Customer is asking for revision to old version if fix is not able to be
> >> accomplished rather quickly.
> >>
> >> thanks
> >> Stuart
> >>
> >
> --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
> >
> >
> --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
> >
> >
>
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Emc-users mailing list
> 

[Emc-users] Spindle speed signal

[Robert Ellenberg]

Hi All,

Does anyone use a spindle encoder with only position output? In other
words, encoder position linked to  motion.spindle-revs, but no input to
motion.spindle-speed-in?

I ask because I'm working on a tweak to spindle synchronization, and I'd
like to use the spindle speed input as part of the position tracking loop.
However, this would require that pins have a valid signal for threading /
spindle position tracking. If the only-position case is common, then I
would make the use of spindle-speed-in controllable by an IN setting.

Thanks!
Rob
--
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

[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

[Robert Ellenberg]

In the most general case, you're correct that the tool tip motion is a
function of the machine geometry. Putting it more succinctly, the tool tip
position (world space) is a nonlinear function of the joint positions. In
the general case, a linear motion in world space is not necessarily linear
in joint space. This non-linearity has all kinds of consequences for motion
planning:

   - Joint space limits are not prismatic (i.e. constant limits for every
   joint). Therefore, you can't be sure that a linear move is within joint
   space limits just because the end points are.
   - Joint space velocity is not proportional to tool tip velocity, and in
   general will change as a function of position. Therefore the max velocity /
   acceleration is not constant within a motion segment.

The current TP / motion planning architecture is really designed for
linear, orthogonal kinematics. There's been discussion about the necessary
redesign before (see here
<https://github.com/machinekit/machinekit/issues/396>).

So, what we can realistically do in the short term is chip away at the
problem:

   1. Get ABC blending working with a constant effective radius (i.e. some
   fixed conversion from degrees to inches)
   2. Make the effective radius specific to each motion segment, assuming
   each of the ABC axis have a fixed global orientation and origin.

I'm working on (1), and I have a plan for (2).

-Rob

On Sun, Nov 6, 2016 at 1:47 PM Klemen Živkovič <klemen.zivko...@gmail.com>
wrote:

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 

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

.

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.  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  on behalf of
Klemen Zivkovic 
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] Cycle time discussion

[Robert Ellenberg]

The discrepancy is likely because the behavior changed in 2.7. In 2.6 and
older, both G61 modes were identical. In 2.7, we added the exact path vs
exact stop distinction (since the new TP could do it).

On Tue, Oct 18, 2016, 12:15 PM Nicklas Karlsson <
nicklas.karlsso...@gmail.com> wrote:

> There seems to be small disreptancy in manual for at least 2.6:
>   G61 - exact path mode. G61 visits the programmed point exactly, even
> though that means temporarily coming to a complete stop.
>   G61.1 - exact stop mode. Same as G61
>
> G61 do not need to stop although it might happen because otherwise it fail
> to reach exact point. G61.1 come to a complete halt at point.
>
> I say to change the manual would make sense.
>
>
>
> On Tue, 18 Oct 2016 11:27:34 -0400 (EDT)
> "Todd  Zuercher"  wrote:
>
> > Yes, a quick test seems to show that for co-linear points G61 doesn't
> stop but G61.1 does.  Maybe the docs should be adjusted to reflect that.
> >
> > - Original Message -
> > From: "John Thornton" 
> > To: "Enhanced Machine Controller (EMC)"  >
> > Sent: Tuesday, October 18, 2016 10:56:56 AM
> > Subject: Re: [Emc-users] Cycle time discussion
> >
> > Looks like G61.1 stops at every end point and G61 only visits each end
> > point but may stop if needed. Could also be incorrect descriptions of
> > them...
> >
> > JT
> >
> > On 10/18/2016 9:17 AM, Todd Zuercher wrote:
> > > Stupid question, why do we even have a G61.1 mode?  Is it in anyway
> different from plain G61?
> > >
> > > - Original Message -
> > > From: "John Thornton" 
> > > To: "Enhanced Machine Controller (EMC)" <
> emc-users@lists.sourceforge.net>
> > > Sent: Tuesday, October 18, 2016 9:21:29 AM
> > > Subject: Re: [Emc-users] Cycle time discussion
> > >
> > > That depends on you, if you do nothing you get G64
> > > http://linuxcnc.org/docs/2.7/html/gcode/g-code.html#gcode:g64
> > >
> > > If you set G64 P  you get something else
> > > http://linuxcnc.org/docs/2.7/html/gcode/g-code.html#gcode:g64
> > >
> > > If you set G61 or G61.1 you get something different
> > > http://linuxcnc.org/docs/2.7/html/gcode/g-code.html#gcode:g61-g61.1
> > >
> > > JT
> > >
> > > On 10/18/2016 7:48 AM, Erik Friesen wrote:
> > >> I have been watching my vintage 1996 haas, and have begun to notice
> > >> all the non cutting times, pauses, etc.  It really seems that non
> > >> rapid, between rapid, and other slow motions are overlooked time
> > >> costs.  Note the non machining pauses on this DM-1
> > >> http://www.haascnc.com/video.asp?mode=demos=c5-XXw0gLxg
> > >>
> > >> I see this on my machine too, rapids don't blend, so G0Z1 followed by
> > >> G0Z5 will always have a noticeable pause.
> > >>
> > >> How does lcnc handle rapids in this scenario?
> > >>
> > >>
> --
> > >> Check out the vibrant tech community on one of the world's most
> > >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> > >> ___
> > >> Emc-users mailing list
> > >> Emc-users@lists.sourceforge.net
> > >> https://lists.sourceforge.net/lists/listinfo/emc-users
> > >
> > >
> --
> > > Check out the vibrant tech community on one of the world's most
> > > engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> > > ___
> > > Emc-users mailing list
> > > Emc-users@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/emc-users
> > >
> > >
> --
> > > Check out the vibrant tech community on one of the world's most
> > > engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> > > ___
> > > Emc-users mailing list
> > > Emc-users@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/emc-users
> >
> >
> >
> --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
> >
> >
> --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
>
>
> --
> Nicklas Karlsson 
>
>
> 

Re: [Emc-users] calling Todd Z

[Robert Ellenberg]

I'd be happy to merge it into either if there's demand. My recent batch of
changes restored the original behavior of the velocity field in EMC status,
so I don't think there are any other obstacles. One minor concern is that
the extra math slightly increases the CPU time for the servo loop, but I
doubt it will matter on reasonably modern hardware.

On Mon, Jan 11, 2016, 2:25 PM Todd Zuercher <zuerc...@embarqmail.com> wrote:

> Rob,
>
> We've been running this for a little while now and it seems to be working
> well for us.  Is there any plans to move it to the mainstream (Master or
> 2.7)?
>
> - Original Message -
> From: "Robert Ellenberg" <rwe...@gmail.com>
> To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
> Sent: Tuesday, December 1, 2015 12:31:50 PM
> Subject: Re: [Emc-users] calling Todd Z
>
> That's consistent with the changes I made, that "velocity"  from the TP's
> perspective is now along the 6D path (instead of just XYZ).
>
> Maybe we could add fields / Hal pins for different interpretations? It
> wouldn't be too hard to calculate XYZ-only velocity, and report it on a
> separate pin. Or, for backwards compatibility, I could tweak the status
> update code so that motion only reports xyz velocity, even though
> internally it uses xyzuvw.
>
> On Tue, Dec 1, 2015, 12:14 PM Todd Zuercher <zuerc...@embarqmail.com>
> wrote:
>
> > Ok I got to test it again today some, and here is what I've found so far.
> > It looks like the g-code with Z and W are running the same as the only Z
> > g-code.  The same file runs for the same amount of time both ways.
> >
> > However I have noticed that it looks like the velocity display on the
> DRO,
> > is adding the velocity of the W axis to the Z, so that when milling at
> F80,
> > the DRO will show that the velocity was more than 80.  I'm not quite sure
> > how this could be corrected or if it should be.  There are configurations
> > where you may want the W and Z velocities to be additive (such as a knee
> > mill) but that situation might be better served by configuring it more
> like
> > 2 joints serving the Z axis.  I don't think it would be right to just
> > completely ignore the W velocity either, because there are situations
> where
> > the machine may be using only XYW for carving instead of XYZ or XYZW.
> > Maybe some way of only using the most significant velocity of the 2 (Z
> and
> > W) in the velocity calculation, sounds like a recipe for making something
> > simple (at least on the surface) into something very complicated.
> >
> > Again, it is only what is being shown for the velocity on the DRO that I
> > think is wrong, the actual movement of the the machine looks right, and
> the
> > run times for the files seem to confirm that.
> >
> > - Original Message -
> > From: "Robert Ellenberg" <rwe...@gmail.com>
> > To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net
> >
> > Sent: Friday, November 27, 2015 10:56:44 AM
> > Subject: Re: [Emc-users] calling Todd Z
> >
> > I just tweaked naive cam detection to handle uvw axes too. Can you guys
> > give it a spin and see if it makes up the difference?
> >
> > -Rob
> >
> > On Wed, Nov 25, 2015, 4:09 PM sam sokolik <sa...@empirescreen.com>
> wrote:
> >
> > > the thing that is missing with uvy blends it the nieve cam detector
> > > (combining of short line segments..)  so it will run just a bit slower.
> > >
> > > sam
> > >
> > > On 11/25/2015 12:17 PM, Todd Zuercher wrote:
> > > > Just for perspective the current version of 2.7 using XYZW runs the
> > file
> > > below in 10min. 44sec.
> > > >
> > > > - Original Message -
> > > > From: "Todd Zuercher" <zuerc...@embarqmail.com>
> > > > To: "Enhanced Machine Controller (EMC)" <
> > emc-users@lists.sourceforge.net
> > > >
> > > > Sent: Wednesday, November 25, 2015 10:17:03 AM
> > > > Subject: Re: [Emc-users] calling Todd Z
> > > >
> > > > Seems to be working great.  I haven't found a problem XYZ and XYZW
> code
> > > seem to run mostly the same now, but not exactly.  The first file I
> > tested
> > > ran in 7min. 10 sec. using only XYZ code (with the W slaved to Z) and
> the
> > > same file using XYZW code, ran in 7min. 28sec.
> > > >
> > > > - Original Message -
> > > > From: "Robert Ellenberg" <rw

Re: [Emc-users] seasons greetings

[Robert Ellenberg]

Merry Christmas all!

https://youtu.be/qEvQLxwp3-A

On Fri, Dec 25, 2015, 9:09 AM Reggie Crane  wrote:

> Merry Christmas!
>
> On Thu, Dec 24, 2015, 10:34 PM Jim Craig 
> wrote:
>
> > Merry Christmas Gene and everyone else.On Dec 24, 2015 10:17 PM, Gene
> > Heskett  wrote:
> > >
> > > Greetings all;
> > >
> > > Its that time of the year again, and there not a PC bone in my body, so
> > >
> > > Merry Christmas everyone!
> > >
> > > Cheers, Gene Heskett
> > > --
> > > "There are four boxes to be used in defense of liberty:
> > > soap, ballot, jury, and ammo. Please use in that order."
> > > -Ed Howdershelt (Author)
> > > Genes Web page 
> > >
> > >
> >
> --
> > > ___
> > > Emc-users mailing list
> > > Emc-users@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/emc-users
> >
> >
> --
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
> >
>
> --
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] calling Todd Z

[Robert Ellenberg]

That's consistent with the changes I made, that "velocity"  from the TP's
perspective is now along the 6D path (instead of just XYZ).

Maybe we could add fields / Hal pins for different interpretations? It
wouldn't be too hard to calculate XYZ-only velocity, and report it on a
separate pin. Or, for backwards compatibility, I could tweak the status
update code so that motion only reports xyz velocity, even though
internally it uses xyzuvw.

On Tue, Dec 1, 2015, 12:14 PM Todd Zuercher <zuerc...@embarqmail.com> wrote:

> Ok I got to test it again today some, and here is what I've found so far.
> It looks like the g-code with Z and W are running the same as the only Z
> g-code.  The same file runs for the same amount of time both ways.
>
> However I have noticed that it looks like the velocity display on the DRO,
> is adding the velocity of the W axis to the Z, so that when milling at F80,
> the DRO will show that the velocity was more than 80.  I'm not quite sure
> how this could be corrected or if it should be.  There are configurations
> where you may want the W and Z velocities to be additive (such as a knee
> mill) but that situation might be better served by configuring it more like
> 2 joints serving the Z axis.  I don't think it would be right to just
> completely ignore the W velocity either, because there are situations where
> the machine may be using only XYW for carving instead of XYZ or XYZW.
> Maybe some way of only using the most significant velocity of the 2 (Z and
> W) in the velocity calculation, sounds like a recipe for making something
> simple (at least on the surface) into something very complicated.
>
> Again, it is only what is being shown for the velocity on the DRO that I
> think is wrong, the actual movement of the the machine looks right, and the
> run times for the files seem to confirm that.
>
> - Original Message -
> From: "Robert Ellenberg" <rwe...@gmail.com>
> To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
> Sent: Friday, November 27, 2015 10:56:44 AM
> Subject: Re: [Emc-users] calling Todd Z
>
> I just tweaked naive cam detection to handle uvw axes too. Can you guys
> give it a spin and see if it makes up the difference?
>
> -Rob
>
> On Wed, Nov 25, 2015, 4:09 PM sam sokolik <sa...@empirescreen.com> wrote:
>
> > the thing that is missing with uvy blends it the nieve cam detector
> > (combining of short line segments..)  so it will run just a bit slower.
> >
> > sam
> >
> > On 11/25/2015 12:17 PM, Todd Zuercher wrote:
> > > Just for perspective the current version of 2.7 using XYZW runs the
> file
> > below in 10min. 44sec.
> > >
> > > - Original Message -
> > > From: "Todd Zuercher" <zuerc...@embarqmail.com>
> > > To: "Enhanced Machine Controller (EMC)" <
> emc-users@lists.sourceforge.net
> > >
> > > Sent: Wednesday, November 25, 2015 10:17:03 AM
> > > Subject: Re: [Emc-users] calling Todd Z
> > >
> > > Seems to be working great.  I haven't found a problem XYZ and XYZW code
> > seem to run mostly the same now, but not exactly.  The first file I
> tested
> > ran in 7min. 10 sec. using only XYZ code (with the W slaved to Z) and the
> > same file using XYZW code, ran in 7min. 28sec.
> > >
> > > - Original Message -
> > > From: "Robert Ellenberg" <rwe...@gmail.com>
> > > To: "Enhanced Machine Controller (EMC)" <
> emc-users@lists.sourceforge.net
> > >
> > > Sent: Tuesday, November 24, 2015 11:39:38 PM
> > > Subject: Re: [Emc-users] calling Todd Z
> > >
> > > Ok, i just pushed a fix for that build error, and now it seems to
> compile
> > > and run on my RTAI VM.  Also, I pushed the branch to the main linuxcnc
> > > repository for the buildbot to chew on.
> > >
> > > -Rob
> > >
> > > On Tue, Nov 24, 2015 at 4:16 PM, Robert Ellenberg <rwe...@gmail.com>
> > wrote:
> > >
> > >> Todd,
> > >>
> > >> I'll troubleshoot the build tonight, it looks like a symbol is missing
> > in
> > >> the RT build that's available in the sim build.
> > >>
> > >> Rob
> > >>
> > >> On Tue, Nov 24, 2015, 4:09 PM Todd Zuercher <zuerc...@embarqmail.com>
> > >> wrote:
> > >>
> > >>> I think I forgot to do the sudo make setuid.
> > >>> did that now, and this is what it spits out.
> > >>>
> > >>> LINUXCNC - 2.7.2
> > >>> M

Re: [Emc-users] calling Todd Z

[Robert Ellenberg]

I just tweaked naive cam detection to handle uvw axes too. Can you guys
give it a spin and see if it makes up the difference?

-Rob

On Wed, Nov 25, 2015, 4:09 PM sam sokolik <sa...@empirescreen.com> wrote:

> the thing that is missing with uvy blends it the nieve cam detector
> (combining of short line segments..)  so it will run just a bit slower.
>
> sam
>
> On 11/25/2015 12:17 PM, Todd Zuercher wrote:
> > Just for perspective the current version of 2.7 using XYZW runs the file
> below in 10min. 44sec.
> >
> > - Original Message -
> > From: "Todd Zuercher" <zuerc...@embarqmail.com>
> > To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net
> >
> > Sent: Wednesday, November 25, 2015 10:17:03 AM
> > Subject: Re: [Emc-users] calling Todd Z
> >
> > Seems to be working great.  I haven't found a problem XYZ and XYZW code
> seem to run mostly the same now, but not exactly.  The first file I tested
> ran in 7min. 10 sec. using only XYZ code (with the W slaved to Z) and the
> same file using XYZW code, ran in 7min. 28sec.
> >
> > - Original Message -
> > From: "Robert Ellenberg" <rwe...@gmail.com>
> > To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net
> >
> > Sent: Tuesday, November 24, 2015 11:39:38 PM
> > Subject: Re: [Emc-users] calling Todd Z
> >
> > Ok, i just pushed a fix for that build error, and now it seems to compile
> > and run on my RTAI VM.  Also, I pushed the branch to the main linuxcnc
> > repository for the buildbot to chew on.
> >
> > -Rob
> >
> > On Tue, Nov 24, 2015 at 4:16 PM, Robert Ellenberg <rwe...@gmail.com>
> wrote:
> >
> >> Todd,
> >>
> >> I'll troubleshoot the build tonight, it looks like a symbol is missing
> in
> >> the RT build that's available in the sim build.
> >>
> >> Rob
> >>
> >> On Tue, Nov 24, 2015, 4:09 PM Todd Zuercher <zuerc...@embarqmail.com>
> >> wrote:
> >>
> >>> I think I forgot to do the sudo make setuid.
> >>> did that now, and this is what it spits out.
> >>>
> >>> LINUXCNC - 2.7.2
> >>> Machine configuration directory is
> >>> '/home/digital4/linuxcnc/configs/Digital_4_ZZ'
> >>> Machine configuration file is 'Digital_4w.ini'
> >>> Starting LinuxCNC...
> >>> insmod: can't read '/home/digital4/linuxcnc-uvw/rtlib/rtapi.ko': No
> such
> >>> file or directory
> >>> Realtime system did not load
> >>> Shutting down and cleaning up LinuxCNC...
> >>> Running HAL shutdown script
> >>> /home/digital4/linuxcnc-uvw/bin/linuxcnc_module_helper: Invalid usage
> >>> with args: remove hal_lib
> >>>
> >>> Usage: /home/digital4/linuxcnc-uvw/bin/linuxcnc_module_helper insert
> >>> /path/to/module.ext [param1=value1 ...]
> >>>
> >>> where module is one of:
> >>> rtai_math
> >>> rtai_sem
> >>> rtai_shm
> >>> rtai_fifos
> >>> rtai_up
> >>> rtai_lxrt
> >>> rtai_hal
> >>> rtai_sched
> >>> rtai_smi
> >>> rtai
> >>> rt_mem_mgr
> >>> adeos
> >>>
> >>> the path starts with one of:
> >>> /lib/modules
> >>> /usr/realtime-2.6.32-122-rtai
> >>>
> >>> and the extension is one of:
> >>> .ko
> >>>
> >>> or the module is in the directory /home/digital4/linuxcnc-uvw/rtlib
> >>>
> >>> OR
> >>>
> >>> /home/digital4/linuxcnc-uvw/bin/linuxcnc_module_helper remove module
> >>>
> >>> where module is one of the modules listed above.
> >>>
> >>> /home/digital4/linuxcnc-uvw/bin/linuxcnc_module_helper: Invalid usage
> >>> with args: remove rtapi
> >>>
> >>> Usage: /home/digital4/linuxcnc-uvw/bin/linuxcnc_module_helper insert
> >>> /path/to/module.ext [param1=value1 ...]
> >>>
> >>> where module is one of:
> >>> rtai_math
> >>> rtai_sem
> >>> rtai_shm
> >>> rtai_fifos
> >>> rtai_up
> >>> rtai_lxrt
> >>> rtai_hal
> >>> rtai_sched
> >>> rtai_smi
> >>> 

Re: [Emc-users] calling Todd Z

[Robert Ellenberg]

Todd,

I'll troubleshoot the build tonight, it looks like a symbol is missing in
the RT build that's available in the sim build.

Rob

On Tue, Nov 24, 2015, 4:09 PM Todd Zuercher  wrote:

> I think I forgot to do the sudo make setuid.
> did that now, and this is what it spits out.
>
> LINUXCNC - 2.7.2
> Machine configuration directory is
> '/home/digital4/linuxcnc/configs/Digital_4_ZZ'
> Machine configuration file is 'Digital_4w.ini'
> Starting LinuxCNC...
> insmod: can't read '/home/digital4/linuxcnc-uvw/rtlib/rtapi.ko': No such
> file or directory
> Realtime system did not load
> Shutting down and cleaning up LinuxCNC...
> Running HAL shutdown script
> /home/digital4/linuxcnc-uvw/bin/linuxcnc_module_helper: Invalid usage with
> args: remove hal_lib
>
> Usage: /home/digital4/linuxcnc-uvw/bin/linuxcnc_module_helper insert
> /path/to/module.ext [param1=value1 ...]
>
> where module is one of:
> rtai_math
> rtai_sem
> rtai_shm
> rtai_fifos
> rtai_up
> rtai_lxrt
> rtai_hal
> rtai_sched
> rtai_smi
> rtai
> rt_mem_mgr
> adeos
>
> the path starts with one of:
> /lib/modules
> /usr/realtime-2.6.32-122-rtai
>
> and the extension is one of:
> .ko
>
> or the module is in the directory /home/digital4/linuxcnc-uvw/rtlib
>
> OR
>
> /home/digital4/linuxcnc-uvw/bin/linuxcnc_module_helper remove module
>
> where module is one of the modules listed above.
>
> /home/digital4/linuxcnc-uvw/bin/linuxcnc_module_helper: Invalid usage with
> args: remove rtapi
>
> Usage: /home/digital4/linuxcnc-uvw/bin/linuxcnc_module_helper insert
> /path/to/module.ext [param1=value1 ...]
>
> where module is one of:
> rtai_math
> rtai_sem
> rtai_shm
> rtai_fifos
> rtai_up
> rtai_lxrt
> rtai_hal
> rtai_sched
> rtai_smi
> rtai
> rt_mem_mgr
> adeos
>
> the path starts with one of:
> /lib/modules
> /usr/realtime-2.6.32-122-rtai
>
> and the extension is one of:
> .ko
>
> or the module is in the directory /home/digital4/linuxcnc-uvw/rtlib
>
> OR
>
> /home/digital4/linuxcnc-uvw/bin/linuxcnc_module_helper remove module
>
> where module is one of the modules listed above.
>
> LinuxCNC terminated with an error.  You can find more information in the
> log:
> /home/digital4/linuxcnc_debug.txt
> and
> /home/digital4/linuxcnc_print.txt
> as well as in the output of the shell command 'dmesg' and in the terminal
>
>
> --
> Go from Idea to Many App Stores Faster with Intel(R) XDK
> Give your users amazing mobile app experiences with Intel(R) XDK.
> Use one codebase in this all-in-one HTML5 development environment.
> Design, debug & build mobile apps & 2D/3D high-impact games for multiple
> OSs.
> http://pubads.g.doubleclick.net/gampad/clk?id=254741551=/4140
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
--
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] calling Todd Z

[Robert Ellenberg]

Ok, i just pushed a fix for that build error, and now it seems to compile
and run on my RTAI VM.  Also, I pushed the branch to the main linuxcnc
repository for the buildbot to chew on.

-Rob

On Tue, Nov 24, 2015 at 4:16 PM, Robert Ellenberg <rwe...@gmail.com> wrote:

> Todd,
>
> I'll troubleshoot the build tonight, it looks like a symbol is missing in
> the RT build that's available in the sim build.
>
> Rob
>
> On Tue, Nov 24, 2015, 4:09 PM Todd Zuercher <zuerc...@embarqmail.com>
> wrote:
>
>> I think I forgot to do the sudo make setuid.
>> did that now, and this is what it spits out.
>>
>> LINUXCNC - 2.7.2
>> Machine configuration directory is
>> '/home/digital4/linuxcnc/configs/Digital_4_ZZ'
>> Machine configuration file is 'Digital_4w.ini'
>> Starting LinuxCNC...
>> insmod: can't read '/home/digital4/linuxcnc-uvw/rtlib/rtapi.ko': No such
>> file or directory
>> Realtime system did not load
>> Shutting down and cleaning up LinuxCNC...
>> Running HAL shutdown script
>> /home/digital4/linuxcnc-uvw/bin/linuxcnc_module_helper: Invalid usage
>> with args: remove hal_lib
>>
>> Usage: /home/digital4/linuxcnc-uvw/bin/linuxcnc_module_helper insert
>> /path/to/module.ext [param1=value1 ...]
>>
>> where module is one of:
>> rtai_math
>> rtai_sem
>> rtai_shm
>> rtai_fifos
>> rtai_up
>> rtai_lxrt
>> rtai_hal
>> rtai_sched
>> rtai_smi
>> rtai
>> rt_mem_mgr
>> adeos
>>
>> the path starts with one of:
>> /lib/modules
>> /usr/realtime-2.6.32-122-rtai
>>
>> and the extension is one of:
>> .ko
>>
>> or the module is in the directory /home/digital4/linuxcnc-uvw/rtlib
>>
>> OR
>>
>> /home/digital4/linuxcnc-uvw/bin/linuxcnc_module_helper remove module
>>
>> where module is one of the modules listed above.
>>
>> /home/digital4/linuxcnc-uvw/bin/linuxcnc_module_helper: Invalid usage
>> with args: remove rtapi
>>
>> Usage: /home/digital4/linuxcnc-uvw/bin/linuxcnc_module_helper insert
>> /path/to/module.ext [param1=value1 ...]
>>
>> where module is one of:
>> rtai_math
>> rtai_sem
>> rtai_shm
>> rtai_fifos
>> rtai_up
>> rtai_lxrt
>> rtai_hal
>> rtai_sched
>> rtai_smi
>> rtai
>> rt_mem_mgr
>> adeos
>>
>> the path starts with one of:
>> /lib/modules
>> /usr/realtime-2.6.32-122-rtai
>>
>> and the extension is one of:
>> .ko
>>
>> or the module is in the directory /home/digital4/linuxcnc-uvw/rtlib
>>
>> OR
>>
>> /home/digital4/linuxcnc-uvw/bin/linuxcnc_module_helper remove module
>>
>> where module is one of the modules listed above.
>>
>> LinuxCNC terminated with an error.  You can find more information in the
>> log:
>> /home/digital4/linuxcnc_debug.txt
>> and
>> /home/digital4/linuxcnc_print.txt
>> as well as in the output of the shell command 'dmesg' and in the terminal
>>
>>
>> --
>> Go from Idea to Many App Stores Faster with Intel(R) XDK
>> Give your users amazing mobile app experiences with Intel(R) XDK.
>> Use one codebase in this all-in-one HTML5 development environment.
>> Design, debug & build mobile apps & 2D/3D high-impact games for multiple
>> OSs.
>> http://pubads.g.doubleclick.net/gampad/clk?id=254741551=/4140
>> ___
>> Emc-users mailing list
>> Emc-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-users
>>
>
--
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551=/4140
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Turning digital outputs on G-code move without slowing down

[Robert Ellenberg]

It just means that for specific moves that involve ABC axes, the planner
will fall back to parabolic blends (i.e. 2.6-style blending). This means
that continuous contouring using the A axis will be slower than the
equivalent 3-axis path, if the program has a lot of short segments. In your
case, the only effect would be a slowdown at the "indexing" moves. The rest
of the XYZ-only moves will run normally.

Rob

On Thu, Nov 12, 2015, 11:31 AM Viesturs Lācis <viesturs.la...@gmail.com>
wrote:

> 2015-11-11 14:51 GMT+02:00 Robert Ellenberg <rwe...@gmail.com>:
> > Currently the TP does not support arc blends between rotary axis moves
>
> Rob, are you saying that this code would not be supported?
>
> G01X1.279Z14.031
> X1.544Z13.921
> X1.720Z13.834
> X1.897Z13.735
> X2.073Z13.622
> X2.250Z13.496
> X2.426Z13.352
> X2.470Z13.313
> X2.492Z13.298
> X2.603Z13.292
> X2.691Z13.267
> X2.779Z13.218
> X2.823Z13.180
> X2.867Z13.129
> X2.911Z13.051
> X2.933Z12.983
> X2.944Z12.906
> X2.980Z12.502
> X3.044Z12.495
> X4.367
> A-0.079
> X3.044
> X2.980Z12.502
> X2.939Z12.954
> X2.933Z12.983
> X2.911Z13.051
> X2.867Z13.129
> X2.823Z13.180
> X2.779Z13.218
> X2.691Z13.267
> X2.603Z13.292
>
> It has linear moves in XZ plane with small indexing moves on A
> inbetween. How does the new TP handle such code?
>
> Viesturs
>
>
> --
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Turning digital outputs on G-code move without slowing down

[Robert Ellenberg]

Hi Marius,

The problem is not the digital IO, but the A axis. Currently the TP does
not support arc blends between rotary axis moves, so it falls back to
parabolic blends (which can be slower for short segments).

Rob

On Wed, Nov 11, 2015, 7:31 AM Marius Alksnys 
wrote:

> I want to control two digital outputs while in motion without slow-down.
> Now I use G1 with A axis. Neither Arc Blend TP settings in ini nor M62,
> 63, 64, 65 seems to help - I get a slowdown at the switching point.
>
>
>
> --
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] 2.7.0, new trajectory planner, lost it's perfect pitch

[Robert Ellenberg]

Thanks Jeff, I loaded it up in a 4-axis sim config. I think my initial idea
is wrong about ARC_BLEND_RAMP_FREQ, since all of the blending happens
between 4 axes (parabolic blends only).

Just for fun, here's both clips together:

http://www.youtubedoubler.com/?video1=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DJKNieuI6Hmo=0=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DS0re79zEX5A=11=rellenberg

It seems like it's running faster in your 2.7 video. Has the configuration
/ scale changed between those videos? It might sound better if it runs at
the same speed. For reference, on my test config, the program takes about
36 seconds on both 2.6 and 2.7.

Rob

On Mon, Oct 19, 2015 at 9:39 PM, Jeff Epler <jep...@unpythonic.net> wrote:

> On Mon, Oct 19, 2015 at 11:30:14PM +0000, Robert Ellenberg wrote:
> > would you mind sharing the g-code so I can
> > take a look at the slow spots?
>
> A version of this program is in the sample nc_files as "daisy.ngc".
>
> It needs to be modified to run on a 3-axis machine, and only "sounds
> good" on a high-accel stepper machine with properly configured scales in
> the gcode.
>
> (set XYZA axis scales)
> O100 call [6400] [6400] [8000] [80]
>
> Jeff
>
>
> --
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Question about G2/G3 where Z and P are used

[Robert Ellenberg]

Hi Gene,

That's correct. The P word controls how many turns, independent of the z
height.

Rob


On Mon, Oct 19, 2015, 10:29 AM Gene Heskett  wrote:

Greetings all;

Can I assume that when a Z# and a P# are used in a G2 or G3 move, that
the Z descent per full turn is:

Z / P

So that depth Z is accomplished in P full circles?

The docs

only sort of say that, as I read them.

I'll be boring a hole all the way through the center of each finger, but
the last time, a 1/8" tool simply plunged in with a couple flute
cleaning retractions, did not bore a big enough hole for a #8 screws
clearance and I had to enlarge it by hand, and I'd like to bore a hole
that will just clear the tips of the screws threads by doing a circular
descent.  At a low enough rate of descent per turn that I don't have to
dig up the jig very much just to make sure its fully bored to diameter
at the bottom face of the board.

Thanks all;

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] 2.7.0, new trajectory planner, lost it's perfect pitch

[Robert Ellenberg]

Tom, have you tried playing with the ARC_BLEND_RAMP_FREQ parameter in your
ini file? Increasing it from the default value of 20Hz up to 100Hz or even
1000Hz will make the trajectory planner more aggressive on short segments,
at the expense of more acceleration ripple for programs with lots of short
lines. If that doesn't fix it, would you mind sharing the g-code so I can
take a look at the slow spots?

Thanks,
Rob

On Sat, Oct 17, 2015, 5:48 PM Jerry Scharf  wrote:

> I'm hearing you. :)
>
> Sounds like the new planner has a lower acceleration rates so you don't get
> the good attack on pitch that sounds more musical. It's like using a slow
> slide whistle or trombone.
>
> Maybe increasing the acceleration rates might fix this critical issue.
>
> jerry
>
> On Sat, Oct 17, 2015 at 2:11 PM, Tom Easterday  wrote:
>
> > I’m just sayin’...
> >
> > New:
> > https://youtu.be/JKNieuI6Hmo
> >
> > Old:
> > https://youtu.be/S0re79zEX5A
> >
> > :-)
> > -Tom
> >
> > ps: Here is You Are My Sunshine.  I don’t have it playing on the 2.6 but
> > definitely sounded better before:  https://youtu.be/e1wu2cMpmMY <
> > https://www.youtube.com/upload>
> >
> >
> --
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
> >
>
>
>
> --
> Jerry Scharf
> FINsix IT
> 650.285.6361 w
> 650.279.7017 m
>
> --
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Path blending

[Robert Ellenberg]

Depending on your machine's acceleration, and the feed you requested, that
could be correct default behavior. The default blend tolerance is
unlimited. Given the speed limitations the TP used to have, it may not have
been able to go fast enough to need a big blend like that, so you might not
have seen it before. Does it still happen at lower feeds?

Another possible cause is a large maximum feed override, which causes the
TP to take larger blends. For example, a maximum feed override of 200%
means that at any time, the TP is prepared to go 2x your requested feed,
and doing so safely means a larger corner radius, even if your requested
feed isn't that fast.

In general, I would always recommend using an explicit tolerance for
blending.

Can you share a code snippet that leads to this behavior (also a config
file so I can see your max acceleration / velocity)?

Rob

On Mon, Oct 19, 2015, 7:33 PM Gene Heskett  wrote:

> Greetings all;
>
> I was just forced to add a G64 P0.001 to my code for making the screw
> shank, a circular cut just deep enough to absorb the screw head, topped
> by a square cutout with 1/16" radius corners as left by a 1/8" mill run
> in a square pattern.  Without it, that square pocket was turned into a 1
> corner pointed circle!
>
> That sure seems like way too aggressive path blending to me.  I also
> noted that turning the alpha-blend checkbox on and off, had zero effect
> on the cut result. The initial white backplot trace was perfect, but not
> the wooden result when the code was executed, it was hugely, completely
> unusably bad.
>
> This is 2.7.0, updated Saturday IIRC.
>
> Is that the expected result?
>
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> Genes Web page 
>
>
> --
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Path blending

[Robert Ellenberg]

Hi Gene,

I just set up a sim config with the same axis vel / accel limits, and ran
your code at 200% feed override in G64 P0:

http://imagebin.ca/v/2JdzAY0jhjp4
http://imagebin.ca/v/2JdylG3HDyLx

It looks like the culprit is a combination of the 200% maximum feed
override and the comparatively low maximum acceleration of your X / Y
axes.  You can see in the halscope plot that the peak acceleration is about
6.8 in / sec^2, which is ~86% of your maximum axis acceleration of 7.8 in /
sec^2.  The trajectory planner is designed only to use about that much of
the maximum acceleration for cornering, so that there is some left over to
accelerate / decelerate along the path.

In your case, you can do a few things to fix it:

   1. Add a blend tolerance (consider an explicit Q < P, something like G64
   P0.002 Q0.001)
   2. Decrease maximum feed override
   3. Increase axis max accelerations
   4. Add fillets on your corners and use a smaller mill

As you've already found, (1) is probably the best solution, especially
since you're doing hand-coded programs.

-Rob

On Mon, Oct 19, 2015 at 8:16 PM, Gene Heskett <ghesk...@wdtv.com> wrote:

> On Monday 19 October 2015 19:48:31 Robert Ellenberg wrote:
>
> > Depending on your machine's acceleration, and the feed you requested,
> > that could be correct default behavior. The default blend tolerance is
> > unlimited. Given the speed limitations the TP used to have, it may not
> > have been able to go fast enough to need a big blend like that, so you
> > might not have seen it before. Does it still happen at lower feeds?
> >
> I didn't notice any such effect when a cousin of that code was running on
> my toy mill about a year ago.
>
> > Another possible cause is a large maximum feed override, which causes
> > the TP to take larger blends. For example, a maximum feed override of
> > 200% means that at any time, the TP is prepared to go 2x your
> > requested feed, and doing so safely means a larger corner radius, even
> > if your requested feed isn't that fast.
> >
> Hummm, my feed override is larger than any axis, Z in particular, can
> move at.  These are things I an still "fine tuning" as I bring this
> machine online to make parts.
>
> Recommendations?
>
> > In general, I would always recommend using an explicit tolerance for
> > blending.
> >
> > Can you share a code snippet that leads to this behavior (also a
> > config file so I can see your max acceleration / velocity)?
>
> Finger-bores.ngc attached. Remove the G64 line to see it in whats
> supposed to be a square cutout for a decorative ebony button.
>
> And GO704fast.ini is attached also,
>
> Thanks for looking, Rob, its appreciated.
>
> > Rob
> >
> > On Mon, Oct 19, 2015, 7:33 PM Gene Heskett <ghesk...@wdtv.com> wrote:
> > > Greetings all;
> > >
> > > I was just forced to add a G64 P0.001 to my code for making the
> > > screw shank, a circular cut just deep enough to absorb the screw
> > > head, topped by a square cutout with 1/16" radius corners as left by
> > > a 1/8" mill run in a square pattern.  Without it, that square pocket
> > > was turned into a 1 corner pointed circle!
> > >
> > > That sure seems like way too aggressive path blending to me.  I also
> > > noted that turning the alpha-blend checkbox on and off, had zero
> > > effect on the cut result. The initial white backplot trace was
> > > perfect, but not the wooden result when the code was executed, it
> > > was hugely, completely unusably bad.
> > >
> > > This is 2.7.0, updated Saturday IIRC.
> > >
> > > Is that the expected result?
>
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> Genes Web page <http://geneslinuxbox.net:6309/gene>
>
>
> --
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
>
--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Before i go bonkers: M98, M99

[Robert Ellenberg]

Sorry folks, it looks like I managed to butt-dial an email during my
commute this morning. Crisis averted :)

Rob
On Jul 29, 2015 11:25, Gene Heskett ghesk...@wdtv.com wrote:

 On Wednesday 29 July 2015 10:25:39 Pete Matos wrote:

  Hehehe.  What?
 
 
  Pete
 
  On Wednesday, July 29, 2015, Bertho Stultiens ber...@vagrearg.org
 wrote:
   On 07/29/2015 01:07 PM, Robert Ellenberg wrote:
Pompeo Kirkman kiosk I kid in ipm Kiki Kokomo Kiki I ijkukKokomo
Kiki Kik Kiki the I just just my Jim kipm I kill Kokomo Kiki kiosk
imp the MIkkujkujk hiking j imitation I K my I I'm K kk I am KikiI
I I ikkjiiujklukk Kiki nonono iok Kiki just as I joined Kids I
my K my

 Catnip spilled on the keyboard?

   Kiki
  
I'm knickknacks Kiki ikkji
  
   Calling section five, prepare for incoming.
   Make room for emergency transport.
  
  
   --
   Greetings Bertho
  
   (disclaimers are disclaimed)
  
  
   
  -- ___
   Emc-users mailing list
   Emc-users@lists.sourceforge.net javascript:;
   https://lists.sourceforge.net/lists/listinfo/emc-users


 Cheers, Gene Heskett
 --
 There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order.
 -Ed Howdershelt (Author)
 Genes Web page http://geneslinuxbox.net:6309/gene


 --
 ___
 Emc-users mailing list
 Emc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-users

--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Before i go bonkers: M98, M99

[Robert Ellenberg]

Pompeo Kirkman kiosk I kid in ipm Kiki Kokomo Kiki I ijkukKokomo Kiki Kik
Kiki the I just just my Jim kipm I kill Kokomo Kiki kiosk imp the
MIkkujkujk hiking j imitation I K my I I'm K kk I am KikiI I I
ikkjiiujklukk Kiki nonono iok Kiki just as I joined Kids I my K my Kiki
I'm knickknacks Kiki ikkji
--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Possible Trajectory Problem

[Robert Ellenberg]

Hi Matt,

As Sam ant Todd mentioned, the large deviations from the path are expected
given your settings. Here's why the deviation seems to be different in
different parts of your code:

   1. The inner cuts start and stop at the lower left corner, and
   transitions from feed to rapid are not blended, so it has to stop at this
   point.
   2. The inner cuts are done with 4 lines, which the trajectory planner
   will blend into circular arcs as much as needed to reach your maximum speed.
   3. This deviation doesn't happen in the outer cuts, because each corner
   has a small arc connecting the lines already, so no blending is needed.

-Rob


On Thu, Aug 21, 2014 at 8:33 AM, Todd Zuercher zuerc...@embarqmail.com
wrote:

 With not tolerance for the g64 setting, Linuxcnc is going to go as fast as
 it can and still touch every line segment.  So with your machines
 acceleration settings, what is the smallest arc radius that it can make at
 400 ipm?  That is how much each corner will be rounded.

 - Original Message -
 From: Matt Shaver m...@mattshaver.com
 To: Emc-users@lists.sourceforge.net
 Sent: Wednesday, August 20, 2014 10:54:27 PM
 Subject: [Emc-users] Possible Trajectory Problem

 I've experienced some behavior that might be a bug. The relevant
 information can be found at:

 http://www.mattshaver.com/gas/

 Running the CAP.TAP program results in the motion depicted in
 Screenshot.png. Adding a G61 or G64 P0.005 to the program produces a
 trajectory that closely follows the expected path. Significantly
 slowing the feedrate also produces normal results.

 Is this a bug, or is it simply default G64 behavior on a machine
 configured as this one is?

 Any comments would be welcome!

 Thanks,
 Matt


 --
 Slashdot TV.
 Video for Nerds.  Stuff that matters.
 http://tv.slashdot.org/
 ___
 Emc-users mailing list
 Emc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-users


 --
 Slashdot TV.
 Video for Nerds.  Stuff that matters.
 http://tv.slashdot.org/
 ___
 Emc-users mailing list
 Emc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-users

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] New Tajectory Planner

[Robert Ellenberg]

Hi Todd,

Sam and I fixed the max velocity issues that turned up a few weeks ago, and
I haven't seen any issues with it since then.  As far as I'm concerned,
it's ready to merge into master. I haven't done much with blending over the
ABC / UVW axes since I last looked at it. The method I had planned to use
would work well for line-line blends, but not blends involving arcs. I have
another idea of how to handle these cases, but it will take some time to
fully implement. It makes sense to me to merge now and add any improvements
as a separate update.

Does anyone object to merging into master now?

-Rob

On Tue, May 13, 2014 at 2:48 PM, Todd Zuercher zuerc...@embarqmail.comwrote:

 Does any one here know when (or if) the new circular-arc-blending
 trajectory planner will make it into master?

 I was also curious about it's current status? If Rob is listening. Has he
 made any progress including other axis other than XYZ into it, specifically
 UVW?

 Thanks again Rob and everyone else who has worked (/is working) on this. I
 think this is one of the biggest improvements to Linuxcnc (EMC2) since I've
 started using it.

 --

 

 Todd Zuercher
 mailto:zuerc...@embarqmail.com

 

 --
 Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
 Instantly run your Selenium tests across 300+ browser/OS combos.
 Get unparalleled scalability from the best Selenium testing platform
 available
 Simple to use. Nothing to install. Get started now for free.
 http://p.sf.net/sfu/SauceLabs
 ___
 Emc-users mailing list
 Emc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-users

--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free.
http://p.sf.net/sfu/SauceLabs
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Jerky motion

[Robert Ellenberg]

Hi Rod,

This is actually a good example of why G64 is a bit confusing at first.
Since you haven't specified a Q word, G64 with a P tolerance by default
uses the same tolerance for the  naive cam detector. What that means is
that your command here:

G64 P0.05

Is interpreted by LinuxCNC to mean this:

G64 P0.05 Q0.05

I'd be willing to bet that if you used this setting instead, it would
revert to the ugly behavior:

G64 P0.05 Q0.0

-Rob




On Fri, Apr 11, 2014 at 4:19 PM, Rod Fitzsimmons Frey rodf...@gmail.comwrote:

 G0 P0.05 worked like a charm!  Thanks Viesturs. I'll have to go read the
 code to understand the behaviour.


 On Fri, Apr 11, 2014 at 4:16 PM, Rod Fitzsimmons Frey rodf...@gmail.com
 wrote:

  Perhaps I'm confused about G64?  From the docs:
 
  G64 is just blending and the naive cam detector is not enabled.  G64 and
  G64 P0 tell the planner to sacrifice path following accuracy in order to
  keep the feed rate up.  ...  G64 P0 has the same effect as G64 alone
  (above), which is necessary for backward compatibility for old G Code
  programs.
 
  I'll try the small value for G64 instead.  I'm not concerned about
  accuracy in this application - .005 would be fine.
 
  I'll definitely have a look at the new trajectory planner too!
 
 
  On Fri, Apr 11, 2014 at 3:28 PM, Viesturs Lācis 
 viesturs.la...@gmail.comwrote:
 
  2014-04-11 22:15 GMT+03:00 Rod Fitzsimmons Frey rodf...@gmail.com:
 
   I've set G64 P0, which I think should eliminate motion mode concerns?
 
 
  P0 means that max allowed deviation from defined path in order to
 maintain
  velocity is equal to as much as total zero, so it really eliminates not
  only concerns about motion mode, but also any options to try to maintain
  the velocity. Try increasing it to something like 0,02 and see, if it is
  better.
 
  I would say that this particular case is a perfect guinea pig for the
 new
  trajectory planner :)
 
  Viesturs
 
 
 --
  Put Bad Developers to Shame
  Dominate Development with Jenkins Continuous Integration
  Continuously Automate Build, Test  Deployment
  Start a new project now. Try Jenkins in the cloud.
  http://p.sf.net/sfu/13600_Cloudbees
  ___
  Emc-users mailing list
  Emc-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/emc-users
 
 
 

 --
 Put Bad Developers to Shame
 Dominate Development with Jenkins Continuous Integration
 Continuously Automate Build, Test  Deployment
 Start a new project now. Try Jenkins in the cloud.
 http://p.sf.net/sfu/13600_Cloudbees
 ___
 Emc-users mailing list
 Emc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-users

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test  Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Poor CV

[Robert Ellenberg]

Terry, that's a good idea. I suspect G41/G42 won't affect much since the
offsets are applied before the path is sent to the motion module, but it
would be nice to be sure.  Do you have a program handy that use G41/42
extensively? If so, I'd be happy to add it to the tests I run.

-Rob



On Mon, Mar 3, 2014 at 7:54 PM, TERRY Christophersen tcninj...@gmail.comwrote:

 Have you tried the new tp with g41/g42? Im sure it wont matter but just in
 case...

 Terry
 One thing I have noticed - with the new TP - the path reaches commanded
 speed.  mach gets close but is usually a few percent under.

 Take this program steve posted a while back.  (
 http://electronicsam.com/images/KandT/testing/steve.ngc )

 New TP
 http://imagebin.org/296859
 If you calculate it out - it is about 3600mm/min.  that is the commanded
 velocity  (following path within .1mm aprox .004)   it actually
 finishes a whole .5 seconds faster ;)

 With Mach
 http://imagebin.org/296858
 it peaks at about 3300mm/min.

 sam  (having too much fun...)



 On 2/20/2014 10:37 AM, sam sokolik wrote:
  Steve!
 
  Here is your sample of gcode running the newest TP
 
  Original TP
  http://imagebin.org/294551  (limit of the 1 segment look-ahead)
 
  New TP (which does arc-arc , Line-arc and line-line look-ahead.)
  http://imagebin.org/294550
 
  Robs hard work is awesome! (and it keeps improving)
 
  sam
 
 
  On 04/07/2013 05:28 PM, Steve Blackmore wrote:
  On Sun, 7 Apr 2013 10:21:11 -0500, you wrote:
 
  On Sun, Apr 07, 2013 at 10:13:11AM +0100, Steve Blackmore wrote:
  CV in LinuxCNC still does not work well. Have a look at this
 
  http://youtu.be/ph_IVXg1C9Y
  Please share your gcode and your full config directory.
  Hi Chris - Here's part of the code - it's obvious early on without all
  of it. I'll post the config tomorrow - machine is at work.
 
  BTW - Changing N190 to
 
  N190 G64 P0.5
 
  and it runs better, but that's far too much deviation.
 
  This was first reported on 26th July 2011 in a post
  trying to understand EMC's operation
  Have a read of that thread for way more information. Daniel Rogge
  concurs in his tests posted on 29th.
 
  I've re posted as this is still occurring since V2.4 !
 
  N100 G0 G21 G17 G90 G40 G49 G80
  N110 G91.1
  N120 G1 Z20.000 F3600.0
  N130 T1 M06
  N140 (End Mill {6 mm})
  N150 G43H1 Z20.000
  N160 S12000 M03
  N170(Toolpath:- Profile 1)
  N180()
  N190 G64
  N200 G1 X0.000 Y0.000 F3600
  N210 G0 X-1.974 Y8.147 Z6.000
  N220 G1 X-1.974 Y8.147 Z-1.000 F1200.0
  N230 G2 X-1.346 Y40.813 I1274.739 J-8.173 F3600.0
  N240 G1 X-1.246 Y43.543 Z-1.000
  N250 G1 X-1.175 Y44.975 Z-1.000
  N260 G2 X0.630 Y65.631 I357.751 J-20.852
  N270 G2 X3.629 Y86.169 I356.674 J-41.593
  N280 G1 X3.738 Y86.813 Z-1.000
  N290 G1 X3.885 Y87.608 Z-1.000
  N300 G1 X4.121 Y88.649 Z-1.000
  N310 G1 X4.891 Y91.654 Z-1.000
  N320 G2 X8.045 Y101.818 I125.643 J-33.412
  N330 G2 X12.017 Y111.685 I122.371 J-43.533
  N340 G1 X12.167 Y112.021 Z-1.000
  N350 G1 X12.392 Y112.507 Z-1.000
  N360 G1 X12.836 Y113.360 Z-1.000
  N370 G1 X14.404 Y116.145 Z-1.000
  N380 G2 X48.101 Y150.602 I84.920 J-49.341
  N390 G2 X94.143 Y164.886 I51.247 J-83.839
  N400 G1 X98.585 Y165.027 Z-1.000
  N410 G2 X107.856 Y164.832 I1.550 J-146.800
  N420 G1 X114.650 Y164.312 Z-1.000
  N430 G1 X121.416 Y163.467 Z-1.000
  N440 G1 X124.191 Y163.060 Z-1.000
  N450 G1 X127.048 Y162.615 Z-1.000
  N460 G2 X139.931 Y159.885 I-25.733 J-153.243
  N470 G2 X152.544 Y156.073 I-38.655 J-150.662
  N480 G1 X157.534 Y154.334 Z-1.000
  N490 G1 X161.108 Y153.062 Z-1.000
  N500 G2 X183.667 Y143.969 I-122.738 J-337.027
  N510 G2 X205.551 Y133.371 I-145.209 J-327.734
  N520 G1 X207.732 Y132.276 Z-1.000
  N530 G1 X215.815 Y128.556 Z-1.000
  N540 G1 X219.037 Y127.150 Z-1.000
  N550 G1 X222.272 Y125.782 Z-1.000
  N560 G1 X223.416 Y125.300 Z-1.000
  N570 G1 X223.904 Y125.085 Z-1.000
  N580 G3 X237.774 Y120.073 I38.168 J83.912
  N590 G3 X252.272 Y117.334 I24.318 J88.999
  N600 G1 X253.479 Y117.248 Z-1.000
 
  Steve Blackmore
  --
 
 

 --
  Minimize network downtime and maximize team effectiveness.
  Reduce network management and security costs.Learn how to hire
  the most talented Cisco Certified professionals. Visit the
  Employer Resources Portal
  http://www.cisco.com/web/learning/employer_resources/index.html
  ___
  Emc-users mailing list
  Emc-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/emc-users
 
 
 

 --
  Managing the Performance of Cloud-Based Applications
  Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
  Read the Whitepaper.
 

 http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk
  ___
  Emc-users mailing list
  Emc-users@lists.sourceforge.net
  

Re: [Emc-users] Axis not updating if linuxcncrsh opens file

[Robert Ellenberg]

I think I've seen this same file-loading issue when using the python
interface. The program_open python command loads a G-code program, but
the GUI doesn't reflect the change by reloading the live plot or the G code
display. Looking into the axis.py script, the open_file_guts function at
line 1040 loads the program internally using program_open(), then re-reads
the program to parse the plot and display the text in a nice format.  It
seems like this bit of extra processing is not triggered by an external
command through linuxcncrsh or the python interface. Hitting reload seems
to reload the old file because the program path stored in axis' internals
doesn't match the currently loaded program anymore.  I can't say how easy
or hard it would be to fix, though.
--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Ramped feed rate, unlurking... And new request for assistance

[Robert Ellenberg]

This sounds like an impressive setup. I'm not familiar with the KL-8082H
particularly, so it's hard to say if having the drivers handle the feedback
would be better than piping it through linuxcnc. My assumption is that if
the drivers already handle it, you'd get the benefit of their controller /
tuning, potentially saving some effort.

In terms of controlling motion proportional to spindle load, you may
actually be able to do that already if you have a spindle encoder.  If your
spindle motor's speed varies in proportion to the load applied, then you
could used spindle-synchronized motion to reduce the feed rate if the motor
speed drops. I imagine a grinding wheel of a decent size would have enough
inertia that you could use a relatively low-resolution encoder, or even an
index pulse.


On Sun, Jan 5, 2014 at 10:54 PM, Andy a...@evanspt.com wrote:

 Robert, thank you for your response and the time you've put into this.
 I've been thinking about this and wonder what the ultimate solution for
 my situation could be.  It likely will involve variable feed rates,
 however I've been wondering how I could tie the feed rate to the motor
 load.  I'll try to get my head around this as I move forward on my project.

 I don't remember what I shared before about my application and history.
 In early 2010 I did some experimenting with EMC2 and a single axis
 linear actuator for creep-feed grinding, and rapidly gained the
 confidence to put together a 4 axis machine, basically configured as a
 mill with a rotary indexer.  I was doing all this on my own nickel to
 develop a process for making a family of parts for a customer.  This was
 put together using Gecko drives and steppers with then current version
 of Ubuntu and EMC2.  The machine came together beautifully with the
 mechanical aspects (ball screw installations, motor hardware, limit
 switches, etc.) and with the configuration of EMC2.  I had hired a
 friend who was electrically and computer savvy to help me and we had a
 great time overcoming every obstacle in our path.  And the results still
 work great!

 The customer's orders for the product have fluctuated in the years
 since, and we have been able to use this machine to good effect, except
 that last fall they finally gained some market traction and the
 production needs took a jump (Yay!).   Back when I finished the first
 machine, I had an opportunity to pick up another donor machine for what
 I envisioned as rev 2 for this project.  It is a Harig Slicer with a
 larger enclosure, higher HP spindle, already outfitted with motor mounts
 and a ball screw on one axis.  I have worked on this slowly in the
 interim, primarily replacing the hydraulic longitudinal axis drive with
 ball screw.  With the uptick in orders, I have accellerated my attention
 on this project, trying to apply our learnings from Grinder #1.  G1 had
 been placed in a subcontractor's shop these past couple years and I have
 recently brought it back to my place (the subs could no longer keep up
 on their part time basis) and I'm able to keep it running two shifts per
 day.

 So now I am working to get the Harig (G2) into production, although it
 has taken a back seat to my attention on reinstalling G1 and resuming
 production.  G2 has the latest software releases and I have gotten as
 far as powering the drives and motors but have not done any final
 calibrations.  I may have a limit switch or two to hook up.  I've also
 got an MPG to work.

 Driver settings.  I've got some numbers that allow it to move, but I
 read right here that I should be sure of these numbers! ;-)

 I couldn't find the KL-8082H on:
 http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Stepper_Drive_Timing

 So I will be happy to share what I learn.  There is some information on
 this document:

 http://www.automationtechnologiesinc.com/wp-content/uploads/downloads/2012/06/KL-8082H.pdf


 But in my ignorance I lack confidence in my interpretations.  Maybe some
 of you know something about these drivers? (Shouldn't have bought them,
 maybe?)  They are closed-loop steppers, and I bought them from
 Automation Technology Inc but the guy basically pleads ignorance with
 LinuxCNC and says most of his stuff is going to the Mach/Windows
 users.   I wished I'd fleshed this out on this list before I bought 'em...

 These drivers are supposed handle the encoder feedback and do any
 necessary travel corrections.   As I understand, LinuxCNC has the
 capability to use the encoders, so maybe I would be better off with
 Geckos and wiring the encoders back to EMC2?

 Thanks,
 Andy E








 --
 Rapidly troubleshoot problems before they affect your business. Most IT
 organizations don't have a clear picture of how application performance
 affects their revenue. With AppDynamics, you get 100% visibility into your
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics
 Pro!
 

Re: [Emc-users] Ramped feed rate, unlurking...

[Robert Ellenberg]

(I may have sent a duplicate message, apologies if I did...)

Hi Andy,

I should point out the ramping was originally raised as an idea by Greg
Bentzinger, I just suggested a few ways to implement it.  Out of curiosity,
I started a feature branch to see what it would take to do this, and the
planner changes ended up being pretty simple.

You can see the (experimental) code in action if you use this branch:
https://github.com/robEllenberg/linuxcnc-mirror/tree/feature/vel-ramping

You can run the test in tests/trajectory-planner/circular-arcs if you want
to play around in simulation, or setup your own config with the appropriate
INI options. Look in this file for an example config:

tests/trajectory-planner/circular-arcs/circular_arcs.ini

The ARC_BLEND_SMOOTHING_THRESHOLD setting controls how much of a line
should be consumed by a blend arc before switching to velocity ramping
instead of trapezoidal. Setting this to 0.0 always uses ramping, while 1.0
never uses ramping.

Let me know if this is the behavior you're looking for. If we can agree on
a G-code mode to represent ramping vs. trapezoidal mode, then it's just a
matter of adding the appropriate case to the interpreter.

-Rob


On Thu, Dec 26, 2013 at 3:13 PM, Andy a...@evanspt.com wrote:

 My name is (another) Andy, in Oregon USA, and a user of EMC2 since about
 3 years ago, and now in the process of building a second machine.

 I was intrigued with Robert's inquiry about ramped feeds, and my
 application could certainly benefit from that.  I realize that you may
 segment a linear move and code in the feed changes, which would very
 likely be the smart thing for me to do in my application, but do I like
 the idea.  Could this be destination synchronized just as linear moves
 are?

 My application is in a creep-feed grinding machine, where the motor load
 is limiting my feed in a ramped cut.

 I look forward to more of the learning that this list has provided me
 since joining a few weeks ago.


 --
 Rapidly troubleshoot problems before they affect your business. Most IT
 organizations don't have a clear picture of how application performance
 affects their revenue. With AppDynamics, you get 100% visibility into your
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics
 Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
 ___
 Emc-users mailing list
 Emc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-users

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Ramped feed rate.

[Robert Ellenberg]

Hi Greg,

Sorry for taking so long to answer. I've been working on the trajectory
planner recently, so I can try to weigh in on your question. First of all,
I'm curious what the application for this would be. Do you use it as a
one-off move, or would you run a whole program this way?

It seems like this mode could useful when you have a program to do detailed
profiling with short segments. The default planner would make a velocity
profile that has more of a stair-step shape, since it will accelerate as
fast it can to the requested speed.

This is a minor change in the trajectory planner. The bigger issue is how
we'd want to control this mode. One way could be to create a new G-code,
similar to G61 / G64. It could also be done by HAL-pin, if you didn't need
to switch between modes during a program.

I'm curious what others think about this. Would anyone else find this
useful?

-Rob


On Wed, Dec 18, 2013 at 7:17 PM, Greg Bentzinger skullwo...@yahoo.comwrote:

  (Ok here I am mumbling into a microphone before the crowd... )

 But going way, way, way back ( Picture in your minds eye teletypes and
 paper tape programs...) I had always wanted a ramped feed rate command.

 Like

 G1 X1. Z-.25 F20.
 ( ramp command) X4. Z-1. F5.

 So that the move from X1. Z-.25 to X4. Z-1. would start at F20. and slow
 to F5. by completion of the move.

 This could be a one shot ( like a G04 ) or modal, or both.

 Another use would be for a part off lathe tool being fed in FeedPerMin vrs
 FeedPerRevolution.

 Same could apply to feeding a tapered ream, start at F.02 end at F.002 (
 FPR )

 Often there are other easy ways to do things, but sometimes it would be
 the best method - were it available.

 Just thinking outloud

 Greg


 --
 Rapidly troubleshoot problems before they affect your business. Most IT
 organizations don't have a clear picture of how application performance
 affects their revenue. With AppDynamics, you get 100% visibility into your
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics
 Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
 ___
 Emc-users mailing list
 Emc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-users

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Limiting Jerk

[Robert Ellenberg]

On Mon, Dec 16, 2013 at 11:47 AM, Charles Steinkuehler 
char...@steinkuehler.net wrote:

 Hmm...I dug into this a bit, and it turns out the Arduino Marlin
 firmware doesn't really support true jerk limiting.  What they call jerk
 is actually the maximum instantaneous allowable change in combined XY
 velocity (ie: going around corners).  I'm pretty sure the jerk setting
 in Marlin can be approximated (likely with better overall results) using
 G64 with a tolerance.

 Descriptions of Arduino/Marlin jerk limiting:

 http://forums.reprap.org/read.php?146,190628,191971#msg-191971

 https://github.com/ErikZalm/Marlin/issues/305#issuecomment-10318472


That's an interesting use of the term jerk, certainly. The circular-arc
blend method limits cornering acceleration as well, so you don't need a
separate spec for that. If they're using a trapezoidal velocity profile,
there will still be large kinematic jerks, though. Whether you need
jerk-limiting will probably depend on how stiff your machine is relative to
the max acceleration, and how much damping your structure and joints
provide. It would certainly be useful feedback for me if you tried out the
circular arc branch (linked below if you're curious).

https://github.com/robEllenberg/linuxcnc-mirror/tree/circular-blend-arc-alpha

One issue I can see with running a 3D printer is that A-axis moves have to
fall back to stock blends (i.e. parabolic). It's something I'd like to
address in a future release, though there's more work to be done on that
front.

-Rob
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Slow G code

[Robert Ellenberg]

I spent some time going through the math behind it, and I think blending
between linear moves with ABCUVW motion is feasible, though it will take a
a bunch of new data structures to store a 9D vector.

There are two big challenges to making this work. The first is implementing
a new way to interpolate along a spherical arc (SLERP), since we won't have
a normal vector. The second is that tolerances become very hard to enforce
with rotary movement. A small displacement in an ABC axis can mean a large
tool displacement, and there it would likely be tough to predict this if TP
treats all joints as independent and linear.  Of course, we can simply have
the algorithm abort if we ask for a tolerance, so this isn't a total
deal-breaker.

-Rob


On Wed, Dec 11, 2013 at 11:20 AM, Ricardo Moscoloni rmoscol...@gmail.comwrote:

 Rob:
 a axis is along x, config is simple, just have to edit GEOMETRY =
 -AXYBC in ini file.
 i will send you a link sharing a folder in goog drive, theres config
 files and some sample gcode, just let me know if you can se it!
 theres no way i could run it smoothly, blending in rot axis is a must!
 there is a way to implement it?  could you expand the need of non
 trivial kinematics in this case?, seems trivial to me.
 Regards
 rick



 2013/12/9 Robert Ellenberg rwe...@gmail.com:
  On Mon, Dec 9, 2013 at 1:04 PM, Ricardo Moscoloni rmoscol...@gmail.com
 wrote:
 
  Hi Robert,
  Im very interested in this too, are you trying to solve slow gcode or
  smooth movement? or both?
 
 
  I'm mostly trying to improve the speed of programs with small segments,
 but
  part of that effort has improved the smoothness as well. The smoothness
  comes from a higher average speed, which means fewer dips in velocity due
  to short segments. I added an additional check that reduces velocity
  ripple in programs with short, similar-length segments.
 
  one problems i find doing a filament winder, linear X and rot A, was
  the lack of blending between them. Also the different interpretation of
  feed between linear and angular (regular feed or non inverse time feed
  rate) cause trouble, when a move changes from linear to angular.
 
 
  My work so far has just been cartesian motion in XYZ, so the current set
 of
  changes may not help with A axis blends. I'm interested in expanding this
  to cover additional axes, but it's not as straightforward due to the
  non-trivial kinematics. Can you tell me more about the setup and motions
  you're using? For example, what orientation is your A axis? Can you send
 me
  an example machine config and G-code?
 
  Axis backplot draw the gcode correctly, and keeps me thinking in a
  manner to ensure constant surface speed doing blending based in tip
  point absolute spatial speed calculations but my lack of programming
  skills drop me.
  Im willing to help in whetever i cancould you explain more about
  your particular branch, i like to test it.
 
 
  Here is the current branch if you're interested in running it:
 
 
 https://github.com/robEllenberg/linuxcnc-mirror/tree/circular-blend-arc-alpha
 
 
  In particular, I could use feedback on how this code runs with axis
 motion
  other than XYZ. It should gracefully fall back to parabolic blends, so
 any
  issues you can find with this would be very helpful.
 
  Thanks!
  -Rob
 
 --
  Sponsored by Intel(R) XDK
  Develop, test and display web and hybrid apps with a single code base.
  Download it for free now!
 
 http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
  ___
  Emc-users mailing list
  Emc-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/emc-users


 --
 Rapidly troubleshoot problems before they affect your business. Most IT
 organizations don't have a clear picture of how application performance
 affects their revenue. With AppDynamics, you get 100% visibility into your
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics
 Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
 ___
 Emc-users mailing list
 Emc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-users

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo

Re: [Emc-users] Slow G code

[Robert Ellenberg]

That's a good point: the radius affects the tool path error in a way that
we can't predict from G-code alone. It would be straightforward to do G64
with no tolerance, though, but I don't know how useful a
half-implementation like that would be.


On Fri, Dec 13, 2013 at 2:59 PM, andy pugh bodge...@gmail.com wrote:

 On 13 December 2013 18:51, Robert Ellenberg rwe...@gmail.com wrote:
  I spent some time going through the math behind it, and I think blending
  between linear moves with ABCUVW motion is feasible,

 One big problem is that G-code has no way to  define the location of
 centres of rotation.
 (I don't know if that matters for your maths).
 It would not be at all unusual for Z=0 to be the surface of a
 cylindrical workpiece, rather than the axis.

 --
 atp
 If you can't fix it, you don't own it.
 http://www.ifixit.com/Manifesto


 --
 Rapidly troubleshoot problems before they affect your business. Most IT
 organizations don't have a clear picture of how application performance
 affects their revenue. With AppDynamics, you get 100% visibility into your
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics
 Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
 ___
 Emc-users mailing list
 Emc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-users

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Slow G code

[Robert Ellenberg]

On Mon, Dec 9, 2013 at 1:04 PM, Ricardo Moscoloni rmoscol...@gmail.comwrote:

 Hi Robert,
 Im very interested in this too, are you trying to solve slow gcode or
 smooth movement? or both?


I'm mostly trying to improve the speed of programs with small segments, but
part of that effort has improved the smoothness as well. The smoothness
comes from a higher average speed, which means fewer dips in velocity due
to short segments. I added an additional check that reduces velocity
ripple in programs with short, similar-length segments.

one problems i find doing a filament winder, linear X and rot A, was
 the lack of blending between them. Also the different interpretation of
 feed between linear and angular (regular feed or non inverse time feed
 rate) cause trouble, when a move changes from linear to angular.


My work so far has just been cartesian motion in XYZ, so the current set of
changes may not help with A axis blends. I'm interested in expanding this
to cover additional axes, but it's not as straightforward due to the
non-trivial kinematics. Can you tell me more about the setup and motions
you're using? For example, what orientation is your A axis? Can you send me
an example machine config and G-code?

Axis backplot draw the gcode correctly, and keeps me thinking in a
 manner to ensure constant surface speed doing blending based in tip
 point absolute spatial speed calculations but my lack of programming
 skills drop me.
 Im willing to help in whetever i cancould you explain more about
 your particular branch, i like to test it.


Here is the current branch if you're interested in running it:

https://github.com/robEllenberg/linuxcnc-mirror/tree/circular-blend-arc-alpha


In particular, I could use feedback on how this code runs with axis motion
other than XYZ. It should gracefully fall back to parabolic blends, so any
issues you can find with this would be very helpful.

Thanks!
-Rob
--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Slow G code

[Robert Ellenberg]

On Dec 6, 2013 5:53 PM, Tomaz T. tomaz_...@hotmail.com wrote:

 Very nice to hear someone is working on that, I can provide you some
complex 3 and 5-axis code generated from NX (siemens unigraphics), and I
can also test it on my machine to check for improvements...
 If you want, I can send you a this code I used for this test mill of
turbine:http://www.youtube.com/watch?v=iy1Mb6G_VJ0 

I'm definitely interested, in particular in the 5 axis code. I need to make
sure that it handles motions on other axes properly. If you'd like to test
the code, it's available on my github repository here:

https://github.com/robEllenberg/linuxcnc-mirror

The branch is circular-blend-arc-alpha.

Thanks!

  If you'd like to contribute to this effort, I'm looking for G-code that
  runs slower than the requested feed rate. In particular, I'm looking for
  programs that have lots of short segments that approximate smooth
paths. If
  you have a program that you think should run faster and are willing to
  share it, please email it to me. While my fixes won't improve every
issue,
  part of my goal here is to survey how common some problems are. If it
turns
  out that a slowdown I consider rare is common in your programs, it will
  justify some additional work in that direction.



--
 Sponsored by Intel(R) XDK
 Develop, test and display web and hybrid apps with a single code base.
 Download it for free now!

http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
 ___
 Emc-users mailing list
 Emc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-users
--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] Slow G code

[Robert Ellenberg]

Hi All,

As some of you know already, I'm working on an improvement to the linuxcnc
trajectory planner that will allow much faster movement for engraving-type
programs with lots of short segments. As part of this effort, I need test
cases, both to find rare errors, and to estimate performance improvements.

If you'd like to contribute to this effort, I'm looking for G-code that
runs slower than the requested feed rate. In particular, I'm looking for
programs that have lots of short segments that approximate smooth paths. If
you have a program that you think should run faster and are willing to
share it, please email it to me. While my fixes won't improve every issue,
part of my goal here is to survey how common some problems are. If it turns
out that a slowdown I consider rare is common in your programs, it will
justify some additional work in that direction.

Thanks!
Rob
--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Slow G code

[Robert Ellenberg]

On Thu, Dec 5, 2013 at 8:20 PM, Bertho Stultiens ber...@vagrearg.orgwrote:

 You could use the wheels.gcmc example from gcmc (contributed by Alan
 Battersby). It creates a lot of small segments of 10..100um. You can
 even increase the number of segments by decreasing the angle-interval of
 the calculation (currently at 0.01 degrees).


Thanks, Bertho, I'll give this a shot. By the way, I launched gcmc
accidentally with no input, and it seemed to hang. Running with --help
listed the arguments nicely, so you might want to treat no arguments the
same as --help.
--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Slow G code

[Robert Ellenberg]

On Dec 5, 2013 8:52 PM, Bertho Stultiens ber...@vagrearg.org wrote:

 On 12/06/2013 02:37 AM, Robert Ellenberg wrote:
  You could use the wheels.gcmc example from gcmc (contributed by Alan
  Battersby). It creates a lot of small segments of 10..100um. You can
  even increase the number of segments by decreasing the angle-interval
of
  the calculation (currently at 0.01 degrees).
  Thanks, Bertho, I'll give this a shot.

 Great.


  By the way, I launched gcmc accidentally with no input, and it seemed
  to hang. Running with --help listed the arguments nicely, so you
  might want to treat no arguments the same as --help.

 Running gcmc with no file as input will read input from stdin (the
 command-line) as in good unix tradition. If you do not specify an output
 file (-o option) then all output is written to stdout. This is done so
 you can form command-chains with pipes on the command-line.

 The behavior is described in the man-page
 (http://www.vagrearg.org/content/gcmc-man).

 You can terminate with ^C (break) or ^D, which is EOF on *nix systems
 (or, if using windows, ^Z to indicate EOF).

Ahh, I see, that's a clever feature!


 --
 Greetings Bertho

 (disclaimers are disclaimed)


--
 Sponsored by Intel(R) XDK
 Develop, test and display web and hybrid apps with a single code base.
 Download it for free now!

http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
 ___
 Emc-users mailing list
 Emc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-users
--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Slow G code

[Robert Ellenberg]

On Thu, Dec 5, 2013 at 11:57 PM, Todd Zuercher zuerc...@embarqmail.comwrote:

 Glad to hear your making progress.  Might your modifications work with
 more than XYZ axis. (I need to run it on 4 axis xyzw.)


It will be compatible with 4+ axes, but most of the improvement will be for
XYZ moves only.
It falls back to simple parabolic blending if there's movement in the other
6 axes.

Would it be ok to send the sample g-code directly to your email?  If so
 I'll try to dig up some extra slow stuff tomorrow at work.


Absolutely, that's a good way to avoid the attachment size limit. That's
also my dropbox email address, so if you have dropbox and want to share a
folder, that works too.

Thanks!
Rob
--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Way to control 6 axis robot, jerk limitation. Araisrobo?

[Robert Ellenberg]

Hi Greg,

Good idea! I've worked with IKFast and OpenRAVE for a few years as part of
my graduate work, and it's definitely a powerful system.  The really nice
thing about it is that it outputs C++ code that can be compiled into
another program, and has standardized inputs and outputs. The solvers can
typically return results in microseconds, which should be plenty for
trajectory planning. It's also really nice in that you can model your robot
in a simple XML format, simulate it in OpenRAVE, and see the IK solutions
visually, so you're not flying blind.

-Rob


On Wed, Nov 6, 2013 at 4:02 AM, Gregg Eshelman g_ala...@yahoo.com wrote:

 On 11/5/2013 11:44 PM, Sven Wesley wrote:
  2013/11/6 Marius Alksnys marius.alks...@gmail.com
 
  I am using master branch.
 
  On 11/05/2013 11:29 PM, Sebastian Kuzminsky wrote:
  What branch are you using?  I believe the joints_axes4 branch may have
  some of these issues fixed.
 
 
  Sebastian (in Stuttgart) addressed some kinematic problems as well, like
  the Gimbal lock. I don't know if he proceeded to fix that himself. You
  should e-mail him and ask.

 Could IKFast be brought into LCNC from OpenRAVE?

 https://en.wikipedia.org/wiki/OpenRAVE



 --
 November Webinars for C, C++, Fortran Developers
 Accelerate application performance with scalable programming models.
 Explore
 techniques for threading, error checking, porting, and tuning. Get the most
 from the latest Intel processors and coprocessors. See abstracts and
 register
 http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk
 ___
 Emc-users mailing list
 Emc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-users

--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users