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] Problem with Rigid Tapping on USC Equipped Bridgeport

g 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

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, z2);

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 reading

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 p

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

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] Acceleration Settings?

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

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] 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 reaso

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

ow this is to be aproached... On Sun, Nov 6, 2016 at 6:48 PM, Robert Ellenberg wrote: > As of now, circular arc blending doesn't work with the ABC axes (which is > why it's running so slowly for you with short segments), but I'm working on > a fix. I had an extensive disc

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 the G-code move was "X

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 the axis of ration is not pa

[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 th

[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 impro

Re: [Emc-users] "Slow" G code

On Thu, Dec 5, 2013 at 8:20 PM, Bertho Stultiens 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 (curr

Re: [Emc-users] "Slow" G code

On Dec 5, 2013 8:52 PM, "Bertho Stultiens" 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

Re: [Emc-users] "Slow" G code

On Thu, Dec 5, 2013 at 11:57 PM, Todd Zuercher wrote: > 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 si

Re: [Emc-users] "Slow" G code

On Dec 6, 2013 5:53 PM, "Tomaz T." 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 f

Re: [Emc-users] "Slow" G code

On Mon, Dec 9, 2013 at 1:04 PM, Ricardo Moscoloni 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 a

Re: [Emc-users] "Slow" G code

xpand the need of non > trivial kinematics in this case?, seems trivial to me. > Regards > rick > > > > 2013/12/9 Robert Ellenberg : > > On Mon, Dec 9, 2013 at 1:04 PM, Ricardo Moscoloni >wrote: > > > >> Hi Robert, > >> Im very interested in this too,

Re: [Emc-users] "Slow" G code

ndy pugh wrote: > On 13 December 2013 18:51, Robert Ellenberg 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 &g

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 combin

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 li

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 plan

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 / t

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 104

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, Ma

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 thi

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 planne

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 blen

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 Kiki

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

; > > > On Wednesday, July 29, 2015, Bertho Stultiens > 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 Koko

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 short

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 So that depth Z is ac

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 s

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 wrote: > On Monday 19 October 2015 19:48:31 Robert

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

uns 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 wrote: > On Mon, Oct 19, 2015 at 11:30:14PM +, Robert Ellenberg wrote: > > would you mind sharing the g-code so I can >

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: > I want to control two d

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 wrote: > 2015-11-11 14:51 GMT+02:00 Robert Ellenberg : > > Currently the TP does not support arc blends between rotary

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 spits out. > > LINUXCNC - 2.

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 wrote: > Todd, > > I'll troubleshoot the

Re: [Emc-users] calling Todd Z

y 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" > > To:

Re: [Emc-users] calling Todd Z

; 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" > To: "Enhanced Machine Controller (EMC)" > Sent: Friday, November 27,

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 PM, Gene > > Heskett wrote: > > > > > > Greetings all

Re: [Emc-users] calling Todd Z

t; 2.7)? > > ----- Original Message - > From: "Robert Ellenberg" > To: "Enhanced Machine Controller (EMC)" > Sent: Tuesday, December 1, 2015 12:31:50 PM > Subject: Re: [Emc-users] calling Todd Z > > That's consistent with the changes I made, th

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 c

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 blend