Re: [Emc-developers] S-curve

2012-05-01 Thread Joachim Franek
On Monday 30 April 2012 22:42:45 andy pugh wrote: > For my simple exact-stop and constant-speed requirements, I am > planning on an approach that says, on every servo cycle: > If I was to decrement acceleration by the max jerk from the current > velocity and acceleration, how long would it take for

Re: [Emc-developers] EMC2 RT_PREEMPT patch forward port

2012-05-01 Thread Abel Michael
Hi there, I just saw that you have resurrected the rt-preempt patches. Very very cool! I'd like to reproduce your results and help bug-fixing, but I'm not exactly sure how to patch everything together. If I've understood right this procedure might do it: 1) Follow these instructions: http://www.

Re: [Emc-developers] S-curve

2012-05-01 Thread Joachim Franek
Harmonic jerk 2: http://www.aspe.net/publications/Spring_2001/01Sp%20Extended%20Abstracts/Arevalo.PDF Joachim -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat

Re: [Emc-developers] EMC2 RT_PREEMPT patch forward port

2012-05-01 Thread Jan de Kruyf
"Ein Zimmermann am Straßenrand vergnügt die Zuschauer." they say in Holland. but also: Die Axt im Haus erspart den Zimmermann. [Friedrich Schiller: Wilhelm Tell] In other words: feel most welcome to the party. The problem seems in the porting to the present HEAD. And since you are much more know

Re: [Emc-developers] S-curve

2012-05-01 Thread Joachim Franek
Harmonic jerk 3: http://cdn.intechopen.com/pdfs/4267/InTech-On_algorithms_for_planning_s_curve_motion_profiles.pdf Harmonic compares to 5th order: see fig. 10. Joachim -- Live Security Virtual Conference Exclusive live

Re: [Emc-developers] NURBS a la Yi-shin

2012-05-01 Thread Spiderdab
Il giorno lun, 30/04/2012 alle 19.55 -0500, sam sokolik ha scritto: > http://linuxcnc.org/docs/2.5/html/gcode/gcode.html#_g5_2_g5_3_nurbs_block_a_id_sec_g5_2_g5_3_nurbs_a > > Sounds like testing would be good > No, Yi-shin was talking about three-dimensional nurbs. I'm interested too in trying th

Re: [Emc-developers] NURBS a la Yi-shin

2012-05-01 Thread Viesturs Lācis
2012/5/1 Spiderdab <77...@tiscali.it>: > Il giorno lun, 30/04/2012 alle 19.55 -0500, sam sokolik ha scritto: >> http://linuxcnc.org/docs/2.5/html/gcode/gcode.html#_g5_2_g5_3_nurbs_block_a_id_sec_g5_2_g5_3_nurbs_a >> >> Sounds like testing would be good >> > No, Yi-shin was talking about three-dimen

Re: [Emc-developers] EMC2 RT_PREEMPT patch forward port

2012-05-01 Thread Charles Steinkuehler
On 5/1/2012 5:09 AM, Abel Michael wrote: > Hi there, > > I just saw that you have resurrected the rt-preempt patches. > Very very cool! > > I'd like to reproduce your results and help bug-fixing, but I'm not > exactly sure how to patch everything together. > If I've understood right this procedur

Re: [Emc-developers] NURBS a la Yi-shin

2012-05-01 Thread Spiderdab
Il giorno mar, 01/05/2012 alle 15.56 +0300, Viesturs Lācis ha scritto: > 2012/5/1 Spiderdab <77...@tiscali.it>: > > Il giorno lun, 30/04/2012 alle 19.55 -0500, sam sokolik ha scritto: > >> http://linuxcnc.org/docs/2.5/html/gcode/gcode.html#_g5_2_g5_3_nurbs_block_a_id_sec_g5_2_g5_3_nurbs_a > >> > >>

Re: [Emc-developers] NURBS a la Yi-shin

2012-05-01 Thread Joachim Franek
Has some one tried this code from page 6? http://158.110.28.100/amst08/papers/art837759.pdf Joachim -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape

Re: [Emc-developers] NURBS a la Yi-shin

2012-05-01 Thread Viesturs Lācis
2012/5/1 Spiderdab <77...@tiscali.it>: > Il giorno mar, 01/05/2012 alle 15.56 +0300, Viesturs Lācis ha scritto: >> 2012/5/1 Spiderdab <77...@tiscali.it>: >> > Il giorno lun, 30/04/2012 alle 19.55 -0500, sam sokolik ha scritto: >> >> http://linuxcnc.org/docs/2.5/html/gcode/gcode.html#_g5_2_g5_3_nurb

Re: [Emc-developers] NURBS a la Yi-shin

2012-05-01 Thread EBo
On Tue, 1 May 2012 15:56:09 +0300, Viesturs Lācis wrote: > > Rhino is the only drawing/designing application I know of that works > with Nurbs. ... K3-D and Blender also works with NURBS, and I've seen some rumblings in the Art of Illusion community suggestion a working NURBS implementation...

Re: [Emc-developers] NURBS a la Yi-shin

2012-05-01 Thread dave
On Tue, 01 May 2012 11:48:15 -0400 EBo wrote: > On Tue, 1 May 2012 15:56:09 +0300, Viesturs Lācis wrote: > > > > Rhino is the only drawing/designing application I know of that works > > with Nurbs. ... > > K3-D and Blender also works with NURBS, and I've seen some rumblings > in the Art of Illus

Re: [Emc-developers] NURBS a la Yi-shin

2012-05-01 Thread Lars Segerlund
Vendor specific extensions, check this out. http://books.google.se/books?id=c_-3TxZlnpMC&pg=PA61&lpg=PA61&dq=fanuc+G-code+NURBS&source=bl&ots=PWeZbXOOqA&sig=NAPRDGrYpXRngHEfTqISbdkGmrc&hl=en&sa=X&ei=Kg6gT6PNIaXe4QSO28GNAw&redir_esc=y#v=onepage&q=fanuc%20G-code%20NURBS&f=false Fanuc ... is 'fai

Re: [Emc-developers] NURBS a la Yi-shin

2012-05-01 Thread Viesturs Lācis
2012/5/1 Lars Segerlund : > Vendor specific extensions, check this out. > >  http://books.google.se/books?id=c_-3TxZlnpMC&pg=PA61&lpg=PA61&dq=fanuc+G-code+NURBS&source=bl&ots=PWeZbXOOqA&sig=NAPRDGrYpXRngHEfTqISbdkGmrc&hl=en&sa=X&ei=Kg6gT6PNIaXe4QSO28GNAw&redir_esc=y#v=onepage&q=fanuc%20G-code%20NUR

Re: [Emc-developers] S-curve: my summary

2012-05-01 Thread Joachim Franek
Look at http://www.roymech.co.uk/Useful_Tables/Maths/fourier/Maths_Fourier_transforms.html and compare the fourier transform of: 1. top hat (sinc) 2. triangle (sinc^2) 3. gauss (gauss) trapezoidal is inbetween top hat and triangle. for accaleration function 1. top hat: jerc is unboundet 2. triang

Re: [Emc-developers] S-curve: my summary

2012-05-01 Thread Kenneth Lerman
My understanding of the goal is that it is to have a minimum time subject to certain constraints. The current constraints in LinuxCNC are to have certain acceleration and velocity limits. It has been suggested that it would also be appropriate to limit the jerk. Doing so could only make the tim

[Emc-developers] Questions Re: The Jerk Limitation Problem in LinuxCNC

2012-05-01 Thread Kenneth Lerman
Hello all, There have been a large number of emails flying around concerning this subject. In order to understand where this fits into LinuxCNC, I would like to understand some things: 1 -- Where does this fit into the current (or future) design of LinuxCNC? 2 -- If I were to build a function

Re: [Emc-developers] S-curve: my summary

2012-05-01 Thread dave
On Tue, 01 May 2012 14:11:15 -0400 Kenneth Lerman wrote: > My understanding of the goal is that it is to have a minimum time > subject to certain constraints. > > The current constraints in LinuxCNC are to have certain acceleration > and velocity limits. It has been suggested that it would also

Re: [Emc-developers] Questions Re: The Jerk Limitation Problem in LinuxCNC

2012-05-01 Thread andy pugh
On 1 May 2012 19:24, Kenneth Lerman wrote: > 2 -- If I were to build a function (or package of functions) to solve > the problem, what would its interface look like? I would have imagined an [AXIS_N] MAX_JERK entry in the INI file. Is there any reason that it wouldn't be that simple? -- atp Th

Re: [Emc-developers] Questions Re: The Jerk Limitation Problem in LinuxCNC

2012-05-01 Thread Joachim Franek
My first contribution is the summary, I just wrote. From this summary the recommandation follows: invest your working time in a solution with sinusoidal time function (or something similar). BTW: do you know another approximation function to gaussian with limited time unequal zero? My second cont

Re: [Emc-developers] S-curve: my summary

2012-05-01 Thread Joachim Franek
On Tuesday 01 May 2012 20:11:15 Kenneth Lerman wrote: > My understanding of the goal is that it is to have a minimum time > subject to certain constraints. > > The current constraints in LinuxCNC are to have certain acceleration and > velocity limits. It has been suggested that it would also b

Re: [Emc-developers] Questions Re: The Jerk Limitation Problem in LinuxCNC

2012-05-01 Thread Joachim Franek
On Tuesday 01 May 2012 21:04:47 andy pugh wrote: > On 1 May 2012 19:24, Kenneth Lerman wrote: > > > 2 -- If I were to build a function (or package of functions) to solve > > the problem, what would its interface look like? > > I would have imagined an [AXIS_N] MAX_JERK entry in the INI file. I

Re: [Emc-developers] S-curve: my summary

2012-05-01 Thread Viesturs Lācis
2012/5/1 Joachim Franek : > >> For a >> variety of reasons (smaller error, less vibration, ...), some commercial >> machines add such constraints. >> >> I suggest that if enhance LinuxCNC to add the jerk constraints, that >> will be sufficient to "compete" with commercial solutions. > > This depend

Re: [Emc-developers] S-curve: my summary

2012-05-01 Thread Joachim Franek
On Tuesday 01 May 2012 21:50:32 Viesturs Lācis wrote: > 2012/5/1 Joachim Franek : > > If I understand this discussion correctly, then jerk limit can be set > to very high number, so the machine would behave very similarly as if > jerk was not limited at all. > > Viesturs Look for example to 4267

[Emc-developers] RFC: 'queuebusters' and a new method for parameter synchronization

2012-05-01 Thread Michael Haberler
on #linuxcnc-devel there's currently a discussion (mostly cradek and me in the last few days) about a future linuxcnc design. In that context, 'queuebusters' and the synchronization of interpreter state came up. I think I came up with a more elegant, flexible and language independent solution t

Re: [Emc-developers] S-curve: my summary

2012-05-01 Thread Alexey Starikovskiy
It is all good looking in theory, but how do you transfer this information to the servo drive? As I understand, now we have all calculations of trajectory done in servo thread with repeat rate equal to ~1kHz. This means that we calculate new data points for drive (either acceleration or velocity) o

Re: [Emc-developers] RFC: 'queuebusters' and a new method for parameter synchronization

2012-05-01 Thread Viesturs Lācis
2012/5/1 Michael Haberler : > on #linuxcnc-devel there's currently a discussion (mostly cradek and me in > the last few days) about a future linuxcnc design. In that context, > 'queuebusters' and the synchronization of interpreter state came up. > > I think I came up with a more elegant, flexible

Re: [Emc-developers] RFC: 'queuebusters' and a new method for parameter synchronization

2012-05-01 Thread Michael Haberler
Am 01.05.2012 um 22:35 schrieb Viesturs Lācis: > 2012/5/1 Michael Haberler : >> on #linuxcnc-devel there's currently a discussion (mostly cradek and me in >> the last few days) about a future linuxcnc design. In that context, >> 'queuebusters' and the synchronization of interpreter state came u

Re: [Emc-developers] RFC: 'queuebusters' and a new method for parameter synchronization

2012-05-01 Thread Viesturs Lācis
2012/5/2 Michael Haberler : > > The background was the following: we discussed changes which would permit > changing tool offset and cutter radius during a pause operation. > > Under the current scheme, this would mean: > > - the handling of parameters 5400-5413 needs to be changed in the > inter

Re: [Emc-developers] RFC: 'queuebusters' and a new method for parameter synchronization

2012-05-01 Thread Michael Haberler
Am 01.05.2012 um 23:22 schrieb Viesturs Lācis: > 2012/5/2 Michael Haberler : >> >> The background was the following: we discussed changes which would permit >> changing tool offset and cutter radius during a pause operation. >> >> Under the current scheme, this would mean: >> >> - the handlin

Re: [Emc-developers] NURBS a la Yi-shin

2012-05-01 Thread EBo
On Tue, 1 May 2012 09:08:00 -0700, dave wrote: > > Synergy has b-splines and NURBS but exports G1's. That could change > is > there were a standard format to export as G-code. can you provide a link to Synergy? -- Live S

Re: [Emc-developers] NURBS a la Yi-shin

2012-05-01 Thread dave
On Tue, 01 May 2012 18:12:23 -0500 EBo wrote: > On Tue, 1 May 2012 09:08:00 -0700, dave wrote: > > > > Synergy has b-splines and NURBS but exports G1's. That could change > > is > > there were a standard format to export as G-code. > > can you provide a link to Synergy? > Sure: http:/

Re: [Emc-developers] EMC2 RT_PREEMPT patch forward port

2012-05-01 Thread John Morris
Hi Abel and Charles, On 05/01/2012 07:34 AM, Charles Steinkuehler wrote: >> I just saw that you have resurrected the rt-preempt patches. >> Very very cool! Yes, very cool! I feared nobody would be interested, since the patches have languished so long, but there's been quite a lot of interest, a

Re: [Emc-developers] NURBS a la Yi-shin

2012-05-01 Thread Spiderdab
Il giorno mar, 01/05/2012 alle 17.02 +0300, Viesturs Lācis ha scritto: > 2012/5/1 Spiderdab <77...@tiscali.it>: > > Il giorno mar, 01/05/2012 alle 15.56 +0300, Viesturs Lācis ha scritto: > >> 2012/5/1 Spiderdab <77...@tiscali.it>: > >> > Il giorno lun, 30/04/2012 alle 19.55 -0500, sam sokolik ha sc

Re: [Emc-developers] EMC2 RT_PREEMPT patch forward port

2012-05-01 Thread John Morris
> Only other modifications to the instructions, since we're now working > with HEAD, be sure to s/emc/linuxcnc/g. Oops, emc-environment becomes rip-environment, not linuxcnc-environment. ;) John -- Live Securit

Re: [Emc-developers] RFC: 'queuebusters' and a new method for parameter synchronization

2012-05-01 Thread Viesturs Lācis
2012/5/2 Michael Haberler : > > Assuing that existed: when you hit 'Pause' and 'switch to MDI', the following > things need to happen: > > - The currently executing trajectory planner queue in motion is put to rest, > as is the executing task+interpreter instance (note I explored some of this >

Re: [Emc-developers] S-curve: my summary

2012-05-01 Thread Joachim Franek
On Tuesday 01 May 2012 22:21:50 Alexey Starikovskiy wrote: > It is all good looking in theory, but how do you transfer this > information to the servo drive? > As I understand, now we have all calculations of trajectory done in > servo thread with repeat > rate equal to ~1kHz. This means that we

Re: [Emc-developers] S-curve: my summary

2012-05-01 Thread Viesturs Lācis
2012/5/1 Alexey Starikovskiy : > It is all good looking in theory, but how do you transfer this > information to the servo drive? If I understand correctly the question, then that is "mission impossible 5" to implement jerk limitation in the feedback loop, closed by servo drive, because AFAIK almo