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

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

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

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 threa

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

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

Re: [Emc-users] Halscope Log Files

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

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

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,

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

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 ri

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

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

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

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

[Emc-users] Spindle speed signal

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

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

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

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

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

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

irect 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

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

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

Re: [Emc-users] Cycle time discussion

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

Re: [Emc-users] calling Todd Z

m (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: [

Re: [Emc-users] seasons greetings

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

Re: [Emc-users] calling Todd Z

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

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

Re: [Emc-users] calling Todd Z

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

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'

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

, 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>: > > Cu

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

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:

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

, 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

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

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

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

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

Re: [Emc-users] Path blending

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

Re: [Emc-users] Path blending

ons 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:

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

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

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

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

Re: [Emc-users] Possible Trajectory Problem

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

Re: [Emc-users] New Tajectory Planner

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

Re: [Emc-users] Jerky motion

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

Re: [Emc-users] Poor CV

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,

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

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

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

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 /

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

(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

Re: [Emc-users] Ramped feed rate.

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

Re: [Emc-users] Limiting Jerk

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

Re: [Emc-users] Slow G code

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

Re: [Emc-users] Slow G code

...@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

Re: [Emc-users] Slow G code

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

Re: [Emc-users] Slow G code

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

[Emc-users] Slow G code

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

Re: [Emc-users] Slow G code

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

Re: [Emc-users] Slow G code

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

Re: [Emc-users] Slow G code

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

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

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