Enhanced Machine Controller

Nice post John, 

As you can tell I'm not a stepper fan. There has been too much 
gnashing of teeth on this list about steppers to make me feel 
very comfortable with them. The only place I ever used a stepper 
motor was the wavelength drive on a Cary 16 spectrophotometer.
The stepper switches were driven directly off a PDP-11 parallel 
interface, not exactly the same thing as a parallel port on a 
pc. Guess  that dates me. 

I do think that the hardware assist, in terms of a pulse 
dispenser, cures a lot of the stepper drive problems. 

I do believe that if one need performance then servos will get 
one there faster than trying to implement steppers. 

Dave



On Wednesday 17 March 2004 08:04 am, jmkasunich@... wrote:
> David A. Frantz wrote:
> > As you point out how fast you move an axis and how well it
> > moves are two different things.    Given the mechanical
> > capability to do so would a faster PC not help with your
> > tracking?    I do not believe that a simple answer on CPU
> > speed can be had, a number of things need to be taken into
> > account; including the number of axis, types of instructions
> > being executed and system resolution.
>
> There are a number of factors that determine how fast and
> smooth a software generated step pulse train can be.  The main
> one is jitter - how repeatable the execution of the realtime
> code is.  If the code wants to run every 20uS, the RTOS will
> program the PC's hardware timer to generate an interrupt every
> 20uS.  But if on one interrupt the actual step code starts
> running right away, and on the next interrupt the interrupt
> response is delayed for 4uS because the OS has disabled
> interrupts, and then it takes another 2uS to load the step
> code into cache, then you will have 6uS of jitter.  Instead of
> running every 20uS, the code runs at 20, 26, 14, 22, 18, 21,
> etc.  That randomness messes up the pulse train.
>
> A faster CPU helps to a certain extent, but not as much as you
> might expect. Jitter is often determined by hardware things
> like the frontside bus, cache, and other interrupts, rather
> than by raw CPU speed.
>
> Of course if the CPU is so slow that it simply _can't_ run the
> step generation code in 20uS, then you have a real problem. 
> You have to slow the thread down, perhaps to 30, or 50uS. 
> That will reduce the maximum step rate that you can generate. 
> In theory a faster CPU might let you reduce the period to 15uS
> or even less, but as you go faster and faster, jitter becomes
> even more important and raw speed makes little difference.
>
> The ultimate solution is to get rid of that 20uS realtime task
> by either using analog servo, or by generating step pulses
> with external hardware.  Then you have a much slower servo
> thread, running perhaps every 1mS, or every 500uS. A few uS of
> jitter on the servo thread does little or no harm.
>
> EMC can work both ways - software generated step pulses for
> low cost at moderate step rates, and external step pulses or
> analog servo for top performance but with more expensive
> external hardware.
>
> Regards,
>
> John Kasunich
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and
> CEO of GenToo technologies. Learn everything from fundamentals
> to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&o
>p=click _______________________________________________
> Emc-users mailing list
> Emc-users@...
> https://lists.sourceforge.net/lists/listinfo/emc-users

Hi,

Can you give me any tips on how to set up emc to 
generate the step pulses externally?
Does it send out a relative position count every servo
cycle to the parallel port?
Does it require modifying source code or just config changes?

I'd like to program a dsp to do the time critical and PID stuff.
I've used Motorola's dsp56800 hybrid dsp's before.
They're fast and very easy to use because they have built in 
hardware support for quadrature encoders etc.

Thank you,

Mike Loser





jmkasunich@...
Sent by: emc-users-admin@...
03/17/2004 10:04 AM
Please respond to emc-users

 
        To:     emc-users@...
        cc: 
        Subject:        Re: [Emc-users] Latest version


David A. Frantz wrote:

> As you point out how fast you move an axis and how well it moves are two
> different things.    Given the mechanical capability to do so would a
> faster PC not help with your tracking?    I do not believe that a simple
> answer on CPU speed can be had, a number of things need to be taken into
> account; including the number of axis, types of instructions being
> executed and system resolution.

There are a number of factors that determine how fast and smooth a 
software
generated step pulse train can be.  The main one is jitter - how 
repeatable
the execution of the realtime code is.  If the code wants to run every 
20uS,
the RTOS will program the PC's hardware timer to generate an interrupt 
every
20uS.  But if on one interrupt the actual step code starts running right
away, and on the next interrupt the interrupt response is delayed for 4uS
because the OS has disabled interrupts, and then it takes another 2uS to 
load
the step code into cache, then you will have 6uS of jitter.  Instead of
running every 20uS, the code runs at 20, 26, 14, 22, 18, 21, etc.  That
randomness messes up the pulse train.

A faster CPU helps to a certain extent, but not as much as you might 
expect.
Jitter is often determined by hardware things like the frontside bus, 
cache,
and other interrupts, rather than by raw CPU speed.

Of course if the CPU is so slow that it simply _can't_ run the step 
generation
code in 20uS, then you have a real problem.  You have to slow the thread 
down,
perhaps to 30, or 50uS.  That will reduce the maximum step rate that you 
can
generate.  In theory a faster CPU might let you reduce the period to 15uS 
or
even less, but as you go faster and faster, jitter becomes even more 
important
and raw speed makes little difference.

The ultimate solution is to get rid of that 20uS realtime task by either 
using
analog servo, or by generating step pulses with external hardware.  Then 
you
have a much slower servo thread, running perhaps every 1mS, or every 
500uS.
A few uS of jitter on the servo thread does little or no harm.

EMC can work both ways - software generated step pulses for low cost at
moderate step rates, and external step pulses or analog servo for top
performance but with more expensive external hardware.

Regards,

John Kasunich


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Emc-users mailing list
Emc-users@...
https://lists.sourceforge.net/lists/listinfo/emc-users



American Express made the following
 annotations on 03/17/2004 12:09:12 PM
------------------------------------------------------------------------------
******************************************************************************

     "This message and any attachments are solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any disclosure, copying, use, or distribution of the information included in this message and any attachments is prohibited.  If you have received this communication in error, please notify us by reply e-mail and immediately and permanently delete this message and any attachments.  Thank you."

******************************************************************************


==============================================================================

Mike Loser wrote:

> Can you give me any tips on how to set up emc to 
> generate the step pulses externally? Does it send
> out a relative position count every servo cycle 
> to the parallel port? Does it require modifying 
> source code or just config changes? 

Depends on the hardware you intend to use to generate
the step pulses.  Jon Elson's Universal Stepper Controller
is one choice, he already has an EMC driver for it, so
no source code changes should be needed.
His webpage is at http://pico-systems.com/univstep.html
Contact Jon for details and help.

I think there are other options as well, but I'm less
familiar with them.

> I'd like to program a dsp to do the time critical
> and PID stuff. I've used Motorola's dsp56800 hybrid
> dsp's before. They're fast and very easy to use because
> they have built in hardware support for quadrature 
> encoders etc. 

Sounds like a bit of re-inventing to me, but that's OK.

If you do that you will certainly need to hack ECM source
code to interface to your DSP.  We are currently working 
on a significant addition to EMC called HAL (hardware
abstraction layer) that is intended to make interfacing
to hardware more modular and hopefully easier.

Regards,

John Kasunich

Hi again,

Interesting answers from all of you guys, but I'm still looking for some
answer on my two main questions. ;-)
What is the latest known kernel version I can get it running on, and can =
I
probe with EMC? I can't find any clear answers about any of these two.

--S

-----Ursprungligt meddelande-----
Fr=E5n: emc-users-admin@...
[mailto:emc-users-admin@... jmkasunich@...
Skickat: den 17 mars 2004 21:17
Till: emc-users@...
=C4mne: Re: [Emc-users] Latest version


Mike Loser wrote:

> Can you give me any tips on how to set up emc to
> generate the step pulses externally? Does it send
> out a relative position count every servo cycle
> to the parallel port? Does it require modifying
> source code or just config changes?

Depends on the hardware you intend to use to generate
the step pulses.  Jon Elson's Universal Stepper Controller
is one choice, he already has an EMC driver for it, so
no source code changes should be needed.
His webpage is at http://pico-systems.com/univstep.html
Contact Jon for details and help.

I think there are other options as well, but I'm less
familiar with them.

> I'd like to program a dsp to do the time critical
> and PID stuff. I've used Motorola's dsp56800 hybrid
> dsp's before. They're fast and very easy to use because
> they have built in hardware support for quadrature
> encoders etc.

Sounds like a bit of re-inventing to me, but that's OK.

If you do that you will certainly need to hack ECM source
code to interface to your DSP.  We are currently working
on a significant addition to EMC called HAL (hardware
abstraction layer) that is intended to make interfacing
to hardware more modular and hopefully easier.

Regards,

John Kasunich


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
_______________________________________________
Emc-users mailing list
Emc-users@...
https://lists.sourceforge.net/lists/listinfo/emc-users

Hi Sven;

Sorry to mis the mark as far as the answers go!

The issue with the kernel is dynamic and depends on which realtime=20
extension you use and where that extension is revision wise.   To that=20
end if you want answers related to the kernel it might be best to ask on=20
one of the realtime kernel lists.    Otherwise I'd just get the latest=20
BDI image and use the kernel there.

Last I knew the RTLinux patch was one release behond the stable kernel=20
releases.    Stable indicates 2.4.XX not 2.6.XX.   RTAI form the latest=20
indication I got is a couple of months away from a 2.6 patch, as far as=20
RTLinux I have no idea where they are with a 2.6 patch.

Thanks
Dave


Sven-=C5ke Larsson wrote:

>Hi again,
>
>Interesting answers from all of you guys, but I'm still looking for some
>answer on my two main questions. ;-)
>What is the latest known kernel version I can get it running on, and can=
 I
>probe with EMC? I can't find any clear answers about any of these two.
>
>--S
>
>-----Ursprungligt meddelande-----
>Fr=E5n: emc-users-admin@...
>[mailto:emc-users-admin@... jmkasunich@...
>Skickat: den 17 mars 2004 21:17
>Till: emc-users@...
>=C4mne: Re: [Emc-users] Latest version
>
>
>Mike Loser wrote:
>
> =20
>
>>Can you give me any tips on how to set up emc to
>>generate the step pulses externally? Does it send
>>out a relative position count every servo cycle
>>to the parallel port? Does it require modifying
>>source code or just config changes?
>>   =20
>>
>
>Depends on the hardware you intend to use to generate
>the step pulses.  Jon Elson's Universal Stepper Controller
>is one choice, he already has an EMC driver for it, so
>no source code changes should be needed.
>His webpage is at http://pico-systems.com/univstep.html
>Contact Jon for details and help.
>
>I think there are other options as well, but I'm less
>familiar with them.
>
> =20
>
>>I'd like to program a dsp to do the time critical
>>and PID stuff. I've used Motorola's dsp56800 hybrid
>>dsp's before. They're fast and very easy to use because
>>they have built in hardware support for quadrature
>>encoders etc.
>>   =20
>>
>
>Sounds like a bit of re-inventing to me, but that's OK.
>
>If you do that you will certainly need to hack ECM source
>code to interface to your DSP.  We are currently working
>on a significant addition to EMC called HAL (hardware
>abstraction layer) that is intended to make interfacing
>to hardware more modular and hopefully easier.
>
>Regards,
>
>John Kasunich
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials
>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>GenToo technologies. Learn everything from fundamentals to system
>administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcl=
ick
>_______________________________________________
>Emc-users mailing list
>Emc-users@...
>https://lists.sourceforge.net/lists/listinfo/emc-users
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials
>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>GenToo technologies. Learn everything from fundamentals to system
>administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dclick
>_______________________________________________
>Emc-users mailing list
>Emc-users@...
>https://lists.sourceforge.net/lists/listinfo/emc-users
>
>
> =20
>

Hi John;

While Jitter is certianly an issue the servo update loop speed is also a 
factor.    Five years ago I was working on CNC lathes with sub us update 
rates.    I actually had the good fortune to talk to the engineer 
responsible for the DSP card that drove the system, he insisted that the 
update rate was need to do what they where doing.   Since at the time I 
had considerable experience with various diamond turning technologies, I 
had to believe him as his equipment had rather impressive abilities to 
interpolate radius and maintain surface finish.

Now I fully realize that a gantry type machine is a different animal 
than a diamond turining lathe cutting optical parts, but I would suspect 
that at some point the update rate will impact the abiltiy to further 
increase a systems performance.    If his system can actually hit 400 
ipm,  a 20us update rate will probally do, but I do wonder how much 
faster he would be able to to go and still keep the resultant quality 
high.   On the type of machine being discussed I would think mechanical 
issues would be huge before controls issue becmae a problem, but then 
agian I've not worked on that type of equipment.

Also I'm not convinced that a one milli second update rate would be 
suitable for any CNC machine doing any sort of interpolation unless a 
rather loose end result is suitable.    I geuss this depends somewhat I 
what one wants to accomplish with the system.


Thanks
Dave

jmkasunich@... wrote:

>David A. Frantz wrote:
>
>  
>
>>As you point out how fast you move an axis and how well it moves are two 
>>different things.    Given the mechanical capability to do so would a 
>>faster PC not help with your tracking?    I do not believe that a simple 
>>answer on CPU speed can be had, a number of things need to be taken into 
>>account; including the number of axis, types of instructions being 
>>executed and system resolution.
>>    
>>
>
>There are a number of factors that determine how fast and smooth a software
>generated step pulse train can be.  The main one is jitter - how repeatable
>the execution of the realtime code is.  If the code wants to run every 20uS,
>the RTOS will program the PC's hardware timer to generate an interrupt every
>20uS.  But if on one interrupt the actual step code starts running right 
>away, and on the next interrupt the interrupt response is delayed for 4uS 
>because the OS has disabled interrupts, and then it takes another 2uS to load
>the step code into cache, then you will have 6uS of jitter.  Instead of
>running every 20uS, the code runs at 20, 26, 14, 22, 18, 21, etc.  That 
>randomness messes up the pulse train.
>
>A faster CPU helps to a certain extent, but not as much as you might expect.
>Jitter is often determined by hardware things like the frontside bus, cache,
>and other interrupts, rather than by raw CPU speed.
>
>Of course if the CPU is so slow that it simply _can't_ run the step generation
>code in 20uS, then you have a real problem.  You have to slow the thread down,
>perhaps to 30, or 50uS.  That will reduce the maximum step rate that you can
>generate.  In theory a faster CPU might let you reduce the period to 15uS or
>even less, but as you go faster and faster, jitter becomes even more important
>and raw speed makes little difference.
>
>The ultimate solution is to get rid of that 20uS realtime task by either using
>analog servo, or by generating step pulses with external hardware.  Then you
>have a much slower servo thread, running perhaps every 1mS, or every 500uS.
>A few uS of jitter on the servo thread does little or no harm.
>
>EMC can work both ways - software generated step pulses for low cost at 
>moderate step rates, and external step pulses or analog servo for top
>performance but with more expensive external hardware.
>
>Regards,
>
>John Kasunich
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials
>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>GenToo technologies. Learn everything from fundamentals to system
>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>_______________________________________________
>Emc-users mailing list
>Emc-users@...
>https://lists.sourceforge.net/lists/listinfo/emc-users
>
>
>  
>

Hello Sven.

Yes, you can do probing with EMC.

For more info, see
http://www.linuxcnc.org/handbook/part2/probe1.html

***Ray - this is on linuxcnc.org, but doesn't seem to
be in the newer manual on sourceforge?!***

Mark

--- Sven-Åke_Larsson <sven@...> wrote:
> Hi again,
> 
> Interesting answers from all of you guys, but I'm
> still looking for some
> answer on my two main questions. ;-)
> What is the latest known kernel version I can get it
> running on, and can I
> probe with EMC? I can't find any clear answers about
> any of these two.
> 
> --S
> 
> -----Ursprungligt meddelande-----
> Från: emc-users-admin@...
> [mailto:emc-users-admin@...
> jmkasunich@...
> Skickat: den 17 mars 2004 21:17
> Till: emc-users@...
> Ämne: Re: [Emc-users] Latest version
> 
> 
> Mike Loser wrote:
> 
> > Can you give me any tips on how to set up emc to
> > generate the step pulses externally? Does it send
> > out a relative position count every servo cycle
> > to the parallel port? Does it require modifying
> > source code or just config changes?
> 
> Depends on the hardware you intend to use to
> generate
> the step pulses.  Jon Elson's Universal Stepper
> Controller
> is one choice, he already has an EMC driver for it,
> so
> no source code changes should be needed.
> His webpage is at
> http://pico-systems.com/univstep.html
> Contact Jon for details and help.
> 
> I think there are other options as well, but I'm
> less
> familiar with them.
> 
> > I'd like to program a dsp to do the time critical
> > and PID stuff. I've used Motorola's dsp56800
> hybrid
> > dsp's before. They're fast and very easy to use
> because
> > they have built in hardware support for quadrature
> > encoders etc.
> 
> Sounds like a bit of re-inventing to me, but that's
> OK.
> 
> If you do that you will certainly need to hack ECM
> source
> code to interface to your DSP.  We are currently
> working
> on a significant addition to EMC called HAL
> (hardware
> abstraction layer) that is intended to make
> interfacing
> to hardware more modular and hopefully easier.
> 
> Regards,
> 
> John Kasunich
> 
> 
>
-------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux
> Tutorials
> Free Linux tutorial presented by Daniel Robbins,
> President and CEO of
> GenToo technologies. Learn everything from
> fundamentals to system
>
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Emc-users mailing list
> Emc-users@...
>
https://lists.sourceforge.net/lists/listinfo/emc-users
> 
> 
> 
>
-------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux
> Tutorials
> Free Linux tutorial presented by Daniel Robbins,
> President and CEO of
> GenToo technologies. Learn everything from
> fundamentals to system
>
administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click
> _______________________________________________
> Emc-users mailing list
> Emc-users@...
>
https://lists.sourceforge.net/lists/listinfo/emc-users


__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com

On Wednesday 17 March 2004 06:15 pm, David A. Frantz wrote:
> Hi John;
>
> While Jitter is certianly an issue the servo update loop speed
> is also a factor.    Five years ago I was working on CNC
> lathes with sub us update rates.    I actually had the good
> fortune to talk to the engineer responsible for the DSP card
> that drove the system, he insisted that the update rate was
> need to do what they where doing.   Since at the time I had
> considerable experience with various diamond turning
> technologies, I had to believe him as his equipment had rather
> impressive abilities to interpolate radius and maintain
> surface finish.
>
> Now I fully realize that a gantry type machine is a different
> animal than a diamond turining lathe cutting optical parts,
> but I would suspect that at some point the update rate will
> impact the abiltiy to further increase a systems performance. 
>   If his system can actually hit 400 ipm,  a 20us update rate
> will probally do, but I do wonder how much faster he would be
> able to to go and still keep the resultant quality high.   On
> the type of machine being discussed I would think mechanical
> issues would be huge before controls issue becmae a problem,
> but then agian I've not worked on that type of equipment.

I think you hit it on the nose! I suspect that the power of the 
servos and the response of the machine usually hits way before 
the update rate of the servo loop. I normally run at 1 KHz but 
have run at 2 KHz. I believe Jon Elson has pushed the rate to 10 
KHz with his ppmc interface. Jon stated that he had an 
interesting resonance on his BP at about 250 Hz but that is way 
above the response of the mass of the table(s). Lathes because 
of the (normally) lower mass may require or be able to use much 
higher update rates. 
I think my servo drives roll off at about 2 KHz so any rate above 
that may be problematical. 

Dave E.
>
> Also I'm not convinced that a one milli second update rate
> would be suitable for any CNC machine doing any sort of
> interpolation unless a rather loose end result is suitable.   
> I geuss this depends somewhat I what one wants to accomplish
> with the system.
>
>
> Thanks
> Dave
>
> jmkasunich@... wrote:
> >David A. Frantz wrote:
> >>As you point out how fast you move an axis and how well it
> >> moves are two different things.    Given the mechanical
> >> capability to do so would a faster PC not help with your
> >> tracking?    I do not believe that a simple answer on CPU
> >> speed can be had, a number of things need to be taken into
> >> account; including the number of axis, types of
> >> instructions being executed and system resolution.
> >
> >There are a number of factors that determine how fast and
> > smooth a software generated step pulse train can be.  The
> > main one is jitter - how repeatable the execution of the
> > realtime code is.  If the code wants to run every 20uS, the
> > RTOS will program the PC's hardware timer to generate an
> > interrupt every 20uS.  But if on one interrupt the actual
> > step code starts running right away, and on the next
> > interrupt the interrupt response is delayed for 4uS because
> > the OS has disabled interrupts, and then it takes another
> > 2uS to load the step code into cache, then you will have 6uS
> > of jitter.  Instead of running every 20uS, the code runs at
> > 20, 26, 14, 22, 18, 21, etc.  That randomness messes up the
> > pulse train.
> >
> >A faster CPU helps to a certain extent, but not as much as
> > you might expect. Jitter is often determined by hardware
> > things like the frontside bus, cache, and other interrupts,
> > rather than by raw CPU speed.
> >
> >Of course if the CPU is so slow that it simply _can't_ run
> > the step generation code in 20uS, then you have a real
> > problem.  You have to slow the thread down, perhaps to 30,
> > or 50uS.  That will reduce the maximum step rate that you
> > can generate.  In theory a faster CPU might let you reduce
> > the period to 15uS or even less, but as you go faster and
> > faster, jitter becomes even more important and raw speed
> > makes little difference.
> >
> >The ultimate solution is to get rid of that 20uS realtime
> > task by either using analog servo, or by generating step
> > pulses with external hardware.  Then you have a much slower
> > servo thread, running perhaps every 1mS, or every 500uS. A
> > few uS of jitter on the servo thread does little or no harm.
> >
> >EMC can work both ways - software generated step pulses for
> > low cost at moderate step rates, and external step pulses or
> > analog servo for top performance but with more expensive
> > external hardware.
> >
> >Regards,
> >
> >John Kasunich
> >
> >
> >-------------------------------------------------------
> >This SF.Net email is sponsored by: IBM Linux Tutorials
> >Free Linux tutorial presented by Daniel Robbins, President
> > and CEO of GenToo technologies. Learn everything from
> > fundamentals to system
> > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638
> >&op=click _______________________________________________
> >Emc-users mailing list
> >Emc-users@...
> >https://lists.sourceforge.net/lists/listinfo/emc-users
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and
> CEO of GenToo technologies. Learn everything from fundamentals
> to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&o
>p=click _______________________________________________
> Emc-users mailing list
> Emc-users@...
> https://lists.sourceforge.net/lists/listinfo/emc-users

Extended question:
The reference shows how to do a basic probe but the question remains:

Is there a way to implement a probe in a g-code file?=20
Example: set up a probe at homing position to establish a Z  reference=20
at the beginning of a procedure.

Craig

Mark Pictor wrote:

>Hello Sven.
>
>Yes, you can do probing with EMC.
>
>For more info, see
>http://www.linuxcnc.org/handbook/part2/probe1.html
>
>***Ray - this is on linuxcnc.org, but doesn't seem to
>be in the newer manual on sourceforge?!***
>
>Mark
>
>--- Sven-=C5ke_Larsson <sven@...> wrote:
> =20
>
>>Hi again,
>>
>>Interesting answers from all of you guys, but I'm
>>still looking for some
>>answer on my two main questions. ;-)
>>What is the latest known kernel version I can get it
>>running on, and can I
>>probe with EMC? I can't find any clear answers about
>>any of these two.
>>
>>--S
>>
>>-----Ursprungligt meddelande-----
>>Fr=E5n: emc-users-admin@...
>>[mailto:emc-users-admin@...
>>jmkasunich@...
>>Skickat: den 17 mars 2004 21:17
>>Till: emc-users@...
>>=C4mne: Re: [Emc-users] Latest version
>>
>>
>>Mike Loser wrote:
>>
>>   =20
>>
>>>Can you give me any tips on how to set up emc to
>>>generate the step pulses externally? Does it send
>>>out a relative position count every servo cycle
>>>to the parallel port? Does it require modifying
>>>source code or just config changes?
>>>     =20
>>>
>>Depends on the hardware you intend to use to
>>generate
>>the step pulses.  Jon Elson's Universal Stepper
>>Controller
>>is one choice, he already has an EMC driver for it,
>>so
>>no source code changes should be needed.
>>His webpage is at
>>http://pico-systems.com/univstep.html
>>Contact Jon for details and help.
>>
>>I think there are other options as well, but I'm
>>less
>>familiar with them.
>>
>>   =20
>>
>>>I'd like to program a dsp to do the time critical
>>>and PID stuff. I've used Motorola's dsp56800
>>>     =20
>>>
>>hybrid
>>   =20
>>
>>>dsp's before. They're fast and very easy to use
>>>     =20
>>>
>>because
>>   =20
>>
>>>they have built in hardware support for quadrature
>>>encoders etc.
>>>     =20
>>>
>>Sounds like a bit of re-inventing to me, but that's
>>OK.
>>
>>If you do that you will certainly need to hack ECM
>>source
>>code to interface to your DSP.  We are currently
>>working
>>on a significant addition to EMC called HAL
>>(hardware
>>abstraction layer) that is intended to make
>>interfacing
>>to hardware more modular and hopefully easier.
>>
>>Regards,
>>
>>John Kasunich
>>
>>
>>
>>   =20
>>
>-------------------------------------------------------
> =20
>
>>This SF.Net email is sponsored by: IBM Linux
>>Tutorials
>>Free Linux tutorial presented by Daniel Robbins,
>>President and CEO of
>>GenToo technologies. Learn everything from
>>fundamentals to system
>>
>>   =20
>>
>administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcl=
ick
> =20
>
>>_______________________________________________
>>Emc-users mailing list
>>Emc-users@...
>>
>>   =20
>>
>https://lists.sourceforge.net/lists/listinfo/emc-users
> =20
>
>>
>>
>>   =20
>>
>-------------------------------------------------------
> =20
>
>>This SF.Net email is sponsored by: IBM Linux
>>Tutorials
>>Free Linux tutorial presented by Daniel Robbins,
>>President and CEO of
>>GenToo technologies. Learn everything from
>>fundamentals to system
>>
>>   =20
>>
>administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dclick
> =20
>
>>_______________________________________________
>>Emc-users mailing list
>>Emc-users@...
>>
>>   =20
>>
>https://lists.sourceforge.net/lists/listinfo/emc-users
>
>
>__________________________________
>Do you Yahoo!?
>Yahoo! Mail - More reliable, more storage, less spam
>http://mail.yahoo.com
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials
>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>GenToo technologies. Learn everything from fundamentals to system
>administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcl=
ick
>_______________________________________________
>Emc-users mailing list
>Emc-users@...
>https://lists.sourceforge.net/lists/listinfo/emc-users
>
> =20
>

Being psychic, there is a message coming along soon that asks about=20
probing within a g-code program.

Yes it's in RS274NGC

-----snippet
3.5.9 Straight Probe - G38.2


3.5.9.1 The Straight Probe Command


Program G38.2 X- Y- Z- A- B- C- to perform a straight probe operation.=20
The rotational axis words are allowed, but it is better to omit them. If =

rotational axis words are used, the numbers must be the same as the=20
current position numbers so that the rotational axes do not move. The=20
linear axis words are optional, except that at least one of them must be =

used. The tool in the spindle must be a probe.


It is an error if:

=B7 the current point is less than 0.254 millimeter or 0.01 inch from the=
=20
programmed point.

=B7 G38.2 is used in inverse time feed rate mode,

=B7 any rotational axis is commanded to move,

=B7 no X, Y, or Z-axis word is used.


In response to this command, the machine moves the controlled point=20
(which should be at the end of the probe tip) in a straight line at the=20
current feed rate toward the programmed point. If the probe trips, the=20
probe is retracted slightly from the trip point at the end of command=20
execution. If the probe does not trip even after overshooting the=20
programmed point slightly, an error is signalled.


After successful probing, parameters 5061 to 5066 will be set to the=20
coordinates of the location of the controlled point at the time the=20
probe tripped.


3.5.9.2 Using the Straight Probe Command


Using the straight probe command, if the probe shank is kept nominally=20
parallel to the Z-axis (i.e., any rotational axes are at zero) and the=20
tool length offset for the probe is used, so that the controlled point=20
is at the end of the tip of the probe:

=B7 without additional knowledge about the probe, the parallelism of a=20
face of a part to the XY-plane may, for example, be found.

=B7 if the probe tip radius is known approximately, the parallelism of a =

face of a part to the YZ or XZ-plane may, for example, be found.

=B7 if the shank of the probe is known to be well-aligned with the Z-axis=
=20
and the probe tip radius is known approximately, the center of a=20
circular hole, may, for example, be found.

=B7 if the shank of the probe is known to be well-aligned with the Z-axis=
=20
and the probe tip radius is known precisely, more uses may be made of=20
the straight probe command, such as finding the diameter of a circular ho=
le.


If the straightness of the probe shank cannot be adjusted to high=20
accuracy, it is desirable to know the effective radii of the probe tip=20
in at least the +X, -X, +Y, and -Y directions. These quantities can be=20
stored in parameters either by being included in the parameter file or=20
by being set in an RS274/NGC program.


Using the probe with rotational axes not set to zero is also feasible.=20
Doing so is more complex than when rotational axes are at zero, and we=20
do not deal with it here.


3.5.9.3 Example Code


As a usable example, the code for finding the center and diameter of a=20
circular hole is shown in Table 6. For this code to yield accurate=20
results, the probe shank must be well-aligned with the Z-axis, the cross =

section of the probe tip at its widest point must be very circular, and=20
the probe tip radius (i.e., the radius of the circular cross section)=20
must be known precisely. If the probe tip radius is known only=20
approximately (but the other conditions hold), the location of the hole=20
center will still be accurate, but the hole diameter will not.


In Table 6, an entry of the form <description of number> is meant to be=20
replaced by an actual number that matches the description of number.=20
After this section of code has executed, the X-value of the center will=20
be in parameter 1041, the Y-value of the center in parameter 1022, and=20
the diameter in parameter 1034. In addition, the diameter parallel to=20
the X-axis will be in parameter 1024, the diameter parallel to the=20
Y-axis in parameter 1014, and the difference (an indicator of=20
circularity) in parameter 1035. The probe tip will be in the hole at the =

XY center of the hole.


The example does not include a tool change to put a probe in the=20
spindle. Add the tool change code at the beginning, if needed.




N010 (probe to find center and diameter of circular hole)

N020 (This program will not run as given here. You have to)

N030 (insert numbers in place of <description of number>.)

N040 (Delete lines N020, N030, and N040 when you do that.)

N050 G0 Z <Z-value of retracted position> F <feed rate>

N060 #1001=3D<nominal X-value of hole center>

N070 #1002=3D<nominal Y-value of hole center>

N080 #1003=3D<some Z-value inside the hole>

N090 #1004=3D<probe tip radius>

N100 #1005=3D[<nominal hole diameter>/2.0 - #1004]

N110 G0 X#1001 Y#1002 (move above nominal hole center)

N120 G0 Z#1003 (move into hole - to be cautious, substitute G1 for G0 her=
e)

N130 G38.2 X[#1001 + #1005] (probe +X side of hole)

N140 #1011=3D#5061 (save results)

N150 G0 X#1001 Y#1002 (back to center of hole)

N160 G38.2 X[#1001 - #1005] (probe -X side of hole)

N170 #1021=3D[[#1011 + #5061] / 2.0] (find pretty good X-value of hole ce=
nter)

N180 G0 X#1021 Y#1002 (back to center of hole)

N190 G38.2 Y[#1002 + #1005] (probe +Y side of hole)

N200 #1012=3D#5062 (save results)

N210 G0 X#1021 Y#1002 (back to center of hole)

N220 G38.2 Y[#1002 - #1005] (probe -Y side of hole)

N230 #1022=3D[[#1012 + #5062] / 2.0] (find very good Y-value of hole cent=
er)

N240 #1014=3D[#1012 - #5062 + [2 * #1004]] (find hole diameter in Y-direc=
tion)

N250 G0 X#1021 Y#1022 (back to center of hole)

N260 G38.2 X[#1021 + #1005] (probe +X side of hole)

N270 #1031=3D#5061 (save results)

N280 G0 X#1021 Y#1022 (back to center of hole)

N290 G38.2 X[#1021 - #1005] (probe -X side of hole)

N300 #1041=3D[[#1031 + #5061] / 2.0] (find very good X-value of hole cent=
er)

N310 #1024=3D[#1031 - #5061 + [2 * #1004]] (find hole diameter in X-direc=
tion)

N320 #1034=3D[[#1014 + #1024] / 2.0] (find average hole diameter)

N330 #1035=3D[#1024 - #1014] (find difference in hole diameters)

N340 G0 X#1041 Y#1022 (back to center of hole)

N350 M2 (that's all, folks)
-----end of snip

Hope this helps

Ray


Mark Pictor wrote:
> Hello Sven.
>=20
> Yes, you can do probing with EMC.
>=20
> For more info, see
> http://www.linuxcnc.org/handbook/part2/probe1.html
>=20
> ***Ray - this is on linuxcnc.org, but doesn't seem to
> be in the newer manual on sourceforge?!***
>=20
> Mark
>=20
> --- Sven-=C5ke_Larsson <sven@...> wrote:
>=20
>>Hi again,
>>
>>Interesting answers from all of you guys, but I'm
>>still looking for some
>>answer on my two main questions. ;-)
>>What is the latest known kernel version I can get it
>>running on, and can I
>>probe with EMC? I can't find any clear answers about
>>any of these two.
>>
>>--S
>>
>>-----Ursprungligt meddelande-----
>>Fr=E5n: emc-users-admin@...
>>[mailto:emc-users-admin@...
>>jmkasunich@...
>>Skickat: den 17 mars 2004 21:17
>>Till: emc-users@...
>>=C4mne: Re: [Emc-users] Latest version
>>
>>
>>Mike Loser wrote:
>>
>>
>>>Can you give me any tips on how to set up emc to
>>>generate the step pulses externally? Does it send
>>>out a relative position count every servo cycle
>>>to the parallel port? Does it require modifying
>>>source code or just config changes?
>>
>>Depends on the hardware you intend to use to
>>generate
>>the step pulses.  Jon Elson's Universal Stepper
>>Controller
>>is one choice, he already has an EMC driver for it,
>>so
>>no source code changes should be needed.
>>His webpage is at
>>http://pico-systems.com/univstep.html
>>Contact Jon for details and help.
>>
>>I think there are other options as well, but I'm
>>less
>>familiar with them.
>>
>>
>>>I'd like to program a dsp to do the time critical
>>>and PID stuff. I've used Motorola's dsp56800
>>
>>hybrid
>>
>>>dsp's before. They're fast and very easy to use
>>
>>because
>>
>>>they have built in hardware support for quadrature
>>>encoders etc.
>>
>>Sounds like a bit of re-inventing to me, but that's
>>OK.
>>
>>If you do that you will certainly need to hack ECM
>>source
>>code to interface to your DSP.  We are currently
>>working
>>on a significant addition to EMC called HAL
>>(hardware
>>abstraction layer) that is intended to make
>>interfacing
>>to hardware more modular and hopefully easier.
>>
>>Regards,
>>
>>John Kasunich
>>
>>
>>
>=20
> -------------------------------------------------------
>=20
>>This SF.Net email is sponsored by: IBM Linux
>>Tutorials
>>Free Linux tutorial presented by Daniel Robbins,
>>President and CEO of
>>GenToo technologies. Learn everything from
>>fundamentals to system
>>
>=20
> administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dc=
lick
>=20
>>_______________________________________________
>>Emc-users mailing list
>>Emc-users@...
>>
>=20
> https://lists.sourceforge.net/lists/listinfo/emc-users
>=20
>>
>>
>>
> -------------------------------------------------------
>=20
>>This SF.Net email is sponsored by: IBM Linux
>>Tutorials
>>Free Linux tutorial presented by Daniel Robbins,
>>President and CEO of
>>GenToo technologies. Learn everything from
>>fundamentals to system
>>
>=20
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dclick
>=20
>>_______________________________________________
>>Emc-users mailing list
>>Emc-users@...
>>
>=20
> https://lists.sourceforge.net/lists/listinfo/emc-users
>=20
>=20
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - More reliable, more storage, less spam
> http://mail.yahoo.com
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dc=
lick
> _______________________________________________
> Emc-users mailing list
> Emc-users@...
> https://lists.sourceforge.net/lists/listinfo/emc-users
>=20
> .
>=20

David A. Frantz wrote:

> Hi John;
>
> While Jitter is certianly an issue the servo update loop speed is also 
> a factor.    Five years ago I was working on CNC lathes with sub us 
> update rates.    I actually had the good fortune to talk to the 
> engineer responsible for the DSP card that drove the system, he 
> insisted that the update rate was need to do what they where doing.   
> Since at the time I had considerable experience with various diamond 
> turning technologies, I had to believe him as his equipment had rather 
> impressive abilities to interpolate radius and maintain surface finish.

What?  Less than a microsecond?  There has to be a mistake here.
Even the fastest DSP processors only execute 100 instructions or
so in 1 uS.  But, if the servo motor is driven by a PWM driver,
any updates to the PWM duty cycle are not going to have any
effect if it is faster than the whole PWM cycle.  Were the servo
motor drivers running PWM faster than 1 MHZ?  That is possible,
I suppose, but it still doesn't make sense.  Can the motors/leadscrews/
carriage/tools really respond with x hundred KHZ bandwidth?  That
is totally preposterous.

Ahh, diamond turning.  Well, the whole problem must be a resolution
problem, and they were using tricks with the DSP to meet the needs for
resolution when making optical mirrors.  That is a far cry from the usual
machine tools, though.

>
> Now I fully realize that a gantry type machine is a different animal 
> than a diamond turining lathe cutting optical parts, but I would 
> suspect that at some point the update rate will impact the abiltiy to 
> further increase a systems performance.    If his system can actually 
> hit 400 ipm,  a 20us update rate will probally do, but I do wonder how 
> much faster he would be able to to go and still keep the resultant 
> quality high.   On the type of machine being discussed I would think 
> mechanical issues would be huge before controls issue becmae a 
> problem, but then agian I've not worked on that type of equipment.
>
> Also I'm not convinced that a one milli second update rate would be 
> suitable for any CNC machine doing any sort of interpolation unless a 
> rather loose end result is suitable.    I geuss this depends somewhat 
> I what one wants to accomplish with the system.

HUH?  Why do you say that?  For **ANY** CNC machine?  Do you know what 
the basic
mechanical accuracy of a Sherline, Taig or Harbor Freight machine is? 
 Do people
who cut wood signs need NANOMETER precision?

Do you know any home shop types who are running their Sherlines at 400 IPM?
Do you know how much power it takes to make a sharp corner at 400 IPM on
a Bridgeport-sized machine?

I think one must match the servo control system to the rest of the machine.
If you have a 1/8 Hp servo motor moving a 400 Lb table, it is TOTAL 
nonsense to
talk about microsecond servo loops, when typically cutting at under 10 IPM
speeds.  My machine is more accurate than I can measure, most of the time,
and tool deflection is the largest source of error, by a factor of 3 to 
5.  My
servos are updated at 1 KHz, although I must add that they are true velocity
servos, and so the amps actually have a velocity bandwidth greater than 
1 KHz.
This is all meaningless, however, because the low motor torque and high 
table
mass make it impossible to respond significantly above 40 Hz or so, in the
mechanical sense.

I urge you to consider that a lot of people making their own CNC machines
are NOT doing diamond turning lathes.

Jon

Jon Elson wrote:

>
>
> David A. Frantz wrote:
>
>> Hi John;
>>
>> While Jitter is certianly an issue the servo update loop speed is 
>> also a factor.    Five years ago I was working on CNC lathes with sub 
>> us update rates.    I actually had the good fortune to talk to the 
>> engineer responsible for the DSP card that drove the system, he 
>> insisted that the update rate was need to do what they where doing.   
>> Since at the time I had considerable experience with various diamond 
>> turning technologies, I had to believe him as his equipment had 
>> rather impressive abilities to interpolate radius and maintain 
>> surface finish.
>
>
> What?  Less than a microsecond?  There has to be a mistake here.
> Even the fastest DSP processors only execute 100 instructions or
> so in 1 uS.  But, if the servo motor is driven by a PWM driver,
> any updates to the PWM duty cycle are not going to have any
> effect if it is faster than the whole PWM cycle.  Were the servo
> motor drivers running PWM faster than 1 MHZ?  That is possible,
> I suppose, but it still doesn't make sense.  Can the motors/leadscrews/
> carriage/tools really respond with x hundred KHZ bandwidth?  That
> is totally preposterous. 


Well the hardware I use to work on is gone now, as I said five years 
now, but that is how I remember it.    It could be that the servo update 
clock was giviing me information in nanoseconds, the memory does slip 
away.   I do know that at the time the card was one of the fastest 
available.    For the machines size, it had rather complex controls, the 
machine would switch between low resolution and high resolution encoders 
on the fly due to data rate and signal quality issues.   As to the 
response of the machine interesting things where done in software to 
deal with some motion compensation issues.   

I do remember that the amplifiers where made by glentek but that is 
about all now.

>
>
> Ahh, diamond turning.  Well, the whole problem must be a resolution
> problem, and they were using tricks with the DSP to meet the needs for
> resolution when making optical mirrors.  That is a far cry from the usual
> machine tools, though.
>
>>
>> Now I fully realize that a gantry type machine is a different animal 
>> than a diamond turining lathe cutting optical parts, but I would 
>> suspect that at some point the update rate will impact the abiltiy to 
>> further increase a systems performance.    If his system can actually 
>> hit 400 ipm,  a 20us update rate will probally do, but I do wonder 
>> how much faster he would be able to to go and still keep the 
>> resultant quality high.   On the type of machine being discussed I 
>> would think mechanical issues would be huge before controls issue 
>> becmae a problem, but then agian I've not worked on that type of 
>> equipment.
>>
>> Also I'm not convinced that a one milli second update rate would be 
>> suitable for any CNC machine doing any sort of interpolation unless a 
>> rather loose end result is suitable.    I geuss this depends somewhat 
>> I what one wants to accomplish with the system.
>
>
> HUH?  Why do you say that?  For **ANY** CNC machine?  Do you know what 
> the basic
> mechanical accuracy of a Sherline, Taig or Harbor Freight machine is? 
> Do people
> who cut wood signs need NANOMETER precision? 


Hi Jon;

You got me there!     One should never make absolute statements as there 
are almost an infinit number of ways to configure a system and almost an 
equal number of requirements to be filled.   Working in the optics 
industry does corrupt ones concept of acceptable tolerances, the sign 
makers are often forgotten.   On the other hand I've seen some very 
rudimentary lathe hardware hold some very tight tolerances in production 
environments, thanks to some skilled maintenance and a few key 
modifications.

>
>
> Do you know any home shop types who are running their Sherlines at 400 
> IPM?
> Do you know how much power it takes to make a sharp corner at 400 IPM on
> a Bridgeport-sized machine? 


At the moment no, but I did point out that mechanical limitations would 
be significant with the machine being discussed.    Even if one has the 
power available there is still the question of the machine responding to 
the requests.

>
>
> I think one must match the servo control system to the rest of the 
> machine.
> If you have a 1/8 Hp servo motor moving a 400 Lb table, it is TOTAL 
> nonsense to
> talk about microsecond servo loops, when typically cutting at under 10 
> IPM
> speeds.  

Yes when you are talking about those speeds, but the original poster was 
talking about "pretty high speeds", and somebody mentioned 40 times 
that.    Now admittedly nothing was discussed as far as resolution needs 
and maybe the discusion is not really worth while until the whole 
performance criteria is known.   The original post talked about a servo 
based router which could imply a number of things and a number of 
construction possibilities, so we really don't know at the moment what 
we are moving.    We don't even know what is being milled only that it 
is three D, it is obvious that the sign maker has different need from 
say somebody working in aluminum for aircraft parts.

> My machine is more accurate than I can measure, most of the time,
> and tool deflection is the largest source of error, by a factor of 3 
> to 5.  My
> servos are updated at 1 KHz, although I must add that they are true 
> velocity
> servos, and so the amps actually have a velocity bandwidth greater 
> than 1 KHz.
> This is all meaningless, however, because the low motor torque and 
> high table
> mass make it impossible to respond significantly above 40 Hz or so, in 
> the
> mechanical sense.
>
> I urge you to consider that a lot of people making their own CNC machines
> are NOT doing diamond turning lathes. 


Point well taken, when there are a number of unknowns it would be best 
to ask questions first.    I must ask though would you stay with a 1KHz 
update rate if you had a differrent arraingment of equipment or needed 
to improve your conturing operations?

>
>
> Jon
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Emc-users mailing list
> Emc-users@...
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
>

Hi Sven

To add to David's response, linux-2.4.24 is the most recent kernel you can 
expect to get working with EMC. RTAI certainly has a patch (currently running 
it here), and I believe RTLinux-GPL also has a patch.

 Whilst there is a 2.6.x patch in the latest RTAI release, I would not 
recommend using RTAI-3.0 - The EMC plat definitions need an overhaul to take 
advantage of the changes that have been made.

Regards, Paul.


On Thursday 18 March 2004 1:50 am, David A. Frantz wrote:
> Last I knew the RTLinux patch was one release behond the stable kernel
> releases.    Stable indicates 2.4.XX not 2.6.XX.   RTAI form the latest
> indication I got is a couple of months away from a 2.6 patch, as far as
> RTLinux I have no idea where they are with a 2.6 patch.

-- 

"To err is human...to really f*** things up requires the root password."
From a collection of quotes at http://www.indigo.org/quotes.html

Hi David

One addition to your snipped post below.

David A. Frantz wrote:
> For the machines size, it had rather complex controls, the 
> machine would switch between low resolution and high resolution encoders 
> on the fly due to data rate and signal quality issues.   As to the 
> response of the machine interesting things where done in software to 
> deal with some motion compensation issues.  
> I do remember that the amplifiers where made by glentek but that is 
> about all now.

We may have hit the nail on the head here by thinking about resolution 
and accuracy rather than raw computing power.

I've seen machines that do this resolution switching.  Mazak and a 
number of other Lathe manufacturers switch it between a spindle turn and 
a live tooling command.  There was also a discussion about max pulse 
train speed from encoders on CAD_CAM... a while back that suggested that 
there is a fairly low upper bound for the rate that digital encoders can 
keep up.

I suggested that we (EMC) experiment with something like that a while 
back but there are serious issues.

You say that the machine is gone now.  Resolution switching would also 
have been much easier using resolvers.  At high speeds, one would only 
need to count position when sin and cosine crossed or when one reached 
zero.  Then at lower speeds one could do finer maths.  I know that Allen 
Bradley made some "high speed" resolver counter boards for their 7360-70 
series.  These went out to several meg. (Someone will say that STG lists 
10 Meg as max but try to find an encoder that reaches that speed reliably)

Since servo velocity in that age was also an analog signal from a tach, 
there would not be velocity issues to contend with because these were 
handled in the servo amp.  It would have been in essence two counters 
working on the same signal.  That is not nearly as easy with a purely 
digital pulse and feedback train.

Most of the machinists I know would rather use older analog drive 
systems if the only concern is for surface finish.  Try putting a 0.0005 
taper in a 10 inch shaft and you'll see every encoder tick from an 
inexpensive all digital lathe.

Ray

David A. Frantz wrote:

>
>
> Point well taken, when there are a number of unknowns it would be best 
> to ask questions first.    I must ask though would you stay with a 
> 1KHz update rate if you had a differrent arraingment of equipment or 
> needed to improve your conturing operations?

It would make no sense to increase the sampling rate without increasing 
the power
of the motors/amplifiers.  I'm sure that a 1 KHz sampling rate, 
especially with
true velocity servos using tachometers for velocity feedback, is more 
than adequate
for the machine as it stands.  I am using somewhat undersized ballscrews 
(.890"
dia) from a PC board drilling machine.  They are extremely accurate 
(better than
.001" / 36" length) but not quite stiff enough for fast motion and high 
acceleration.

If I were to completely rebuild this machine, or build another, perhaps on a
BOSS foundation, it might make sense to increase the update rate.  (I 
know it
helped dramatically to go from an Allen-Bradley 7320 with 100 Hz update
to EMC with 1 KHz update.  There is also a difference in the level of servo
loop calculations, so it is not a direct comparison of rate, only.)  I 
know I could
run easily at 10 KHz with my USC or PPMC boards.

I also was playing with a prototype of a direct PWM servo control that I 
am getting
ready to display at the NAMES show in April, still at 1 KHz, and controlling
a bare motor.  I was pleasantly surprised at how well it controlled the 
motor with
no mechanical damping (and no tach).  But, then, even a fairly small 
motor of
conventional iron-rotor construction is not able to provide much of a 
response
in just a mS.

When I get this all working on a machine, I will have to see if I can 
even tell any
difference between 1 KHz and 10 KHz servo update rate.  My feeling is that
at practical velocities and encoder resolutions used in conventional milling
operations, there will be no difference.

Jon

On Thursday 13 March 2003 04:22 am, Ray Henry wrote:
> Being psychic, there is a message coming along soon that asks about
> probing within a g-code program.
>
> Yes it's in RS274NGC

There is also the emcprobe utility now checked into CVS.   I would apprec=
iate=20
any feedback from anyone who experiments with this code.   Emcprobe does =
not=20
use RS274NGC, rather it talks to emc directly using NML.

It allows you to probe "cubical" regions on a 3 axis table.   It then out=
puts=20
g-code that follows the surface contour.

I've also checked into CVS "ncutils".   These are a collection of utiliti=
es=20
for manipulating g-code files.   There are also specific utilities  for=20
merging g-code with probed surfaces.

I routinely use these utilities on a cnc wood router.  I can succesfully=20
"wrap" the truetype font g-code output from DeskEngrave onto curved surfa=
ces=20
that I've previously probed.  Backplot images of this proccess are in the=
=20
/demo directory.

To do list:

1) Better error checking, more user friendly.
2) Update emcprobe docs.
3) Add splined interpolation to emcprobe output.
4) Make another utility that calculates a rough toolpath and works down t=
o the=20
probed toolpath.
5) Mergecnc utility needs better surface mapping,  splined emcprobe outpu=
t=20
will help in this regard.

Hi all,

I was looking at a another program that was able to run some sort
of auto probing like a real measuring machine. We just put a piece 
from a modell at the table and the machine scanned the object, the output
was a file with all measuring points that we could import into our CAD program
and recreate the model. 
Extended probing question: Can I do that with EMC, how?

For fun, I'll try to install EMC on a Qnx-machine. But just for the fun. ;-)

 > Extended question:
 > The reference shows how to do a basic probe but the question remains:
 > 
 > Is there a way to implement a probe in a g-code file? 
 > Example: set up a probe at homing position to establish a Z  reference 
 > at the beginning of a procedure.
 > 
 > Craig
 > 
 > Mark Pictor wrote:
 > 
 > >Hello Sven.
 > >
 > >Yes, you can do probing with EMC.
 > >
 > >For more info, see
 > >http://www.linuxcnc.org/handbook/part2/probe1.html
 > >

Dean,

This is exactly what I'm looking for and it sounds great.
I will for sure test the software later on!

Regards,
Sven


-----Ursprungligt meddelande-----
Fr=E5n: emc-users-admin@...
[mailto:emc-users-admin@... Dean Hedin
Skickat: den 18 mars 2004 22:21
Till: emc-users@...
=C4mne: Re: SV: [Emc-users] Latest version


On Thursday 13 March 2003 04:22 am, Ray Henry wrote:
> Being psychic, there is a message coming along soon that asks about
> probing within a g-code program.
>
> Yes it's in RS274NGC

There is also the emcprobe utility now checked into CVS.   I would
appreciate
any feedback from anyone who experiments with this code.   Emcprobe does =
not
use RS274NGC, rather it talks to emc directly using NML.

It allows you to probe "cubical" regions on a 3 axis table.   It then
outputs
g-code that follows the surface contour.

Dean,

If you read this, please send me an e-mail, sven[at]svenneduva.net,
or if anyone out here knows how to get in contact with Dean, please let me
know how.

I have questions about your probing utility.

Cheers,
Sven

Hello Sven.  I am here.  Let the questioning begin.
Proceed with dialog on the emc list so that others may benefit.

On Tuesday 20 April 2004 11:06 am, Sven-=C5ke Larsson wrote:
> Dean,
>
> If you read this, please send me an e-mail, sven[at]svenneduva.net,
> or if anyone out here knows how to get in contact with Dean, please let=
 me
> know how.
>
> I have questions about your probing utility.
>
> Cheers,
> Sven

Nice to find you! :-)

A while ago you responded on a question I sent about probing, and you wro=
te
that you made a piece of code that scanned a given cube and you also wrot=
e
that is was checked in under ncutils in the cvs-tree. I'm pretty sure I w=
as
looking at it back then and I also found some example images of some text
scanned with the code, but I can't find anymore.
So my initial questions are:
Where is it now?
Can I get those images again?
Is there any documention around the code?


I also (back then) found an example drawing of a home made probe designed=
 as
three horizontal pins shortcutting a circuit. When the vertical probe was
pushed to the side either one of the three pins where lifted and the circ=
uit
was broken. If anyone recognize what I'm blurring about, please give me a
hint where I can find it again.


Cheers,
Sven


-----Ursprungligt meddelande-----
Fr=E5n: emc-users-admin@...
=C4mne: Re: [Emc-users] Dean Hedin, I need to get in contact!


Hello Sven.  I am here.  Let the questioning begin.
Proceed with dialog on the emc list so that others may benefit.

Hi Sven

The file I think you refer to is:
http://f3.grp.yahoofs.com/v1/wNKGQHs65ZnYSAPVtyr0OpXh74ksexSD_b6FsOBwPoZ8UaQkKF61DJb9uqGyxofLxwt61K0c5xUakl5upQsxIv1pEX3Th0A/CIRCUITS/Probes/digitizer.PDF

If the link fails, try this one:
http://groups.yahoo.com/group/CAD_CAM_EDM_DRO/files/CIRCUITS/Probes/ File 
name: digitzer.PDF

If you still can't download it, I have a copy I can forward on.

As regards the ncutils source - These can be found under emc/src.

Regards, Paul.


On Wednesday 21 April 2004 9:32 pm, Sven-Åke Larsson wrote:
> Where is it now?
> Can I get those images again?
> Is there any documention around the code?
>
>
> I also (back then) found an example drawing of a home made probe designed
> as three horizontal pins shortcutting a circuit. When the vertical probe
> was pushed to the side either one of the three pins where lifted and the
> circuit was broken. If anyone recognize what I'm blurring about, please
> give me a hint where I can find it again.

-- 

"To err is human...to really f*** things up requires the root password."
From a collection of quotes at http://www.indigo.org/quotes.html

Lovely!


-----Ursprungligt meddelande-----
Fr=E5n: emc-users-admin@...
[mailto:emc-users-admin@... Paul
Skickat: den 21 april 2004 22:45
Till: emc-users@...
=C4mne: Re: SV: [Emc-users] Dean Hedin, I need to get in contact!



Hi Sven

The file I think you refer to is:
http://f3.grp.yahoofs.com/v1/wNKGQHs65ZnYSAPVtyr0OpXh74ksexSD_b6FsOBwPoZ8=
UaQ
kKF61DJb9uqGyxofLxwt61K0c5xUakl5upQsxIv1pEX3Th0A/CIRCUITS/Probes/digitize=
r.P
DF

If the link fails, try this one:
http://groups.yahoo.com/group/CAD_CAM_EDM_DRO/files/CIRCUITS/Probes/ File
name: digitzer.PDF

If you still can't download it, I have a copy I can forward on.

As regards the ncutils source - These can be found under emc/src.

Regards, Paul.

On Wednesday 21 April 2004 08:32 pm, Sven-=C5ke Larsson wrote:
> Nice to find you! :-)
>
> A while ago you responded on a question I sent about probing, and you w=
rote
> that you made a piece of code that scanned a given cube and you also wr=
ote
> that is was checked in under ncutils in the cvs-tree. I'm pretty sure I=
 was
> looking at it back then and I also found some example images of some te=
xt
> scanned with the code, but I can't find anymore.
> So my initial questions are:
> Where is it now?
> Can I get those images again?
> Is there any documention around the code?

For those unaware, emcprobe is a utility that makes emc behave like a=20
pantograph.   You need to have a probe tip mounted in the machine chuck a=
nd=20
connected to the probe i/o line on the emc parallel port.

The source is for the emcprobe utility is in the sourceforge CVS reposito=
ry.
I am still working on the documentation.   If you have a system where you=
 can=20
build emc source then you could use the "browse cvs" feature  of sourcefo=
rge.=20
and download the code.  =20

emcprobe.cc is in the /src/task directory   (you will also need the Makef=
ile=20
from that directory)

I am hoping to get the documentation done soon and emcprobe will be out i=
n the=20
next release of emc.

To run emcprobe,  you need to create an initilization file that tells it =
about=20
the region(s) on the machine table to probe and some other info like what=
=20
polarity the probe tip is.  I will put a sample init file in the docs.  I=
 can=20
email you a sample init if you want.

Next, fire up emc,  confirm your probe works with the existing emc gui me=
nu=20
item.  Zero your machine, mount the item on the table, and then open up a=
=20
console and run emcprobe -f  initfile.    Emcprobe will then take control=
 of=20
the machine and run the probe through the region(s) specified.   You can =
hit=20
control-c to abort emcprobe.

Emcprobe will then output a g-code file representing the surface probed. =
 It=20
will also display the probed coordinates on the console as it runs.

Emcprobe can take a long time to run.  For example a 3"x5" region probed =
on a=20
=2E1" grid can take several hours to probe. =20

I also put into cvs some g-code utilities the are under /src/ncutils.   T=
hese=20
utilities perform various transforms on g-code files.  You can rotate, sh=
ift,=20
flip, merge g-code files with them.   These utilities compile under Borla=
nd=20
for Win OS or under linux.  These are well documented in the cvs source. =
=20
There main intent was for use with the g-code produced by emcprobe, howev=
er=20
they evolved into more general use.  I use them with g-code from other=20
programs as well and find them quite handy for lining things up on the=20
machine. =20

=20

Thanks Dean! :-)

Cheers,
Sven

-----Ursprungligt meddelande-----
Fr=E5n: emc-users-admin@...
[mailto:emc-users-admin@... Dean Hedin
Skickat: den 21 april 2004 22:23
Till: emc-users@...; Sven-=C5ke Larsson
Kopia: sven@...
=C4mne: Re: SV: [Emc-users] Dean Hedin, I need to get in contact!


On Wednesday 21 April 2004 08:32 pm, Sven-=C5ke Larsson wrote:
> Nice to find you! :-)
>
> A while ago you responded on a question I sent about probing, and you
wrote
> that you made a piece of code that scanned a given cube and you also wr=
ote
> that is was checked in under ncutils in the cvs-tree. I'm pretty sure I
was
> looking at it back then and I also found some example images of some te=
xt
> scanned with the code, but I can't find anymore.
> So my initial questions are:
> Where is it now?
> Can I get those images again?
> Is there any documention around the code?

For those unaware, emcprobe is a utility that makes emc behave like a
pantograph.   You need to have a probe tip mounted in the machine chuck a=
nd
connected to the probe i/o line on the emc parallel port.

The source is for the emcprobe utility is in the sourceforge CVS reposito=
ry.
I am still working on the documentation.   If you have a system where you
can
build emc source then you could use the "browse cvs" feature  of
sourceforge.
and download the code.

emcprobe.cc is in the /src/task directory   (you will also need the Makef=
ile
from that directory)

I am hoping to get the documentation done soon and emcprobe will be out i=
n
the
next release of emc.