Re: [Emc-developers] call for maintainers for keystick and mini guis

[EBo]

On Dec 21 2015 11:10 PM, Chris Morley wrote:
>> To: emc-developers@lists.sourceforge.net
>> From: dgarr...@panix.com
>> Date: Tue, 22 Dec 2015 04:33:57 +
>> Subject: Re: [Emc-developers] call for maintainers for keystick and 
>> mini guis
>>
>>
>
>> It doesn't seem productive or motivational to ask users wanting
>> a joints_axes merge to wait to accommodate fixing and updating
>> code that no one uses.
>>
>
> I tend to agree. I would humbly suggest:
> - pulling it out (as you did)
> - leave it out when merging JA to master
> - at that point if someone feels they want it, it can be added again.
>
> I'm a little afraid we will release too soon after JA is merged.
> or the opposite have to wait 2 more years to fix all the little bugs.
> The sooner JA is merged the better (I'm sure you know that).
> I'm willing to bet as soon as it's merged more people will work on 
> it.
> Thanks for your diligent and determined work!

the problem as always is identifying code that no one uses.

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

Re: [Emc-developers] call for maintainers for keystick and mini guis

[Chris Morley]

Well that seems easy in this case. It's been seriously broken for 6 years.not a 
peep from anyone.

Chris M

- Reply message -
From: "EBo" 
To: 
Subject: [Emc-developers] call for maintainers for keystick and mini guis
Date: Tue, Dec 22, 2015 1:02 AM


On Dec 21 2015 11:10 PM, Chris Morley wrote:
>> To: emc-developers@lists.sourceforge.net
>> From: dgarr...@panix.com
>> Date: Tue, 22 Dec 2015 04:33:57 +
>> Subject: Re: [Emc-developers] call for maintainers for keystick and
>> mini guis
>>
>>
>
>> It doesn't seem productive or motivational to ask users wanting
>> a joints_axes merge to wait to accommodate fixing and updating
>> code that no one uses.
>>
>
> I tend to agree. I would humbly suggest:
> - pulling it out (as you did)
> - leave it out when merging JA to master
> - at that point if someone feels they want it, it can be added again.
>
> I'm a little afraid we will release too soon after JA is merged.
> or the opposite have to wait 2 more years to fix all the little bugs.
> The sooner JA is merged the better (I'm sure you know that).
> I'm willing to bet as soon as it's merged more people will work on
> it.
> Thanks for your diligent and determined work!

the problem as always is identifying code that no one uses.

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

Re: [Emc-developers] call for maintainers for keystick and mini guis

[Dave Caroline]

Dont forget the if it aint broke principle, some users will not have
upgraded therefore not found it, even some providers get to a working
setup and stick to that version.

eg http://www.sherline.com/8400pg.htm still states EMC2

Dave Caroline

On 22/12/2015, Chris Morley  wrote:
>
> Well that seems easy in this case. It's been seriously broken for 6
> years.not a peep from anyone.
>
> Chris M
>
> - Reply message -
> From: "EBo" 
> To: 
> Subject: [Emc-developers] call for maintainers for keystick and mini guis
> Date: Tue, Dec 22, 2015 1:02 AM
>
>
> On Dec 21 2015 11:10 PM, Chris Morley wrote:
>>> To: emc-developers@lists.sourceforge.net
>>> From: dgarr...@panix.com
>>> Date: Tue, 22 Dec 2015 04:33:57 +
>>> Subject: Re: [Emc-developers] call for maintainers for keystick and
>>> mini guis
>>>
>>>
>>
>>> It doesn't seem productive or motivational to ask users wanting
>>> a joints_axes merge to wait to accommodate fixing and updating
>>> code that no one uses.
>>>
>>
>> I tend to agree. I would humbly suggest:
>> - pulling it out (as you did)
>> - leave it out when merging JA to master
>> - at that point if someone feels they want it, it can be added again.
>>
>> I'm a little afraid we will release too soon after JA is merged.
>> or the opposite have to wait 2 more years to fix all the little bugs.
>> The sooner JA is merged the better (I'm sure you know that).
>> I'm willing to bet as soon as it's merged more people will work on
>> it.
>> Thanks for your diligent and determined work!
>
> the problem as always is identifying code that no one uses.
>
> --
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
> --
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] call for maintainers for keystick and mini guis

[andy pugh]

On 22 December 2015 at 04:33, Dewey Garrett  wrote:

>Who uses the linuxcnclcd gui?

I looked at that briefly, I am not sure that it ever worked.
It's almost a fun idea, and I guess it _might_ find a use an a very
special-purpose machine.
(It is a GUI for a 4x20 LCD with 4 buttons, IIRC)

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

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

Re: [Emc-developers] call for maintainers for keystick and mini guis

[EBo]

Actually, that is the rule and not the exception.  Most people see I 
know see no reason to upgrade LCNC/EMC2 until some feature comes along 
they CANNOT live without, or until they upgrade their hardware and it 
requires them to go in and update the config.  You stabalize a setup, 
learn to work around it's quirks, and then keep it that way until 
something dies...  My current running (work) machine is still running 
2.5.0, and I only plan on upgrading that one after I get the new mill 
retrofitted and running.  The real question is who is currently using 
keystick and mini and wants it moving forward.  I would say more telling 
is that the can has been kicked around now for days/weeks and only one 
person said they would look at it...

On Dec 22 2015 2:46 AM, Dave Caroline wrote:
> Dont forget the if it aint broke principle, some users will not have
> upgraded therefore not found it, even some providers get to a working
> setup and stick to that version.
>
> eg http://www.sherline.com/8400pg.htm still states EMC2
>
> Dave Caroline
>
> On 22/12/2015, Chris Morley  wrote:
>>
>> Well that seems easy in this case. It's been seriously broken for 6
>> years.not a peep from anyone.
>>
>> Chris M
>>
>> - Reply message -
>> From: "EBo" 
>> To: 
>> Subject: [Emc-developers] call for maintainers for keystick and mini 
>> guis
>> Date: Tue, Dec 22, 2015 1:02 AM
>>
>>
>> On Dec 21 2015 11:10 PM, Chris Morley wrote:
 To: emc-developers@lists.sourceforge.net
 From: dgarr...@panix.com
 Date: Tue, 22 Dec 2015 04:33:57 +
 Subject: Re: [Emc-developers] call for maintainers for keystick 
 and
 mini guis


>>>
 It doesn't seem productive or motivational to ask users wanting
 a joints_axes merge to wait to accommodate fixing and updating
 code that no one uses.

>>>
>>> I tend to agree. I would humbly suggest:
>>> - pulling it out (as you did)
>>> - leave it out when merging JA to master
>>> - at that point if someone feels they want it, it can be added 
>>> again.
>>>
>>> I'm a little afraid we will release too soon after JA is merged.
>>> or the opposite have to wait 2 more years to fix all the little 
>>> bugs.
>>> The sooner JA is merged the better (I'm sure you know that).
>>> I'm willing to bet as soon as it's merged more people will work on
>>> it.
>>> Thanks for your diligent and determined work!
>>
>> the problem as always is identifying code that no one uses.

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

Re: [Emc-developers] call for maintainers for keystick and mini guis

[EBo]

On Dec 22 2015 3:46 AM, andy pugh wrote:
> On 22 December 2015 at 04:33, Dewey Garrett  
> wrote:
>
>>Who uses the linuxcnclcd gui?
>
> I looked at that briefly, I am not sure that it ever worked.
> It's almost a fun idea, and I guess it _might_ find a use an a very
> special-purpose machine.
> (It is a GUI for a 4x20 LCD with 4 buttons, IIRC)

almost sounds like a 3D printer like a MendleMax...

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

Re: [Emc-developers] call for maintainers for keystick and mini guis

[andy pugh]

On 22 December 2015 at 10:50, EBo  wrote:
>> (It is a GUI for a 4x20 LCD with 4 buttons, IIRC)
>
> almost sounds like a 3D printer like a MendleMax...

Indeed. Ideal for situations when you want to hide the fact there is a
PC inside.

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

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

Re: [Emc-developers] jerk limited trajectory

[Yishin Li]

On Tue, Dec 22, 2015 at 1:59 PM, Chris Morley 
wrote:

>
>
> > To: emc-developers@lists.sourceforge.net
> > From: marius.alks...@gmail.com
> > Date: Tue, 22 Dec 2015 06:11:23 +0200
> > Subject: Re: [Emc-developers] jerk limited trajectory
> >
> > 12/17/2015 05:40 PM, Viesturs Lācis rašė:
> > ...
> > > IIRC it has not been implemented in LinuxCNC, because it would not
> > > work for spindle-synchronised moves, but I might be totally wrong on
> > > that :))
> > >
> > >
> > > Viesturs
> >
> > I see jerk limitation as very nice and important feature to have.
> > And I would go with a workaround like disabling jerk limitation only
> > when doing spindle-synchronised move (or whatever else rarely used type
> > of move) to let it work for the mainstream.
> >
> > BTW, limit4 would be great too :)
> >
>
> That version of jerk-limited just didn't quite work right with
> spindle-synch.
> IIRC the person doing it didn't need spindle-synch and got little help -
> lost interest.
> Not that i blame him - it looks very difficult!
>
> Our Jerk limitation implementation is on-going at:
https://github.com/araisrobo/machinekit/tree/rpi2-spi

It is with spindle synchronizing for a wood lathe machine:
https://youtu.be/_3v9xDF-2nY

We are trying a new approach to apply trajectory planning for spindle, i.e.
treat spindle like an axis. Still lots of work to be done.

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

Re: [Emc-developers] call for maintainers for keystick and mini guis

[Gene Heskett]

On Tuesday 22 December 2015 04:46:35 Dave Caroline wrote:

> Dont forget the if it aint broke principle, some users will not have
> upgraded therefore not found it, even some providers get to a working
> setup and stick to that version.

Let me put my toothpick sized oar into this water.

There is always that, and I for one fail to understand the logic behind 
that other than the inconvenience and quite nominal cost perhaps of 
stringing the cat5/6 it takes to network the machines to the houses 
hub/switch.

I can't imagine doing without it. When I sit down to write or run code, 
the first thing I do is spend nominally 5 minutes running synaptic to 
make sure I have the latest LCNC, 2 or 3 times a week in some cases.

Running 2.7.3 sim here, and 2.8-pre on the working machines because I 
can, no 2.8-pre so far has created a problem for me that wasn't 99.9% 
PEBKAC, and I have learned several new techniques that in the long view, 
have shrunk the time from concept to working code when the code, except 
the output translation from eagle & pcb-gcode, comes entirely from my 
mind and fingers, although often with help from arcbuddy and its git and 
cousins.

In any event if someone useing the removed interfaces does decide to 
update and finds that dynasoar missing, I think rather than scrambling 
to make the old code run again, we should extend all the help and advice 
needed in making the switch to the newer gui's as painless for them as 
it is possible to do. I personally started with the tkinter based gui 
because thats what the first BDI install setup.  But I was not more than 
a week switching to axis when it was announced, and I have no looked 
back at the tkinter blue screen with any hint of nostalgia.

> eg http://www.sherline.com/8400pg.htm still states EMC2

That page has to be obsolete by at least half a decade as no linux will 
now run with only 256 megs of ram, and run well.  It is also Sherlines 
responsibility I think.

> Dave Caroline
>
> On 22/12/2015, Chris Morley  wrote:
> > Well that seems easy in this case. It's been seriously broken for 6
> > years.not a peep from anyone.
> >
> > Chris M
> >
> > - Reply message -
> > From: "EBo" 
> > To: 
> > Subject: [Emc-developers] call for maintainers for keystick and mini
> > guis Date: Tue, Dec 22, 2015 1:02 AM
> >
> > On Dec 21 2015 11:10 PM, Chris Morley wrote:
> >>> To: emc-developers@lists.sourceforge.net
> >>> From: dgarr...@panix.com
> >>> Date: Tue, 22 Dec 2015 04:33:57 +
> >>> Subject: Re: [Emc-developers] call for maintainers for keystick
> >>> and mini guis
> >>>
> >>>
> >>>
> >>> It doesn't seem productive or motivational to ask users wanting
> >>> a joints_axes merge to wait to accommodate fixing and updating
> >>> code that no one uses.
> >>
> >> I tend to agree. I would humbly suggest:
> >> - pulling it out (as you did)
> >> - leave it out when merging JA to master
> >> - at that point if someone feels they want it, it can be added
> >> again.
> >>
> >> I'm a little afraid we will release too soon after JA is merged.
> >> or the opposite have to wait 2 more years to fix all the little
> >> bugs. The sooner JA is merged the better (I'm sure you know that).
> >> I'm willing to bet as soon as it's merged more people will work on
> >> it.
> >> Thanks for your diligent and determined work!
> >
> > the problem as always is identifying code that no one uses.

Haven't we already had the 6 years you quoted, to identify what no one is 
acutally using on a day to day basis? ISTM thats more than long enough.

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)
Some mill pix are at:
Genes Web page 

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

Re: [Emc-developers] jerk limited trajectory

[TJoseph Powderly]

Yishin hello
Am I right to think you want to be able to turn spindle to any degree?
like G01 C35.678   ?

In sink Edm we do not spin the tool but use
C axis on end of Z to orient tool ( electrode) to workpiece (mold cavity).

Sometimes...
we do use as spindle, but for sink edm it is slow compared to
milling machine. IIRC the highest speeds are near 100rpm,
even with tiny diameter tools ( <.01 mm dia ), At higher rpm's
the spark does not form correctly.

Your work is always interesting, thank you.

TomP

On 12/22/2015 06:26 AM, Yishin Li wrote:
> On Tue, Dec 22, 2015 at 1:59 PM, Chris Morley 
> wrote:
>
>>
>>> To: emc-developers@lists.sourceforge.net
>>> From: marius.alks...@gmail.com
>>> Date: Tue, 22 Dec 2015 06:11:23 +0200
>>> Subject: Re: [Emc-developers] jerk limited trajectory
>>>
>>> 12/17/2015 05:40 PM, Viesturs Lācis rašė:
>>> ...
 IIRC it has not been implemented in LinuxCNC, because it would not
 work for spindle-synchronised moves, but I might be totally wrong on
 that :))


 Viesturs
>>> I see jerk limitation as very nice and important feature to have.
>>> And I would go with a workaround like disabling jerk limitation only
>>> when doing spindle-synchronised move (or whatever else rarely used type
>>> of move) to let it work for the mainstream.
>>>
>>> BTW, limit4 would be great too :)
>>>
>> That version of jerk-limited just didn't quite work right with
>> spindle-synch.
>> IIRC the person doing it didn't need spindle-synch and got little help -
>> lost interest.
>> Not that i blame him - it looks very difficult!
>>
>> Our Jerk limitation implementation is on-going at:
> https://github.com/araisrobo/machinekit/tree/rpi2-spi
>
> It is with spindle synchronizing for a wood lathe machine:
> https://youtu.be/_3v9xDF-2nY
>
> We are trying a new approach to apply trajectory planning for spindle, i.e.
> treat spindle like an axis. Still lots of work to be done.
>
> -Yishin
> --
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers


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

Re: [Emc-developers] call for maintainers for keystick and mini guis

[EBo]

On Dec 22 2015 4:13 AM, andy pugh wrote:
> On 22 December 2015 at 10:50, EBo  wrote:
>>> (It is a GUI for a 4x20 LCD with 4 buttons, IIRC)
>>
>> almost sounds like a 3D printer like a MendleMax...
>
> Indeed. Ideal for situations when you want to hide the fact there is 
> a
> PC inside.

I will be working with Yishin's code on RPi.  There are situations 
where something with an embedded controller is desirable.  We just have 
to identify a integration path to make that more reasonable.  I know 
Yishin has gone through some pain trying to integrate his code into 
LCNC's main branch.  He has some brilliant stuff there.  It is a bit of 
a shame that he had to move over to machinekit to get it integrated.

Anyway, I look forward to working with his stuff in the near future.

   EBo --


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

Re: [Emc-developers] jerk limited trajectory

[Jon Elson]

On 12/21/2015 11:59 PM, Chris Morley wrote:
>
> That version of jerk-limited just didn't quite work right 
> with spindle-synch. IIRC the person doing it didn't need 
> spindle-synch and got little help - lost interest. Not 
> that i blame him - it looks very difficult!
Yes, I think combining jerk limiting with spindle synch 
REQUIRES a compromise.  There are probably a couple ways to 
do it.  One is to just turn off jerk limiting when in 
spindle synch.  The other is to warn users that there is 
some initial part of the motion which will not be fully 
synched to the spindle, until the jerk limit has been 
integrated out.  This latter scheme will break taps on 
spindle reversal, so doesn't seem like the right approach.  
Maybe somebody else knows a better way?

Jon

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

Re: [Emc-developers] call for maintainers for keystick and mini guis

[Jon Elson]

On 12/22/2015 03:37 AM, Chris Morley wrote:
> Well that seems easy in this case. It's been seriously broken for 6 years.not 
> a peep from anyone.
>
>
The problem is there MAY be users out there who still use it 
on very old EMC versions, and will have an unpleasant 
surprise if they ever update to LinuxCNC.  But, maybe the 
correct response is "we now have much better GUIs."

Jon

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

Re: [Emc-developers] jerk limited trajectory

[Viesturs Lācis]

2015-12-22 19:18 GMT+02:00 Jon Elson :
> One is to just turn off jerk limiting when in
> spindle synch.  The other is to warn users that there is
> some initial part of the motion which will not be fully
> synched to the spindle, until the jerk limit has been
> integrated out.

It seems to me that "turn off jerk limiting when in spindle synch
_and_ to warn users [about it]" is a good compromise :)

Viesturs

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

Re: [Emc-developers] jerk limited trajectory

[Chris Morley]

> Date: Tue, 22 Dec 2015 11:18:20 -0600
> From: el...@pico-systems.com
> To: emc-developers@lists.sourceforge.net
> Subject: Re: [Emc-developers] jerk limited trajectory
> 
> On 12/21/2015 11:59 PM, Chris Morley wrote:
> >
> > That version of jerk-limited just didn't quite work right 
> > with spindle-synch. IIRC the person doing it didn't need 
> > spindle-synch and got little help - lost interest. Not 
> > that i blame him - it looks very difficult!
> Yes, I think combining jerk limiting with spindle synch 
> REQUIRES a compromise.  There are probably a couple ways to 
> do it.  One is to just turn off jerk limiting when in 
> spindle synch.  The other is to warn users that there is 
> some initial part of the motion which will not be fully 
> synched to the spindle, until the jerk limit has been 
> integrated out.  This latter scheme will break taps on 
> spindle reversal, so doesn't seem like the right approach.  
> Maybe somebody else knows a better way?
> 
> Jon
> 

I've heard this argument before and it just doesn't make sense to me.
I can't figure out why one would not want to have jerk limiting.
jerk limiting allows one to define a machine command that the machine
 can actually physically perform. In fact it can allow you to raise acceleration
setting giving you more performance.
If ignoring jerk allowed better performance then ignoring acceleration should be
 even better? I don't think that would be very successful.
I mean obviously if your jerk setting is out to lunch that could be just as bad.
but I bet jerk is such a small part of machine movement that it wouldn't break 
the tap.
I say this because all linuxcnc machines out there ignore jerk and they don't 
break taps
 all the time. Though i guess one could argue that the axis has jerk anyways so 
it matches
the spindle close enough.

I am not an expert or have done the math on this - it just doesn't make sense 
to me.
I'd love to know the answer definitively!
It would be interesting to see the actual motion profile of a spindle tapping 
vrs
the actual motion profile of an axis following it vrs the commanded motion 
profile.

Interesting !

Chris M 

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

Re: [Emc-developers] jerk limited trajectory

[Peter C. Wallace]

On Tue, 22 Dec 2015, Chris Morley wrote:

> Date: Tue, 22 Dec 2015 18:25:10 +
> From: Chris Morley 
> Reply-To: EMC developers 
> To: EMC DEV 
> Subject: Re: [Emc-developers] jerk limited trajectory
> 
>
>
>> Date: Tue, 22 Dec 2015 11:18:20 -0600
>> From: el...@pico-systems.com
>> To: emc-developers@lists.sourceforge.net
>> Subject: Re: [Emc-developers] jerk limited trajectory
>>
>> On 12/21/2015 11:59 PM, Chris Morley wrote:
>>>
>>> That version of jerk-limited just didn't quite work right
>>> with spindle-synch. IIRC the person doing it didn't need
>>> spindle-synch and got little help - lost interest. Not
>>> that i blame him - it looks very difficult!
>> Yes, I think combining jerk limiting with spindle synch
>> REQUIRES a compromise.  There are probably a couple ways to
>> do it.  One is to just turn off jerk limiting when in
>> spindle synch.  The other is to warn users that there is
>> some initial part of the motion which will not be fully
>> synched to the spindle, until the jerk limit has been
>> integrated out.  This latter scheme will break taps on
>> spindle reversal, so doesn't seem like the right approach.
>> Maybe somebody else knows a better way?
>>
>> Jon
>>
>
> I've heard this argument before and it just doesn't make sense to me.
> I can't figure out why one would not want to have jerk limiting.
> jerk limiting allows one to define a machine command that the machine
> can actually physically perform. In fact it can allow you to raise 
> acceleration
> setting giving you more performance.
> If ignoring jerk allowed better performance then ignoring acceleration should 
> be
> even better? I don't think that would be very successful.
> I mean obviously if your jerk setting is out to lunch that could be just as 
> bad.
> but I bet jerk is such a small part of machine movement that it wouldn't 
> break the tap.
> I say this because all linuxcnc machines out there ignore jerk and they don't 
> break taps
> all the time. Though i guess one could argue that the axis has jerk anyways 
> so it matches
> the spindle close enough.
>
> I am not an expert or have done the math on this - it just doesn't make sense 
> to me.
> I'd love to know the answer definitively!
> It would be interesting to see the actual motion profile of a spindle tapping 
> vrs
> the actual motion profile of an axis following it vrs the commanded motion 
> profile.
>
> Interesting !
>
> Chris M

I suspect (but do not know for sure) that VFDs are slow enough at developing 
reverse torque (so are inherently low jerk) that this is not really an issue
as long as the synchronized axis jerk value is high enough to follow without 
bounding acceleration.

Of course, with a fancy spindle control (say closed loop), the spindle jerk 
could be limited.

Peter Wallace
Mesa Electronics


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

[Emc-developers] Who changed the requiered python version?

[Niemand Sonst]

Hallo,

I am working on the merge of the gmoccapy 2.0 version (5 axis) to master.
I made a fresh pull on my development machine (Ubuntu 10.04) and got 
during ./configure the error

Python Version too old (2.7 or newer requiered)

When did this change happen?
We do lock out all users with the very stable and good looking UBUNTU 10.04!

So I stop now and go to vacations first, as I do not like this behavior, 
without being announced in advance!

Norbert

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

Re: [Emc-developers] jerk limited trajectory

[EBo]

On Dec 22 2015 10:18 AM, Jon Elson wrote:
> On 12/21/2015 11:59 PM, Chris Morley wrote:
>>
>> That version of jerk-limited just didn't quite work right
>> with spindle-synch. IIRC the person doing it didn't need
>> spindle-synch and got little help - lost interest. Not
>> that i blame him - it looks very difficult!
> Yes, I think combining jerk limiting with spindle synch
> REQUIRES a compromise.  There are probably a couple ways to
> do it.  One is to just turn off jerk limiting when in
> spindle synch.  The other is to warn users that there is
> some initial part of the motion which will not be fully
> synched to the spindle, until the jerk limit has been
> integrated out.  This latter scheme will break taps on
> spindle reversal, so doesn't seem like the right approach.
> Maybe somebody else knows a better way?

I think there are at least two issues here:

*) thread turning -- where the spindle is already in motion and you 
want to sync up to chase a thread.  Here you do not care about 
acceleration profiles of the tool (as long as you have enough room to 
sync them).

*) coordinating the spindle with full start/stop motion control.

In either case, once you get everything moving you can keep them 
synchronized to a stop and reverse.  One the other hand, if you are 
chasing threads, then you might want to back the threading tool out and 
leave the spindle running a full speed.

As a note, this discussion totally ignores large machines which can be 
broken or worn when moving without jerk limits.  I have never worked on 
a machine that big, but when a friend was working on one of the NRAO's 
VLA radio antennas .  Those thigns are three 
stories TALL!

   EBo --


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

Re: [Emc-developers] Who changed the requiered python version?

[Niemand Sonst]

OK I installed python 3.1
Same error

I made: alias python=python3
Same error

I made: sudo update-alternatives -- install /usr/bin/python 
/usr/bin/python2   10
Same error

What now?

3.1 is newer than 2.7!

from a frustrated Norbert

Am 22.12.2015 um 20:26 schrieb Niemand Sonst:
> Hallo,
>
> I am working on the merge of the gmoccapy 2.0 version (5 axis) to master.
> I made a fresh pull on my development machine (Ubuntu 10.04) and got
> during ./configure the error
>
> Python Version too old (2.7 or newer requiered)
>
> When did this change happen?
> We do lock out all users with the very stable and good looking UBUNTU 10.04!
>
> So I stop now and go to vacations first, as I do not like this behavior,
> without being announced in advance!
>
> Norbert
>
> --
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>


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

Re: [Emc-developers] Who changed the requiered python version?

[EBo]

I cannot speak to the testing script, but I will say that there are a 
handful of changes that need to be done to make 2.7 code run in 3.0+.  I 
doubt that LCNC will run on any python3 interrupter (and would be happy 
to be proven wrong).

That said, we really should get all the python scripts running in 2.7 
and 3.4 as they are the most stable.

EBo --


On Dec 22 2015 12:39 PM, Niemand Sonst wrote:
> OK I installed python 3.1
> Same error
>
> I made: alias python=python3
> Same error
>
> I made: sudo update-alternatives -- install /usr/bin/python
> /usr/bin/python2   10
> Same error
>
> What now?
>
> 3.1 is newer than 2.7!
>
> from a frustrated Norbert
>
> Am 22.12.2015 um 20:26 schrieb Niemand Sonst:
>> Hallo,
>>
>> I am working on the merge of the gmoccapy 2.0 version (5 axis) to 
>> master.
>> I made a fresh pull on my development machine (Ubuntu 10.04) and got
>> during ./configure the error
>>
>> Python Version too old (2.7 or newer requiered)
>>
>> When did this change happen?
>> We do lock out all users with the very stable and good looking 
>> UBUNTU 10.04!
>>
>> So I stop now and go to vacations first, as I do not like this 
>> behavior,
>> without being announced in advance!
>>
>> Norbert
>>
>> 
>> --
>> ___
>> Emc-developers mailing list
>> Emc-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-developers
>>
>
>
> 
> --
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers


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

Re: [Emc-developers] jerk limited trajectory

[Yishin Li]

On Tue, Dec 22, 2015 at 9:54 PM, TJoseph Powderly  wrote:

> Yishin hello
> Am I right to think you want to be able to turn spindle to any degree?
> like G01 C35.678   ?
>
> Yes, we use G33.2 to position spindle in any degree within 360. Because,
after M3S200 for a while, it's not easy to use G1 to position spindle at
any degree without modifying tpAddLine().

= G33.2, Absolute Spindle Positioning within 360 degree
* spindle positioning where spindle may be mapped as A/B/C axis
* Spindle must be on; and its speed must be 0 (M3S0)
* usage: G33.2 A[ABSOLUTE_ANGLE] K[RPM]
 move spindle to ABSOLUTE_ANGLE with RPM speed

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

Re: [Emc-developers] Who changed the requiered python version?

[Chris Morley]

Norbert you must use 2.7 or change the requirements back to 2.6.
3.x is a very different animal.
This change was because it was decided to drop 10.04 for master.
basically you can't develop master with Ubuntu 10.04 anymore.
If you didn't happen to see the discussion in IRC I guess you didn't 
need to know. :(
I'm gonna try mint soon - Debian is too annoying for use on my main 
laptop (the one I do most everything on).

Chris M

> To: emc-developers@lists.sourceforge.net
> From: nie...@web.de
> Date: Tue, 22 Dec 2015 20:39:33 +0100
> Subject: Re: [Emc-developers] Who changed the requiered python version?
> 
> OK I installed python 3.1
> Same error
> 
> I made: alias python=python3
> Same error
> 
> I made: sudo update-alternatives -- install /usr/bin/python 
> /usr/bin/python2   10
> Same error
> 
> What now?
> 
> 3.1 is newer than 2.7!
> 
> from a frustrated Norbert
> 
> Am 22.12.2015 um 20:26 schrieb Niemand Sonst:
> > Hallo,
> >
> > I am working on the merge of the gmoccapy 2.0 version (5 axis) to master.
> > I made a fresh pull on my development machine (Ubuntu 10.04) and got
> > during ./configure the error
> >
> > Python Version too old (2.7 or newer requiered)
> >
> > When did this change happen?
> > We do lock out all users with the very stable and good looking UBUNTU 10.04!
> >
> > So I stop now and go to vacations first, as I do not like this behavior,
> > without being announced in advance!
> >
> > Norbert
> >
> > --
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
> >
> 
> 
> --
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
  
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Who changed the requiered python version?

[Sebastian Kuzminsky]

On 12/22/15 1:10 PM, Chris Morley wrote:
> This change was because it was decided to drop 10.04 for master.
> basically you can't develop master with Ubuntu 10.04 anymore.
> If you didn't happen to see the discussion in IRC I guess you didn't
> need to know. :(

Jeff proposed it on the emc-developers list in September:
> I am happy to postpone this plan by a release cycle if a developer plans
> to maintain 10.04 compatibility during the current release cycle.  If
> you plan to do that, please speak up.

Here's the full email:

http://article.gmane.org/gmane.linux.distributions.emc.devel/15246


-- 
Sebastian Kuzminsky

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

Re: [Emc-developers] Who changed the requiered python version?

[Chris Morley]

I stand corrected and apologize for my quip. I just didn't remember this at 
all.and I do understand it needs to happen.
1004 is just so nice to use :)

Chris M

- Reply message -
From: "Sebastian Kuzminsky" 
To: "EMC developers" 
Subject: [Emc-developers] Who changed the requiered python version?
Date: Tue, Dec 22, 2015 12:23 PM


On 12/22/15 1:10 PM, Chris Morley wrote:
> This change was because it was decided to drop 10.04 for master.
> basically you can't develop master with Ubuntu 10.04 anymore.
> If you didn't happen to see the discussion in IRC I guess you didn't
> need to know. :(

Jeff proposed it on the emc-developers list in September:
> I am happy to postpone this plan by a release cycle if a developer plans
> to maintain 10.04 compatibility during the current release cycle.  If
> you plan to do that, please speak up.

Here's the full email:

http://article.gmane.org/gmane.linux.distributions.emc.devel/15246


--
Sebastian Kuzminsky

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

Re: [Emc-developers] Who changed the requiered python version?

[Jeff Epler]

> Date: Tue, 29 Sep 2015 15:43:16 -0500
> From: Jeff Epler 
> To: emc-developers@lists.sourceforge.net
> Subject: [Emc-developers] LinuxCNC operating system support in master branch 
> / for eventual LinuxCNC 2.8
>
> For LinuxCNC 2.7 we produce packages for
> Ubuntu 10.04 "Lucid Lynx" (rtai realtime)
> Ubuntu 12.04 "Precise Pangolin" (rtai realtime)
> Debian 7.x "Wheezy" (rtai and rt-preempt realtime)
> Debian 8.x "Jessie" (rt-preempt realtime)
> 
> Canonical's extended release cycle for Ubuntu 10.04 has now ended.
> 
> In addition, I have identified two benefits from dropping support for
> Ubuntu 10.04 in the master branch, meaning that the oldest OSes that
> would be supported in the 2.8 release would be Ubuntu 12.04 and Debian
> 7.x.
> 
>  - The LD_PRELOAD workaround for the libgl bug can be dropped
>  - The minimum Python version requirement can be increased to 2.7.
> 
> The second benefit is the major one -- Python 2.7.x has a lot of items
> that can ease the porting process to Python3.  Because Python 2.7 has
> end-of-life in 2020, and our release cycle is frequently greater than 1
> year, we need to start this process soon.
> 
> I am happy to postpone this plan by a release cycle if a developer plans
> to maintain 10.04 compatibility during the current release cycle.  If
> you plan to do that, please speak up.
> 
> Jeff
http://mid.gmane.org/20150929204315.GB63865%40unpythonic.net

(the process of python3 porting alluded to in that message has not started at
all)

Jeff

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

Re: [Emc-developers] jerk limited trajectory

[Jon Elson]

On 12/22/2015 12:25 PM, Chris Morley wrote:
> jerk limiting allows one to define a machine command that 
> the machine can actually physically perform. In fact it 
> can allow you to raise acceleration setting giving you 
> more performance.
Yes, I see your point!  Actually, what I was referring to 
was during the spindle reversal.  Especially on a lathe, due 
to the inertia of the chuck, violent reversals of the 
spindle are actually impossible.  So, the spindle's 
rotational inertia makes jerk MECHANICALLY impossible.

So, the only place there could be jerk is when the Z axis 
first slaves to the spindle.  This can lead to sudden 
accelerations, but LinuxCNC seems to be fairly well behaved 
in this condition.

But, of course, the whole problem with spindle-synched 
motion is that the motion CAN'T be pre-computed, it has to 
be forced to line up with the spindle index in real time.  
That makes things just a bit more complicated.

Jon

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

Re: [Emc-developers] jerk limited trajectory

[andy pugh]

On 23 December 2015 at 02:02, Jon Elson  wrote:
> So, the spindle's
> rotational inertia makes jerk MECHANICALLY impossible.

I don't think that there is a mechanical limit on jerk.

This is why you stumble when a tube train stops hard.

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

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

Re: [Emc-developers] jerk limited trajectory

[Jon Elson]

On 12/22/2015 09:33 PM, andy pugh wrote:
> On 23 December 2015 at 02:02, Jon Elson  wrote:
>> So, the spindle's
>> rotational inertia makes jerk MECHANICALLY impossible.
> I don't think that there is a mechanical limit on jerk.
>
> This is why you stumble when a tube train stops hard.
>
Ahh, well, that's why I am NOT a math major!

Jon

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

Re: [Emc-developers] call for maintainers for keystick and mini guis

[Jeff Epler]

I believe I've fixed keystick on 2.6, and I've also cherry-picked
Dewey's tk8.6 fix for mini back to that branch.  I mildly tested both on
my Debian Jessie uspace laptop.

In my mind the fate of these two UIs in master branch is still in
question, and we should feel free to remove them if there is no
maintainer and the UIs are impeding progress, such as the merge of the
long-lived joints-axes projet.

Particularly in the case of keystick, we have very good evidence that
it's received limited to no use since 2009.  Mini has been usable on
every supported OS until Debian Jessie and a similar vintage of Ubuntu,
so that's less of a red flag about real-world use.

Jeff

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

Re: [Emc-developers] call for maintainers for keystick and mini guis

[EBo]

On Dec 22 2015 9:02 PM, Jeff Epler wrote:
> I believe I've fixed keystick on 2.6, and I've also cherry-picked
> Dewey's tk8.6 fix for mini back to that branch.  I mildly tested both 
> on
> my Debian Jessie uspace laptop.
>
> In my mind the fate of these two UIs in master branch is still in
> question, and we should feel free to remove them if there is no
> maintainer and the UIs are impeding progress, such as the merge of 
> the
> long-lived joints-axes projet.
>
> Particularly in the case of keystick, we have very good evidence that
> it's received limited to no use since 2009.  Mini has been usable on
> every supported OS until Debian Jessie and a similar vintage of 
> Ubuntu,
> so that's less of a red flag about real-world use.

I am begging to wonder that this thread has gotten more love than 
either keystick or mini in the last 5 years...

How about this for a proposal:

*) Jeff, post your fixes to branches named keystick and mini, and then 
orphan them until a maintainer steps up.

   EBo --


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

Re: [Emc-developers] jerk limited trajectory

[EBo]

On Dec 22 2015 8:33 PM, andy pugh wrote:
> On 23 December 2015 at 02:02, Jon Elson  
> wrote:
>> So, the spindle's
>> rotational inertia makes jerk MECHANICALLY impossible.
>
> I don't think that there is a mechanical limit on jerk.
>
> This is why you stumble when a tube train stops hard.

I like to think of what happens when I apply the breaks on a car.  It 
slows down, and if I do not let up a little near the end it grabs...  I 
think that is technically jerk.  As for applying gas, if you pop the 
clutch...

Seriously though.  The VLA example, they installed two motors (each 
feeding the opposite way, and would feed them propositionally to control 
jerk, and possibly higher order derivatives).  They told me that when 
they originally had one motor on the system, the initial impulse would 
send a shock through the entire antenna.  I could have the story wrong, 
but that is what I remember.

Back to LCNC land...  I can see this being useful for most cases, but 
not critically necessary unless I was spinning something less than a 24" 
chuck.  I only had a chance to run a machine that large once, and that 
was decades ago.

   EBo --


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