Re: [Emc-developers] Minimum feed rate in G93

CNC boule-drawing machine or something, but otherwise it should be plenty of headroom. On Mon, Jan 11, 2021 at 3:52 PM Jon Elson wrote: > On 01/11/2021 01:30 PM, Robert Ellenberg wrote: > > I think the reason there are minimum feed rate (overall) is because > motion > > / TP has a

Re: [Emc-developers] Minimum feed rate in G93

should someone be suitably motivated. -Rob On Mon, Jan 11, 2021 at 11:57 AM Jon Elson wrote: > On 01/11/2021 09:23 AM, Robert Ellenberg wrote: > > The good news is, I've got a fix that removes this restriction, and > instead > > checks if the resulting feed rate is above th

Re: [Emc-developers] Minimum feed rate in G93

I'm not sure why it was added, but this restriction has some nasty side effects if you're doing rotary axis work. The pathological case is a G1/G2/G3 move with very short but non-zero motion in XYZ, and significant ABC axis motion. The minimum feed rate value applied is 0.1 units per min. Mixed XYZ

Re: [Emc-developers] problem understanding diagram from help-pages of pncconf

Reinhard, I agree that it's logical to use positive offsets for tools in a spindle (since a negative physical size is nonsensical). However, what if you have an auxiliary spindle with a tool tip above the zero height of the main spindle? I'm not saying that's a wise choice, but it would be physica

Re: [Emc-developers] interpolationTime value

Interpolation in that context was a way to run the trajectory planner at a slower rate than the servo loop, and interpolate between planned points. Currently, the TP and servo loop run at the same rate (usually 1kHz) so the interpolation has no effect. On Mon, Apr 27, 2020, 6:23 PM Georgios Liolid

Re: [Emc-developers] Emc-developers Digest, Vol 168, Issue 80

It's the same process to adjust it up or down. The TP plans blend sizes for a maximum feed override (typically 150% or 200%). No replanning has to happen at all for any feed override value. You could apply as large an override as you wanted in theory, but it would slow down disproportionately in th

Re: [Emc-developers] single step, task, TP, motion, offsets ...

I agree, the motion / TP component now is doing work that doesn't have to be in real-time. Specifically, the queueing of motion commands and the lookahead optimization could be done in a user space component. You'd need a real-time safe queue structure to do it, but it would make the optimization p

Re: [Emc-developers] fixture offset

> Well it does. > > ie G10 adjust the tool offsets. > > How tool offsets work are defined by the Gcode rules. > > We could produce a different interpreter that converts ChrisMorley code > into motion moves. > > maybe it doesn't have tool offsets, linuxcnc motion would be fine with it. > > > It's th

Re: [Emc-developers] fixture offset

Reinhard, I strongly recommend using G10 for this because the NML command doesn't update the offsets in interp. This would cause subsequent motions to have the wrong offset values, and get the machine into an inconsistent state. In general, I'd be very wary of bypassing G-code for this kind of thi

Re: [Emc-developers] Toolchange and tlo behaviour change in 2.8

hard wrote: > Hi, > > On Samstag, 11. April 2020, 04:54:41 CEST Robert Ellenberg wrote: > > Furthermore, you could eliminate > > the M6 (since "changing" a tool doesn't necessarily imply a physical tool > > change). For the slitting saw example, y

Re: [Emc-developers] Toolchange and tlo behaviour change in 2.8

That's an interesting point, and a great reason to not require that a tool have exactly one offset. I think there may be a solution that addresses all of these concerns: 1. A tool with no offset doesn't make sense 2. A single physical tool (saw top / bottom, face mill inserts) can have mo

Re: [Emc-developers] Toolchange and tlo behaviour change in 2.8

Reinhard, I partially agree: to everyone, what is the point of a tool change command that doesn't apply a corresponding length offset? If you don't have an offset stored (or a means of measuring it like a toolsetter / touchoff subroutine), then a tool number is just an arbitrary label. One example

Re: [Emc-developers] State-synch G-code.

>From my experience, it's more for remap and subroutine authors than end users. For example, reading Hal pins in g-code via _hal. On Thu, Apr 9, 2020, 7:40 PM Chris Morley wrote: > This feels wrong. why would the user need to know anything about when to > pause the queue? > > The gcode should kn

Re: [Emc-developers] State-synch G-code.

Yes! That would be way more convenient than the common kludge of an M66. On Thu, Apr 9, 2020, 6:34 PM andy pugh wrote: > Should we invent a new G-code that functions specifically to bust the > queue? > > -- > atp > "A motorcycle is a bicycle with a pandemonium attachment and is > designed for th

Re: [Emc-developers] synch between fwd stroke and backout for G33.1

Gene, what linuxcnc version are you running? On Sun, Apr 5, 2020, 7:35 PM Jon Elson wrote: > On 04/05/2020 01:12 PM, Gene Heskett wrote: > > So I'm back to the Z backlash as a possible culprit.. I > > assume it is applied as the spindle is doing its turnaround. > It just seems to me that compens

Re: [Emc-developers] improve synchronization between backend and UI

otion command to change offset, but as you said motion > doesn't need to know abut it it's baked into the actual command for > movement. > > Thanks for setting me straight on that guys. > It's interesting to get into it a bit (and a little scary). > > Chris > __

Re: [Emc-developers] improve synchronization between backend and UI

Chris, unfortunately G10 doesn't send any "motion" commands, it directly changes the work offsets in interp (where they live), and if the changed offset is active, sends canon commands to update the current offset values. Those commands never make it to motion. Canon is basically synchronized with

Re: [Emc-developers] improve synchronization between backend and UI

the > pathpilot code ? > > Are they included in the current state tags branch? > > Thanks for the great work... > > Regards, > > automata > > On Tue, 31 Mar, 2020, 7:51 pm Robert Ellenberg, wrote: > > > Hi Reinhard, > > > > Thanks for looking into

Re: [Emc-developers] improve synchronization between backend and UI

Hi Reinhard, Thanks for looking into this! I think state tags could solve your issue. I wrote state tags years ago for PathPilot's fork of LinuxCNC to solve these problems: 1. UI status reflected the "read to" line, not the currently-executing line 2. When aborting a program, a user woul

Re: [Emc-developers] announcement OpenCN, a new fork of LinuxCNC

Hi Raoul, That's impressive work! Thanks for sharing it with all of us. It's been a long-standing goal for us to support limited-jerk planning and smoother blends. It's a major achievement to both create G2-continuous blends and optimize the overall feedrate, and I'm excited to see your future wo

Re: [Emc-developers] New Stuff

Hi Andy, There are a few that I've been sitting on for a while that should really be fixed pre-release: - 639 - unexpected motion after abort during threading - 546 - acceleration violatio

Re: [Emc-developers] Link-time optimization in realtime objects

the problems? > > Paul Kessler > > -Original Message- > From: Robert Ellenberg > Sent: Thursday, August 15, 2019 11:39 AM > To: EMC developers > Subject: [Emc-developers] Link-time optimization in realtime objects > > Hi All, > > Has anyone tried to

[Emc-developers] Link-time optimization in realtime objects

Hi All, Has anyone tried to use link-time optimization in the realtime object builds? I think the motion / TP build would be a good candidate for it, so we could improve inlining of things like posemath. Best, Rob ___ Emc-developers mailing list Emc-de

Re: [Emc-developers] Introduction and a couple of questions

g in > popularity in industry everywhere. Andy might be right plasma does need a > new task module but for now there is a high class working solution. But he > should not need to maintain the core code for a 4 year old feature on a > private repository to achieve it. > > > Rod Webster

Re: [Emc-developers] Introduction and a couple of questions

Hi Randy, Welcome to the community! It's great to hear that you've been a long time user and want to contribute. If you have any interest in motion / TP, I'm happy to answer questions (since there's a lot of history there). Andy / Chris / Rod / Phillip, I agree that the languishing release schedu

Re: [Emc-developers] To-Do list

According to the log, it's not happy with my use of (gasp!) a C99 feature. I've been writing C++ for too long, I guess. The latest build passes now. On Thu, May 2, 2019, 5:21 AM andy pugh wrote: > On Thu, 2 May 2019 at 02:38, Robert Ellenberg wrote: > > > https://github

Re: [Emc-developers] To-Do list

Andy, I appreciate your vote of confidence :). It would be nice to have push access, though I'm happy to go through a pull request / review process if anyone else has interest in testing / reviewing my changes in a reasonable time. I think having motion / TP unit tests will be a big help here, sinc

Re: [Emc-developers] Simultaneous 4 axis + new TP

Hi Curtis, There are a few major hurdles to doing rotary axis blending: 1. Blends between circular motions (that also have motion in other axes) are not geometrically possible with the blending technique we use (circular arc segments), except for some special cases. This IS possible with

[Emc-developers] Unit testing for motion / trajectory planner

Hi All, I've been working on a simple unit testing framework for motion / TP based on a Meson build script and the "greatest " framework, which can be seen in this development branch: https://github.com/robEllenberg/linuxcnc-mir

Re: [Emc-developers] G33 linear motion limits exceeded error

create a > > thread that is faster than the axis limit (for a given rpm) awesome! > > (and it doesn't seem to pause at the end when there is an error) > > This branch works for me, too. > > > On 01/26/2017 09:44 PM, Robert Ellenberg wrote: > >> For anyone i

Re: [Emc-developers] G33 linear motion limits exceeded error

u don't have an encoder you can't do G33 anyway. > >[...] > > > > On Mon, Jan 23, 2017, at 12:18 PM, Robert Ellenberg wrote: > >> Is there an INI or HAL setting to tell LinuxCNC that the spindle > >> ismanually controlled? > > > > Not that I'm awa

Re: [Emc-developers] G33 linear motion limits exceeded error

John, you raise a good point here. The general assumption is that the S word is a reasonable prediction of spindle speed. What do you think of having a check at both interp time and runtime? That would cover all cases. For machines like yours, we could suppress the interp-time error. Is there an IN

Re: [Emc-developers] G33 linear motion limits exceeded error

That's true, though I think we should warn users of errors we can detect as early as possible, so they don't have to destroy a part to learn the significance of a line in the documentation. On Fri, Jan 20, 2017, 9:22 AM John Kasunich wrote: > > > On Fri, Jan 20, 2017, at 07:46 AM, John Morris wr

Re: [Emc-developers] G33 linear motion limits exceeded error

I think it's a bug (or at least an oversight), see this issue: https://github.com/LinuxCNC/linuxcnc/issues/167 I have an experimental fix: https://github.com/robEllenberg/linuxcnc-mirror/tree/feature/spindle-sync-overhaul-2.7 It caps spindle speed based on max feed for position sync moces. It s

Re: [Emc-developers] Spindle speed signal

12/14/2016 05:56 PM, sam sokolik wrote: > > Here is a plot with motion.spindle-speed-in > > > > > http://electronicsam.com/images/KandT/testing/robthreading/latest/robnewandspindlein.png > > > > sam > > > > > > > > On 12/11/2016 03:52 PM, Robert

Re: [Emc-developers] Spindle speed signal

Sam, one last thing, is it possible to put the spindle-speed-in pin on a halscope channel? I'd like to see what the spindle velocity is when it transitions out of accel sync. On Sun, Dec 11, 2016 at 4:44 PM Robert Ellenberg wrote: > Thanks for giving it a spin! > > I am still get

Re: [Emc-developers] Spindle speed signal

already, so we get the benefit for free. On Sun, Dec 11, 2016 at 12:18 PM Gene Heskett wrote: On Sunday 11 December 2016 09:17:32 Robert Ellenberg wrote: > Ahh, that would have been smart to include before: > >- sim_spindle_encoder's position signal is now quantized based on &

Re: [Emc-developers] Spindle speed signal

Thanks for giving it a spin! I am still getting the error about the spindle going too fast.. You can see the threading is happening at 19.12 ipm and the axis max vel is 30ipm. I tried a similar config and got the same result (could be both configs have some odd issue we have not figured out.) ht

Re: [Emc-developers] Spindle speed signal

lled "spindle_fb" - Math tweaks to rigid tapping / position tracking to prevent discontinuities due to sign changes. -Rob On Sun, Dec 11, 2016 at 8:20 AM andy pugh wrote: On 11 December 2016 at 06:30, Robert Ellenberg wrote: > For anyone interested in testing, my latest br

Re: [Emc-developers] Spindle speed signal

ul when running it on hardware (cut air or wax first!). Best, Rob On Fri, Dec 9, 2016 at 12:17 PM Robert Ellenberg wrote: > Peter, I like your idea of calculating a velocity if none is provided. > I'll take a look at the PID component. > > Andy / Chris, from your feedback, it

Re: [Emc-developers] Spindle speed signal

Peter, I like your idea of calculating a velocity if none is provided. I'll take a look at the PID component. Andy / Chris, from your feedback, it sounds like cases like Jon's are rare, but we shouldn't break them. Peter's approach gives a safe if suboptimal fallback. If the future manual explains

[Emc-developers] 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

Re: [Emc-developers] Hardware testing for improved spindle tracking jitter (issue 164)

Sam, what are the max velocity and acceleration on the Z axis? It looks like 0.5 in / sec and 20 in/sec^2 from the plots. I want to match my sim configuration to yours. On Sat, Nov 26, 2016, 2:03 PM Robert Ellenberg wrote: > Ahh, I'll take another look at the math, clearly it's no

Re: [Emc-developers] Hardware testing for improved spindle tracking jitter (issue 164)

1/25/2016 09:24 PM, sam sokolik wrote: > >> that is odd because the threading is done at about 16ipm - and the max > >> velocity of the axis is 30ipm... (you can see the z velocity goes > >> higher than 16ipm in the plots) > >> > >> If there is anything els

Re: [Emc-developers] Hardware testing for improved spindle tracking jitter (issue 164)

sam.com/images/KandT/testing/robthreading/current1.png > http://electronicsam.com/images/KandT/testing/robthreading/robnew.png > > Also - rob - it prints in axis every pass velocity at line 8 is 230rpm > or such.. (paraphrasing..) > > sam > > > On 09/25/2016 07:47 AM, Robe

Re: [Emc-developers] Hardware testing for improved spindle tracking jitter (issue 164)

50 John Kasunich wrote: > > > On Wed, Sep 28, 2016, at 09:35 PM, Robert Ellenberg wrote: > > > That would certainly be convenient. What if we took it one step > > > further and automatically limit the maximum spindle speed for each > > > G33 segment? It would be ugl

Re: [Emc-developers] Hardware testing for improved spindle tracking jitter (issue 164)

reter error, so the user gets some advance notice. By the time the motion starts, it could be too late to save the thread. Rob On Thu, Sep 29, 2016, 11:32 AM Gene Heskett wrote: > On Thursday 29 September 2016 08:49:50 John Kasunich wrote: > > > On Wed, Sep 28, 2016, at 09:35

Re: [Emc-developers] Hardware testing for improved spindle tracking jitter (issue 164)

That would certainly be convenient. What if we took it one step further and automatically limit the maximum spindle speed for each G33 segment? It would be ugly, but we may be able to stuff a spindle speed command into the queue before adding the line segment. Combined with a message to the user th

Re: [Emc-developers] Hardware testing for improved spindle tracking jitter (issue 164)

On Wed, Sep 28, 2016 at 8:41 PM andy pugh wrote: > On 29 September 2016 at 01:36, andy pugh wrote: > > > > > I approve of this warning, definitely. > > Given that (as far as I can guess) nobody ever prefers to make a bad > > thread than no thread, could the warning abort all motion? > > > > (Sup

Re: [Emc-developers] Hardware testing for improved spindle tracking jitter (issue 164)

atible changes to the 2.7 TP. -Rob On Mon, Sep 26, 2016 at 10:32 AM Gene Heskett wrote: > On Monday 26 September 2016 08:22:23 Robert Ellenberg wrote: > > > Hi Kirk, > > > > The best way to compare would be Z acceleration. It's easy to add to > > the HAL

Re: [Emc-developers] Hardware testing for improved spindle tracking jitter (issue 164)

> On 09/25/2016 04:46 PM, Robert Ellenberg wrote: > > Hi Kirk, > > > > Thanks for giving it a run! It is hard to tell if it's an improvement, > but > > it does look like it's tracking smoothly, It would likely help to compare > > the same run without

Re: [Emc-developers] Hardware testing for improved spindle tracking jitter (issue 164)

I'm glad that it's running well now. It would be cool to find a machine that's borderline and see if the patch makes it run smoother. On Sun, Sep 25, 2016, 8:00 PM andy pugh wrote: > On 26 September 2016 at 00:46, Robert Ellenberg wrote: > > > Thanks for giving it a

Re: [Emc-developers] Hardware testing for improved spindle tracking jitter (issue 164)

Hi Kirk, Thanks for giving it a run! It is hard to tell if it's an improvement, but it does look like it's tracking smoothly, It would likely help to compare the same run without the patch to see if the velocity jitters more. On Sun, Sep 25, 2016 at 5:41 PM Kirk Wallace wrote: > On 09/25/2016 1

Re: [Emc-developers] Hardware testing for improved spindle tracking jitter (issue 164)

build available. On Sun, Sep 25, 2016 at 11:41 AM Gene Heskett wrote: > On Sunday 25 September 2016 08:47:13 Robert Ellenberg wrote: > > > Hi All, > > > > Recently, I found a way to reduce the acceleration / velocity jitter > > during threading and tapping mot

[Emc-developers] Buildbot stalled

It looks like the buildbot is stuck on this build: http://buildbot.linuxcnc.org/buildbot/builders/.checkin/builds/4528 It's been running a test for 35 hours, and other builds queued up behind it haven't started. -Rob ---

[Emc-developers] Hardware testing for improved spindle tracking jitter (issue 164)

Hi All, Recently, I found a way to reduce the acceleration / velocity jitter during threading and tapping motions (see this issue on github and the feature/spindle-sync-jiiter-fix branch

Re: [Emc-developers] About blendmath.c

n you have finished? > > Thanks. > Jullian > > On Fri, Dec 25, 2015 at 4:00 AM, Robert Ellenberg > wrote: > > > Hi Jullian, > > > > There really should be more detailed documentation in that file, since so > > much of it is purpose-built. I used a lot of

Re: [Emc-developers] About blendmath.c

Hi Jullian, There really should be more detailed documentation in that file, since so much of it is purpose-built. I used a lot of standard techniques, but much is designed from scratch to deal with edge cases. In fact, most of the complexity in that file is due to handling preprocessing for diffe

Re: [Emc-developers] feedback in tp

That's roughly the idea, at least for arc blending. The geometry is set when the new segment is added to the queue. The TP creates a new position in 2 main steps: 1. Plan motion in 1 dimension (distance along the motion segments). This is done in tpCalculateTrapezoidalAccel and tpUpdateDist

Re: [Emc-developers] Different ABC values

Do you see this same effect on a config with trivial kinematics? If so, it would point to something within motion (likely the TP). Rob On Mon, Oct 19, 2015, 8:46 AM Jullian wrote: > May be reise is right. > > On Mon, Oct 19, 2015 at 8:40 PM, Jullian wrote: > > > I'm wrong?? > > > > On Sun, Oct

Re: [Emc-developers] normal.z=0.039370

Hi Julian, As you've discovered, the trajectory planner itself can already create arcs in an arbitrary plane. However, the interpreter and canon only support the subset that Jeff mentioned. Internally, the TP's circular arc segment is defined with a start point, end point, center point, and normal

Re: [Emc-developers] Reverse Run

awesomeness - Jeff said I should try > > reversing > > through a tool change.. > > > > It stops reversing once it backs up to the tool change location... > > > > sam > > > > On 9/8/2015 7:51 PM, Robert Ellenberg wrote: > >> Hi Kenneth, > >

Re: [Emc-developers] Reverse Run

Hi Kenneth, There's no fundamental limitation here, it's just a matter of how big we make the queue structure. It's a circular buffer, so it could be 1000 segments longer if we could afford the space. I just made it 100 segments because it seemed reasonable. For context, the stock queue is 2000 se

[Emc-developers] Tangent segment behavior for linuxcnc 2.7

Hi All, After looking into bug #424, I think I found the source of some oddly slow blends with the new TP. In some cases, blending between two nearly-tangent arcs creates a very short blend segment, and therefore a very low velocity for that segment. I have a fix for this in my github repo, and al

Re: [Emc-developers] Nurbs

Can you upload some examples? On Apr 20, 2015 8:54 AM, "John Thornton" wrote: > I had the opportunity to use nurbs as output by truetype-tracer 4 on my > plasma yesterday. The speed was 25-35 for a requested velocity of 60 > IPM. The letters were 3" tall so there is no reason for the slow speed >

Re: [Emc-developers] TP_MIN_SEGMENT_CYCLES

What that number controls is the maximum velocity of a motion segment, based on it's length. Right now, the trajectory planner has a hard restriction that it must spend at least one time step (usually 1ms) in each segment. This limitation means that we can't move more than one segment length in tha

Re: [Emc-developers] Fwd: Re: Reverse Run

particular program line, or manually invoked via MDI line). I don't have experience with this process myself, so I'm not sure how important this distinction is. On 14 April 2015 at 16:17, Robert Ellenberg wrote: > 1) "Retract-to-setpoint-on-abort" modal code. If a retract poin

Re: [Emc-developers] Fwd: Re: Reverse Run

Very interesting stuff! I have some ideas for how to implement a more EDM-appropriate reverse run mechanism based on what you describe. Here's a short list of new features we would need to address your concerns 1) "Retract-to-setpoint-on-abort" modal code. If a retract point is set, the machine wo

Re: [Emc-developers] Reverse Run

sokolik wrote: > Sounds good to me... > > I was playing with motion.tp-reverse and must not be doing it right. > (like I cannot change it from hal - but I see it change when I do it > from the gui) > > sam > > On 4/9/2015 11:37 AM, Robert Ellenberg wrote: > > Ok, ba

Re: [Emc-developers] Reverse Run

Ok, based on what everyone has said, I'm imagining the following interface: * a HAL pin to allow / disallow reverse run * a HAL pin to command reverse /forward direction (with safe state change handled by TP) * adaptive feeds of -1.0 to 0 trigger reverse run at the scaled feed rate (with safe state

Re: [Emc-developers] Reverse Run

The adaptive feed pin as direction control is a great idea, and I think I can make this work. I've got some code written towards this already. Does anyone have a GUI flavor with an adaptive feed slider? I'm looking for a quick way to test the direction-switch behavior to work out the kinks. -Rob

Re: [Emc-developers] Reverse Run

wrong, though. I'll take another look and see what I can find. > > sam > > > On 04/08/2015 07:25 PM, Robert Ellenberg wrote: > > Hi All, > > > > I've been playing around with reverse run for the last few days, and I > > think I have a crude but wo

Re: [Emc-developers] Reverse Run

People have been asking about that for a while, and I just never got around to it until now (other things going on). I thing EDM is a great application, though I'm sure there are others. On 04/08/2015 06:30 PM, andy pugh wrote: > On 9 April 2015 at 01:25, Robert Ellenberg wrote: >

[Emc-developers] Reverse Run

Hi All, I've been playing around with reverse run for the last few days, and I think I have a crude but working solution based off of 2.7. Here's a branch on my github repo that has an example (also pushed to the official repo to run on the buildbot): https://github.com/robEllenberg/linuxcnc-mirr

Re: [Emc-developers] New TP bugs?

On Sun, Mar 8, 2015 at 7:37 PM, Andrew wrote: > 2015-03-09 1:11 GMT+02:00 Robert Ellenberg : > > > Nice catch, Sam! those variables definitely should have been doubles, not > > ints. I'm not sure whether the comparison numbers Andrew posted were for > > the lines

Re: [Emc-developers] New TP bugs?

Nice catch, Sam! those variables definitely should have been doubles, not ints. I'm not sure whether the comparison numbers Andrew posted were for the lines or arcs example, but it looks like 2.7 is at least competitive. 3:04 is second place on that list! It surprises me a little that Mach3 isn't

Re: [Emc-developers] New TP bugs?

I'll take a look at this tonight. I've made a few changes to how the optimization works that may have had some unintended consequences. Blends behaving like exact stop mode sounds like what would happen if the optimization was aborted early. With any luck it will be a simple fix, since I haven't ch

Re: [Emc-developers] Interp / Motion state synchronization

On Fri, Jan 30, 2015 at 4:41 PM, Chris Radek wrote: > On Fri, Jan 30, 2015 at 03:20:03PM -0500, Robert Ellenberg wrote: > > > > The idea is basically to pack the relevant parts of the interpreter's > > active state into a minimal size "tag", and stick th

[Emc-developers] Interp / Motion state synchronization

Hi All, I've been doing some work on making the "Active G-Codes" display match between the running program and what's displayed in the GUI. I have a branch off of 2.7 with my solution to this problem: https://github.com/robEllenberg/linuxcnc-mirror/tree/feature/state-tags-2.7 The idea is basical

[Emc-developers] joints_axes6 status

Hi All, I'm curious what the current state of joints_axes6 is. I'm working on a CoreXY configuration that would really benefit from specifying limits in world space rather than joint space, so the changes in ja6 would be a great help. Is there a public discussion / development resource I can refe

Re: [Emc-developers] Found a new constraint violation...

I'm glad to see the code still holds up. I can't wait for 2.7 to roll out so we can get feedback from regular users. Thanks for keeping me in the loop! Rob On Oct 20, 2014 4:07 PM, "sam sokolik" wrote: > ok - as you can see from my screen shot I was actually running 2.6.3 > > So - I actaully

[Emc-developers] TP issue with exact stop and slow machine acceleration

Many thanks to Sam for finding this! Once again, his diligent testing has uncovered a subtle but important issue (posted here ). After some digging, it turns out that the final velocity for a seg

Re: [Emc-developers] Threading issue with new TP

t; axis has about .0003" backlash - so an audible 'thud' could be heard at > stops/reversals.. > > Great work.. > sam > > On 6/8/2014 11:10 PM, Robert Ellenberg wrote: > > Good find! I bet that bug was introduced during the overhaul of max speed > > and f

Re: [Emc-developers] Threading issue with new TP

Good find! I bet that bug was introduced during the overhaul of max speed and feed to get smoother performance with arcs. The good news is, if what I think is wrong actually is, it's a simple fix (just to make sure that if we're doing synced motion, to ignore the F-word). I'll poke around in the mo

Re: [Emc-developers] Kinematic Transformation and Trajectory Planer

The acceleration limit is along the direction of the path, rather than along a particular axis. Since the axis limits always apply, this limit only matters if it's less than what is allowed by the axes. To be honest, I'm not even sure this limit is fully implemented in the TP code, though I'd have

Re: [Emc-developers] [Emc-users] New Tajectory Planner

7;m trying. Did you push your fixes to it? > > Best regards > Julian > > > > Robert Ellenberg schrieb: > >Hi Julian, > > > >Are you using the circular-blend-arc-rc3 branch from git.linuxcnc.org? > >That's the one that's been tested and working.

Re: [Emc-developers] [Emc-users] New Tajectory Planner

Hi Julian, Are you using the circular-blend-arc-rc3 branch from git.linuxcnc.org? That's the one that's been tested and working. If you're using this branch and encounter any errors like this, can you post your config and G code that causes the error? -Rob On Wed, May 14, 2014 at 1:20 AM, Julia

Re: [Emc-developers] [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-developers] New Trajectory Planner

t; > Great work!! > sam > > On Tue, 15 Apr 2014 13:02:01 -0400 > Robert Ellenberg wrote: > > That's a possibility, I just did a quick diff of 2.5 and master and don't > > see any changes to the ARC_FEED function (other than a few renames). > > > > >

Re: [Emc-developers] New Trajectory Planner

That's a possibility, I just did a quick diff of 2.5 and master and don't see any changes to the ARC_FEED function (other than a few renames). On Tue, Apr 15, 2014 at 10:06 AM, Chris Radek wrote: > On Tue, Apr 15, 2014 at 01:21:07AM -0400, Robert Ellenberg wrote: > > Well,

Re: [Emc-developers] New Trajectory Planner

Oh well, I suppose I shouldn't be too surprised, I only had time to go through a few programs last night. Is this test program in the usual place? If so, I'll be able to run it again tonight or tomorrow morning and see what's up. At least we're making incremental progress! Rob

Re: [Emc-developers] New Trajectory Planner

hed.. > >> http://imagebin.org/305525 > >> > >> (z velocity is peaking at 74ipm - set for 60ipm) > >> On 04/14/2014 02:09 PM, sam sokolik wrote: > >>> when I ran the config that had all the axis constraints the same > (132ipm > >>> and 30in/s^2) it ran

Re: [Emc-developers] New Trajectory Planner

much effect at all on the run time as it is > pretty sporadic) > > http://imagebin.org/305472 > > sam > > > On 04/14/2014 09:27 AM, Robert Ellenberg wrote: > > Hi Sam, > > > > Thanks for tracking this down. Based on your data here, I did a little > > in

Re: [Emc-developers] New Trajectory Planner

th the velocities all the same (2.2in/s^2) > > http://imagebin.org/305052 > > > > here is with velocities and acc all the same > > http://imagebin.org/305054 > > > > sam > > > > > > > > > > On 04/10/2014 10:21 PM, Robert Ellen

Re: [Emc-developers] Unit conversions in Canon

g and arithmetic. Defining operators and possibly storing a unit variable could shrink those 9-line blocks down to a single, clear operation. -Rob On Apr 10, 2014 3:52 PM, "Chris Radek" wrote: > > On Thu, Apr 10, 2014 at 03:09:33PM -0400, Robert Ellenberg wrote: > > > &g

Re: [Emc-developers] New Trajectory Planner

astebin.ca/2694169 > > dad always seems to be right > > sam > > > > On 03/28/2014 06:40 PM, Robert Ellenberg wrote: > > It turned out that the max feed override defaulted to zero if not set in > > the INI, which caused the velocity to be set to zero. I added a

[Emc-developers] Unit conversions in Canon

Just had a thought about the canon layer. It would be really nice if CANON_POSITION was unit-aware: typedef struct { double axis[9]; (or just 9 doubles) unit_t lin_unit; unit_t ang_unit; } CANON_POSITION; unit_t would be an enum representing each known unit (in, mm, deg, rad, sec, cm,

Re: [Emc-developers] Possibly dumb question about NML buffer size

Since linuxcnc works with a queue depth of 1, increasing above > that max msg size (15k I think) does nothing. Go below the max message > size, and linuxcnc doesn't work. > > > -Original Message- > > From: Robert Ellenberg [mailto:rwe...@gmail.com] > &

[Emc-developers] Possibly dumb question about NML buffer size

Hi All, Is there a hard limit on the size of the NML buffers defined in linuxcnc.nml? If not, does anyone know if increasing the buffer size leads to a performance hit on a modern PC? I couldn't find much info on how the channel buffer sizes were chosen on the web. Thanks, Rob ---

Re: [Emc-developers] New Trajectory Planner

It turned out that the max feed override defaulted to zero if not set in the INI, which caused the velocity to be set to zero. I added a default value here that seems to fix that test. Also, I think the ripple issue is fixed (I moved the vLimit check to always be called in the function that calcula

  1   2   3   >