Re: [Emc-users] A simple LinuxCNC system

[Chris Albertson]

>  With the pitch of the
> ballscrew at 3mm just how does one get the fine step size back .


With a timing belt reduction system.  Timing belts have zero-backlash and
can increase torque and precision.   They also can absorb tiny amounts of
misaignment between the motor and the lead screw like a flexible shaft
coupler.
-- 

Chris Albertson
Redondo Beach, California

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

Re: [Emc-users] A simple LinuxCNC system

[Lester Caine]

On 29/04/2020 17:48, John Dammeyer wrote:

Yes. Up until recently micro-stepper drives ran 10:1 but now they can do 256:1 
although the jury is out on whether anything past 10:1 is useful.  But that's a 
different discussion.


The drivers I use have always had 128:1 but I've never found anything 
over 8:1 of use if one is continually switching direction. As you say it 
is a different discussion, but having now got a ballscrew build of the 
taig mill in the workshop it's one I need to return to. A 20tpi 
leadscrew with 4:1 stepping gives fairly reliable 1/16thou steps while 
at 8:1 one you can measure the spread of the step sizes. That said, both 
give a visible improvement to surface finish when working on jewellery 
over the original half stepping controller. With the pitch of the 
ballscrew at 3mm just how does one get the fine step size back ... does 
the much lower backlash provide enough gain, given that it can be 
catered for and managed on the 20tpi leadscrew. Time to look at the 
0.9deg motors? They are pushing up to the power that the the first taig 
machines were shipped with ...


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk


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

Re: [Emc-users] A simple LinuxCNC system

[John Dammeyer]

> From: Jon Elson [mailto:el...@pico-systems.com]
> On 04/29/2020 12:54 AM, John Dammeyer wrote:
> >
> > Here's my question for you. If the asynchronous pulse
> > generator from your $1 chip has just created a pulse and
> > the SERVO_PERIOD now wants to a new rate how do you set up
> > the frequency generator so that the next pulse is
> > correctly spaced from the previous one? Or do you just
> > hope it works out?
> The trajectory planner uses a specified acceleration rate to
> change the commanded velocity in small increments.  Remember
> this is typically recomputed 1000 times a second.  So, there
> will not be huge jumps in commanded velocity.  Therefore,
> the change in time between steps will not be large, so the
> motor can follow it properly.
> 
> Jon

Thanks Jon,
My ELS included most of that trajectory planning, step pulse generation and the 
LMD18245 micro-stepping control all inside what would be called the BASE_PERIOD 
thread in LinuxCNC.

That's because 14 years ago two LMD18245's and the associated parts cost less 
than any 3A 55V micro-stepping driver out there.  Now you can get that for the 
price of only one LMD18245 so that hardware is redundant.  Which means I've 
been rethinking how I'd do things.  

Interesting too how motion.c which I'm seeing for the first time is very 
similar to what I did in my ELS code.  I've ported the ELS from the PIC18F to a 
PIC32 and for the most part it's working.  And that interrupt routine that used 
to take about 35 microseconds now takes under 2 uS.And I want to run 
everything under the PIC32 version of FREE RTOS. 

John






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

Re: [Emc-users] A simple LinuxCNC system

[John Dammeyer]

> >
> > Hi Gene,
> > I'm just in learn mode trying to figure out how LinuxCNC works.   Not 
> > worried about speed.  So far, with various steppers  when
> actually used to drive machines I've found that if you can step at 20kHz you 
> are way beyond the torque capabilities of the motors.
> >
> Unless you are using drivers with microstepping, then you
> need more steps to get the same motor speed.
> 
> Jon

Yes. Up until recently micro-stepper drives ran 10:1 but now they can do 256:1 
although the jury is out on whether anything past 10:1 is useful.  But that's a 
different discussion.

John



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



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

Re: [Emc-users] A simple LinuxCNC system

[John Dammeyer]

>   Is the real time component of Linux CNC running all the tasks that are
> > started with the loadrt with a 24uS period?In other words all loaded
> > "loadrt tasks" have to finish within 24uS or the system will start to have
> > jitter or miss events.
> >
> 
> No, only the functions that are addf-ed to the base-thread run at that
> rate. Everything else (addf-ed to the servo-thread) runs at the
> servo-thread rate.
> This typically includes motion and the management section of many
> components. So, for example, the stepgen has a servo-thread part that
> calculates the step rate, and a base-thread portion that _only_ makes
> steps.
> Generally nothing in the base-thread does any floating-point calculations.
> (base-thread FP used to be disallowed, in fact, but can now be turned on
> via a switch)
> 
> 
> In general yes, but the parallel port is a special case. It has a "reset"
> function that can be configured to switch pins back to their default state
> in the same thread cycle as the parport-write.
> (The parport reset will actually busy-wait if the time has not yet elapsed,
> so it is more efficient to put some other base-thread tasks between
> parport-write and parport-reset in the base thread to avoid waiting, except
> in cases where you need the parport pulses to be as short as possible
> (which I can't think of a use-case for)

Thanks Andy,
A small lightbulb just went on.  The 

loadrt loadrt hal_parport cfg="0 out" 

just tells the OS that there is a function rtapi_app_main() that must be called 
to setup the list of functions that can be addf'd.

It's then the addf function names that must be exported in the rtapi_app_main() 
function.

The  
"addf functions _time_-thread"  
then add the functions to the real time OS task list running at BASE_PERIOD and 
they are added in the order they are in the HAL file. 

So below here:
==
# ESTOP and Charge Pump Support for safety
loadrt estop_latch
loadrt charge_pump

# Control of PWM for Spindle
addf pwmgen.make-pulses base-thread

# Monitor Parallel port inputs
addf parport.0.read base-thread

#Control of Parallel port step/dir/output signals
addf stepgen.make-pulses base-thread
addf parport.0.write base-thread

# make parallel port step pulses shorter than one base period
addf parport.0.reset base-thread
===

Having the parport-reset right after the parport-write means it sits in that 
while loop wasting time until the system clock in nano-seconds passes the set 
point of system clock + 5000 nanoseconds.

But if I move things around so there are more addf functions before the addf 
parport-reset I may find it doesn't spend any time in that do wait for timeout 
loop.
 
==
# Monitor Parallel port inputs
addf parport.0.read base-thread

#Control of Parallel port step/dir signals
addf stepgen.make-pulses base-thread
addf parport.0.write base-thread

# ESTOP and Charge Pump Support for safety
loadrt estop_latch
loadrt charge_pump

# Control of PWM for Spindle
addf pwmgen.make-pulses base-thread

# make parallel port step pulses shorter than one base period
addf parport.0.reset base-thread
===

John Dammeyer




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

Re: [Emc-users] A simple LinuxCNC system

[Jon Elson]

On 04/29/2020 12:54 AM, John Dammeyer wrote:


Here's my question for you. If the asynchronous pulse 
generator from your $1 chip has just created a pulse and 
the SERVO_PERIOD now wants to a new rate how do you set up 
the frequency generator so that the next pulse is 
correctly spaced from the previous one? Or do you just 
hope it works out?
The trajectory planner uses a specified acceleration rate to 
change the commanded velocity in small increments.  Remember 
this is typically recomputed 1000 times a second.  So, there 
will not be huge jumps in commanded velocity.  Therefore, 
the change in time between steps will not be large, so the 
motor can follow it properly.


Jon


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

Re: [Emc-users] A simple LinuxCNC system

[Jon Elson]

On 04/29/2020 12:10 AM, John Dammeyer wrote:


Hi Gene,
I'm just in learn mode trying to figure out how LinuxCNC works.   Not worried 
about speed.  So far, with various steppers  when actually used to drive 
machines I've found that if you can step at 20kHz you are way beyond the torque 
capabilities of the motors.

Unless you are using drivers with microstepping, then you 
need more steps to get the same motor speed.


Jon


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

Re: [Emc-users] A simple LinuxCNC system

[andy pugh]

On Wed, 29 Apr 2020 at 01:35, John Dammeyer  wrote:

The important constants come from the INI file:
>

Note that they don't have to. A very simple LinuxCNC configuration can omit
the INI.
But once you loadrt motmod, then you need an INI to pass it the axis data.

  Is the real time component of Linux CNC running all the tasks that are
> started with the loadrt with a 24uS period?In other words all loaded
> "loadrt tasks" have to finish within 24uS or the system will start to have
> jitter or miss events.
>

No, only the functions that are addf-ed to the base-thread run at that
rate. Everything else (addf-ed to the servo-thread) runs at the
servo-thread rate.
This typically includes motion and the management section of many
components. So, for example, the stepgen has a servo-thread part that
calculates the step rate, and a base-thread portion that _only_ makes
steps.
Generally nothing in the base-thread does any floating-point calculations.
(base-thread FP used to be disallowed, in fact, but can now be turned on
via a switch)


> setp stepgen.0.steplen 1
> setp stepgen.0.stepspace 0
>
> Both values inside the motmod and parallel port tasks appear to set it to
> that value or the minimum BASE_PERIOD.  Whichever is shorter.  At least
> that is how I interpret it.
> Is that correct?

What that would mean is that although it wants a 1nS step length the
> reality is the minimum period is 24uS and since a step pulse is exactly
> that, a pulse, the step space is also 24uS.   So that implies the fastest
> step rate possible is 24uS ON and 24uS OFF or 48 uS minimum period which
> gives a 20.833kHz stepping rate.


In general yes, but the parallel port is a special case. It has a "reset"
function that can be configured to switch pins back to their default state
in the same thread cycle as the parport-write.
(The parport reset will actually busy-wait if the time has not yet elapsed,
so it is more efficient to put some other base-thread tasks between
parport-write and parport-reset in the base thread to avoid waiting, except
in cases where you need the parport pulses to be as short as possible
(which I can't think of a use-case for)

For a stepping motor driver with 10uStep per step that's still pretty well
> faster than it can actually turn.  For a Servo motor with a 2500 line
> encoder it's way too slow so a step multiplier or encoder divider would be
> required.
>

Step rate is not often a problem with the parport, encoder-counting hits
the limit a lot more often. Especially on spindles.

Now the trajectory planner.  Am I correct when I interpret that the
> trivkins planner runs at the BASE_PERIOD rate every 24 uS but uses the
> SERVO_PERIOD of 1mS (100nS) for trajectory updating.
>

No, everything bar the most basic pin-manipulation functions tends to run
at the servo-thread rate. (as you can see from typical HAL files)

But back to my final question for this post.  Is the Servo Period the time
> interval used to calculate the next motor velocity?
> So the acceleration is actually based on changing the velocity every 1mS
> for that 100nS SERVO_PERIOD value?


Yes. The acceleration and velocity  curves are all governed by a set of
_position_ waypoints that are updated every 1mS and sent straight to the
joint.N... HAL pins.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is designed
for the especial use of mechanical geniuses, daredevils and lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912

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

Re: [Emc-users] A simple LinuxCNC system

[Gene Heskett]

On Wednesday 29 April 2020 01:10:54 John Dammeyer wrote:

> > If using the parport in EPP mode, you can set a reset time
> > separately, so you can step at the base thread rate. As far as motor
> > speed is concerned, the speed limit is generally the speed limit of
> > the opto stuff in the driver, and I've run steppeers laying on the
> > table at slightly better than 300 kilohertz with a 2M542 driver, or
> > about 3000 rpm. zero torque at that speed of course. :)
> >
> >
> > Cheers, Gene Heskett
>
> Hi Gene,
> I'm just in learn mode trying to figure out how LinuxCNC works.   Not
> worried about speed.  So far, with various steppers  when actually
> used to drive machines I've found that if you can step at 20kHz you
> are way beyond the torque capabilities of the motors. John
>
This is also true John, its the nature of the beasts. In fact one machine 
I own, a 6040 that came with crap electronics I had to replace all of, 
has a batch of the shortest nema 23 motors I have seen. But with a box 
of good drivers its doing rapids in the xy at 200 ipm.  The Z has to 
lift the horse or so spindle  motor so its all done at 35 ipm going up, 
but the little motors have much less inductance so they will take the 
needed currant at higher speeds where the 435's on the g0704 mill are 
all done well before 100 ipm.

Either. at working speeds has more than enough torque to shatter a 
plugged up with hot alu tool in a heartbeat. I very quickly found that 
mist cooling on that puppy was an absolute requirement so I invented 
some, I am pulsing a peristoltic pump, similar to what the hospitals use 
to put an IV drip in you. Pulse is settable from the axis gui.  Air for 
it is also switched by the same button.

I've also found that the proper programming of the vfd's can get enough 
power to cut alu at a quite decent feed rate even when that 24k revs 
spindle is only turning 1k revs, the secret is to set the low speed 
currant limits in the vfd to match the motors FLA rating. They don't 
come OOB set to do anything like that. Thats not always easy when trying 
to translate the vfd booklet, written in Chinglish, to something you and 
I might understand.  But I've done it twice now with amazing low speed 
results. My converted Sheldon lathe, with a 1 horse 3 phase that spent 
the first 40 years of its life on an air compressor, can pull large 
swarf turning blue, when driven at 8 hz, for long enough to get the job 
done, without getting the motor too hot to lay my hand on it. Flat, 
plumb, hasn't been used yet, don't need the backgear.

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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


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

Re: [Emc-users] A simple LinuxCNC system

[John Dammeyer]

> -Original Message-
> From: Chris Albertson [mailto:albertson.ch...@gmail.com]
> Sent: April-28-20 9:30 PM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] A simple LinuxCNC system
> 
> On Tue, Apr 28, 2020 at 6:32 PM John Dammeyer 
> wrote:
> 
> >
> > Will you share some code on how you accelerate from 0 to 15kHz stepping
> > rate on your $1 processor?
> >
> 
> No code. that is the entire point.  The microcontroller has built-in
> hardware the bigger PC or Raspberry Pi lacks.   

>  But at the servo loop
> period you would re-oad the register with the new step period.  The
> resolution is hat ever is needed up to the crystal frequency.
> 
> Same with reading quadrature encoders.  The chips will have a hardware
> encoder made with flip-flops and a counter. So there is no polling or
> iterrupts.  They use logic gates.  The software reads the encoder value
> from a hardware register.   To the little chip and drive a few motors I
> might do a 20Hz loop but run the motor at 1KHz.
> 
> LinuxCNC with a Mesa card works sort of like this too.  An FPGA is just
> hardware gates
> 
> 
HI Chris,
I believe you indirectly answered my question.To say it differently I'd 
explain it this way.

The trajectory planner decides that a motor needs to step at rate N.  So as you 
said the " servo loop period " does the calculation and sets that up.  In the 
case of the parallel port interface the real time system runs at the 
BASE_PERIOD rate to generate these pulses.   And there's an embedded delay loop 
in the reset_port() function called from somewhere.  Don't know where yet.

In either case, how the steps are generated when you use something external 
like a $1 chip or an FPGA is what I was trying to leave out of this 
conversation.

If the SERVO_PERIOD is 1kHz (1mS) then a new rate is calculated and sent off to 
the stepping task.  But you can't just step at a new rate.  The trajectory 
planner has to determine the acceleration and for each SERVO_PERIOD issue a new 
step rate so that the motor accelerates up to or down to the new speed.  

Here's my question for you.  If the asynchronous pulse generator from your $1 
chip has just created a pulse and the SERVO_PERIOD now wants to a new rate how 
do you set up the frequency generator so that the next pulse is correctly 
spaced from the previous one?  Or do you just hope it works out?

John




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

Re: [Emc-users] A simple LinuxCNC system

[John Dammeyer]

> >
> If using the parport in EPP mode, you can set a reset time separately, so
> you can step at the base thread rate. As far as motor speed is
> concerned, the speed limit is generally the speed limit of the opto
> stuff in the driver, and I've run steppeers laying on the table at
> slightly better than 300 kilohertz with a 2M542 driver, or about 3000
> rpm. zero torque at that speed of course. :)

 
> Cheers, Gene Heskett

Hi Gene,
I'm just in learn mode trying to figure out how LinuxCNC works.   Not worried 
about speed.  So far, with various steppers  when actually used to drive 
machines I've found that if you can step at 20kHz you are way beyond the torque 
capabilities of the motors.
John




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

Re: [Emc-users] A simple LinuxCNC system

[Chris Albertson]

On Tue, Apr 28, 2020 at 6:32 PM John Dammeyer 
wrote:

>
> Will you share some code on how you accelerate from 0 to 15kHz stepping
> rate on your $1 processor?
>

No code. that is the entire point.  The microcontroller has built-in
hardware the bigger PC or Raspberry Pi lacks.   The way it works is there
is a counter register that counts clock cycles.  The clock is derived from
the main crystal and can be set to say 10 MHz or whatever.   Then there is
another register what you load in a cycle count and the output step rate is
say maybe "475 cycles" and each cycle is some multiple of the crystal
frequency.Once you load the registers the steps happen in hardware so
there never is need for a real-time loop.   But at the servo loop
period you would re-oad the register with the new step period.  The
resolution is hat ever is needed up to the crystal frequency.

Typically a processor has many of these timers.  Cheaper chips have a few
and bigger chips might have a dozen of them.  YOu also get to asign the
timer to a physical pin.  So the software never has to write to the pin as
it is connected to the timer register.

You can do PWM in hardware too.  There is a 10-bit register that holds the
duty cycle and then the PWM output runs without any software.  It is just
logic gates

So this is how people are running 4 axis machines at 200mm per second using
low-end controllers.   The controllers have quite a lot of useful hardware
on them so they don't need fast software

Same with reading quadrature encoders.  The chips will have a hardware
encoder made with flip-flops and a counter. So there is no polling or
iterrupts.  They use logic gates.  The software reads the encoder value
from a hardware register.   To the little chip and drive a few motors I
might do a 20Hz loop but run the motor at 1KHz.

LinuxCNC with a Mesa card works sort of like this too.  An FPGA is just
hardware gates



-- 

Chris Albertson
Redondo Beach, California

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

Re: [Emc-users] A simple LinuxCNC system

[Gene Heskett]

On Tuesday 28 April 2020 21:29:39 John Dammeyer wrote:

> > From: Chris Albertson [mailto:albertson.ch...@gmail.com]
> > Sent: April-28-20 6:13 PM
> > To: Enhanced Machine Controller (EMC)
> > Subject: Re: [Emc-users] A simple LinuxCNC system
> >
> > > *For a stepping motor driver with 10uStep per step that's still
> > > pretty well faster than it can actually turn. *
> >
> > No, you missed the point.   With 10 uS per cycle, the motor can step
> > in steps that are a multiple of 10uS long.   So it can be 6000 uS or
> > 6010 uS but never 6011 uS per step.  It is the step-size resolution.
> >  The pulse can be raised or lowered on each cycle.   I think the max
> > step rates would then be 20 uS or 50KHz which is faster than it can
> > go.
>
> Hi Chris,
> I think I didn't explain that well enough. A Gecko a 10 step per step
> drive.  What is commonly called micro-steps.  Perhaps I should have
> written it that way.
>
> As far as LinuxCNC goes, to me it appears the parallel port code given
> the steplen calculations there isn't a way to bring the step pulse low
> again during the same BASE_PERIOD interval which in the HAL file
> example is 24uS not 10uS.   Therefore I interpret the step pulses to
> be twice the BASE_PERIOD time.
>
> > BTW this only works because you have a very fast processor.   If I'm
> > running a stepper motor using my $1 (yes literally $1)
> > microcontroller chip I can tell the hardware step generator the step
> > period in units of 0.001 uS. one nanosecond  I get 10,000 times
> > better resolution.  I think the FPGA based solutions do the same. 
> > That said, I doubt the nanosecond level resolution of the step
> > period is really needed.
>
> Will you share some code on how you accelerate from 0 to 15kHz
> stepping rate on your $1 processor?
>
> Thanks
> John
>
If using the parport in EPP mode, you can set a reset time separately, so 
you can step at the base thread rate. As far as motor speed is 
concerned, the speed limit is generally the speed limit of the opto 
stuff in the driver, and I've run steppeers laying on the table at 
slightly better than 300 kilohertz with a 2M542 driver, or about 3000 
rpm. zero torque at that speed of course. :)
> > --
> >
> > Chris Albertson
> > Redondo Beach, California
> >
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>


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

Re: [Emc-users] A simple LinuxCNC system

[John Dammeyer]

> > I couldn't find that reset mode in the hal_parport.  At least not how you 
> > could have a step that lasted 5uS when the base period
> was 35uS.  How's that timing calculated?
> 
> setp parport.0.reset-time 5000
>  In the doc I linked earlier

Ends up being  reset_time in the reset_port() function.   Can't find when or 
how reset_port() is called.  

Looks a lot like the system sets up a loop inside one of the tasks burning CPU 
cycles until 5 micro-seconds has passed by calling the rtapi_get_clocks() 
function.  

if(port->reset_time > period/4) port->reset_time = period/4;
reset_time_tsc = ns2tsc(port->reset_time);

if(outdata != port->outdata) {
deadline = port->write_time + reset_time_tsc;
while(rtapi_get_clocks() < deadline) {}
rtapi_outb(outdata, port->base_addr);
}


I do something similar (as a temporary measure until I get the FREE RTOS 
installed)   The LED is just there so I can verify the time delay with the 
scope.  But I'm not fond of that technique.

void 
Delay10uS(int32 delay) {
 uint32 timedelay;
bANB_LED3 = 1;  // For now pulse LED so we can see if it's being used in 
normal LCD operations.
timedelay = ReadCoreTimer() + (400*delay);
while (ReadCoreTimer() < timedelay) ;
bANB_LED3 = 0;
}




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



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

Re: [Emc-users] A simple LinuxCNC system

[Phill C]

> On 29 Apr 2020, at 12:34 pm, John Dammeyer  wrote:
> 
> 
> 
>> -Original Message-
>> From: Peter C. Wallace [mailto:p...@mesanet.com]
 double step on this page may do that
 >
>>> 
>>> Nope.  From the doc. "What is the maximum step rate? Remember, two periods 
>>> to
>>> make a step. You settled on 16uS for the period, so a step takes 32uS. That
>>> works out to a not bad 31,250 steps per second."
> 
> 
>>> The clue in that bit of text is the step len and step hold times are not
>>> nanoseconds but BASE_PERIOD events.  So my original thoughts are still
>>> correct.  The BASE_PERIOD is chosen to create the fastest possible step rate
>>> within reason taking into account latency.
>>> 
>>> Now the source code makes more sense.  Was a bit confusing thinking the
>>> steplen was nanoseconds.
>>> 
>> 
>> The steplen _is_ specified in nanoseconds, and you can generate 1 step per 
>> base
>> thread invocation by using the double step mode (reset mode)
>> 
>> This is described in the hal_parport manual
>> 
>> 
> I couldn't find that reset mode in the hal_parport.  At least not how you 
> could have a step that lasted 5uS when the base period was 35uS.  How's that 
> timing calculated?

setp parport.0.reset-time 5000
 In the doc I linked earlier
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] A simple LinuxCNC system

[John Dammeyer]

> -Original Message-
> From: Peter C. Wallace [mailto:p...@mesanet.com]
> >> double step on this page may do that
> >>  >> >
> >
> > Nope.  From the doc. "What is the maximum step rate? Remember, two periods 
> > to
> > make a step. You settled on 16uS for the period, so a step takes 32uS. That
> > works out to a not bad 31,250 steps per second."


> > The clue in that bit of text is the step len and step hold times are not
> > nanoseconds but BASE_PERIOD events.  So my original thoughts are still
> > correct.  The BASE_PERIOD is chosen to create the fastest possible step rate
> > within reason taking into account latency.
> >
> > Now the source code makes more sense.  Was a bit confusing thinking the
> > steplen was nanoseconds.
> >
> 
> The steplen _is_ specified in nanoseconds, and you can generate 1 step per 
> base
> thread invocation by using the double step mode (reset mode)
> 
> This is described in the hal_parport manual
> 
>
I couldn't find that reset mode in the hal_parport.  At least not how you could 
have a step that lasted 5uS when the base period was 35uS.  How's that timing 
calculated?

OTOH, the code variable names are clearly referring to nanoseconds. 


   for (n = 0; n < num_chan; n++) {
/* decrement "timing constraint" timers */
if ( stepgen->timer1 > 0 ) {
if ( stepgen->timer1 > periodns ) {
stepgen->timer1 -= periodns;
} else {
stepgen->timer1 = 0;
}
}



> 
> >
> >
> >
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
> >
> 
> Peter Wallace
> Mesa Electronics
> 
> (\__/)
> (='.'=) This is Bunny. Copy and paste bunny into your
> (")_(") signature to help him gain world domination.
> 
> 
> 
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



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

Re: [Emc-users] A simple LinuxCNC system

[Peter C. Wallace]

On Tue, 28 Apr 2020, John Dammeyer wrote:


Date: Tue, 28 Apr 2020 19:09:00 -0700
From: John Dammeyer 
Reply-To: "Enhanced Machine Controller (EMC)"
 To: "'Enhanced Machine Controller 
(EMC)'"  Subject: Re: [Emc-users] A simple 
LinuxCNC system




As far as LinuxCNC goes, to me it appears the parallel port code given the 
steplen calculations there isn't a way to bring the step
pulse low again during the same BASE_PERIOD interval which in the HAL file 
example is 24uS not 10uS.  Therefore I interpret the step pulses to be twice 
the BASE_PERIOD time.




double step on this page may do that 
<http://linuxcnc.org/docs/2.8/html/hal/parallel-port.html 
<http://linuxcnc.org/docs/2.8/html/hal/parallel-port.html>>


Nope.  From the doc. "What is the maximum step rate? Remember, two periods to 
make a step. You settled on 16uS for the period, so a step takes 32uS. That 
works out to a not bad 31,250 steps per second."


But then it goes on to show that the real restriction in their example was the 
dir hold setup time and by changing those parameters the step rate can be 
increased.


The clue in that bit of text is the step len and step hold times are not 
nanoseconds but BASE_PERIOD events.  So my original thoughts are still 
correct.  The BASE_PERIOD is chosen to create the fastest possible step rate 
within reason taking into account latency.


Now the source code makes more sense.  Was a bit confusing thinking the 
steplen was nanoseconds.


Thanks
John




The steplen _is_ specified in nanoseconds, and you can generate 1 step per base 
thread invocation by using the double step mode (reset mode)


This is described in the hal_parport manual







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



Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



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

Re: [Emc-users] A simple LinuxCNC system

[John Dammeyer]

> From: Phill C [mailto:phillcarte...@gmail.com]
> 
> > On 29 Apr 2020, at 11:29 am, John Dammeyer  wrote:
> >
> > As far as LinuxCNC goes, to me it appears the parallel port code given the 
> > steplen calculations there isn't a way to bring the step
> pulse low again during the same BASE_PERIOD interval which in the HAL file 
> example is 24uS not 10uS.   Therefore I interpret the
> step pulses to be twice the BASE_PERIOD time.
> >
> 
> double step on this page may do that 
>  >

Probably the reason my head was wrapped around nanoseconds is because the HAL 
file for the MESA 7i92H has:

# these are in nanoseconds
DIRSETUP   = 1000
DIRHOLD= 1000
STEPLEN= 2000
STEPSPACE  = 1000

John




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

Re: [Emc-users] A simple LinuxCNC system

[John Dammeyer]

> >
> > As far as LinuxCNC goes, to me it appears the parallel port code given the 
> > steplen calculations there isn't a way to bring the step
> pulse low again during the same BASE_PERIOD interval which in the HAL file 
> example is 24uS not 10uS.   Therefore I interpret the
> step pulses to be twice the BASE_PERIOD time.
> >
> 
> double step on this page may do that 
>  >

Nope.  From the doc.
"What is the maximum step rate? Remember, two periods to make a step. You 
settled on 16uS for the period, so a step takes 32uS. That works out to a not 
bad 31,250 steps per second."

But then it goes on to show that the real restriction in their example was the 
dir hold setup time and by changing those parameters the step rate can be 
increased.  

The clue in that bit of text is the step len and step hold times are not 
nanoseconds but BASE_PERIOD events.  So my original thoughts are still correct. 
 The BASE_PERIOD is chosen to create the fastest possible step rate within 
reason taking into account latency.

Now the source code makes more sense.  Was a bit confusing thinking the steplen 
was nanoseconds.

Thanks
John





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

Re: [Emc-users] A simple LinuxCNC system

[Phill C]

> On 29 Apr 2020, at 11:29 am, John Dammeyer  wrote:
> 
> As far as LinuxCNC goes, to me it appears the parallel port code given the 
> steplen calculations there isn't a way to bring the step pulse low again 
> during the same BASE_PERIOD interval which in the HAL file example is 24uS 
> not 10uS.   Therefore I interpret the step pulses to be twice the BASE_PERIOD 
> time.
> 

double step on this page may do that 
>
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] A simple LinuxCNC system

[John Dammeyer]

> From: Chris Albertson [mailto:albertson.ch...@gmail.com]
> Sent: April-28-20 6:13 PM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] A simple LinuxCNC system
> 
> >
> > *For a stepping motor driver with 10uStep per step that's still pretty
> > well faster than it can actually turn. *
> 
> 
> No, you missed the point.   With 10 uS per cycle, the motor can step in
> steps that are a multiple of 10uS long.   So it can be 6000 uS or 6010 uS
> but never 6011 uS per step.  It is the step-size resolution.  The pulse can
> be raised or lowered on each cycle.   I think the max step rates would then
> be 20 uS or 50KHz which is faster than it can go.

Hi Chris,
I think I didn't explain that well enough. A Gecko a 10 step per step drive.  
What is commonly called micro-steps.  Perhaps I should have written it that 
way.  

As far as LinuxCNC goes, to me it appears the parallel port code given the 
steplen calculations there isn't a way to bring the step pulse low again during 
the same BASE_PERIOD interval which in the HAL file example is 24uS not 10uS.   
Therefore I interpret the step pulses to be twice the BASE_PERIOD time.


> 
> BTW this only works because you have a very fast processor.   If I'm
> running a stepper motor using my $1 (yes literally $1) microcontroller chip
> I can tell the hardware step generator the step period in units of 0.001
> uS. one nanosecond  I get 10,000 times better resolution.  I think the FPGA
> based solutions do the same.  That said, I doubt the nanosecond level
> resolution of the step period is really needed.

Will you share some code on how you accelerate from 0 to 15kHz stepping rate on 
your $1 processor?

Thanks
John


> 
> 
> 
> --
> 
> Chris Albertson
> Redondo Beach, California
> 
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



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

Re: [Emc-users] A simple LinuxCNC system

[Chris Albertson]

>
> *For a stepping motor driver with 10uStep per step that's still pretty
> well faster than it can actually turn. *


No, you missed the point.   With 10 uS per cycle, the motor can step in
steps that are a multiple of 10uS long.   So it can be 6000 uS or 6010 uS
but never 6011 uS per step.  It is the step-size resolution.  The pulse can
be raised or lowered on each cycle.   I think the max step rates would then
be 20 uS or 50KHz which is faster than it can go.

BTW this only works because you have a very fast processor.   If I'm
running a stepper motor using my $1 (yes literally $1) microcontroller chip
I can tell the hardware step generator the step period in units of 0.001
uS. one nanosecond  I get 10,000 times better resolution.  I think the FPGA
based solutions do the same.  That said, I doubt the nanosecond level
resolution of the step period is really needed.



-- 

Chris Albertson
Redondo Beach, California

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

[Emc-users] A simple LinuxCNC system

[John Dammeyer]

I've been studying the source code for the basic LinuxCNC system.  One that 
doesn't require external intelligent hardware to augment a 4 core 2 GHz 64 bit 
processor.  In other words the parallel port based system.
 
Perhaps someone with more experience with the system can answer a few questions?
 
Starting with this from the HAL file:
 
# Originally generated by stepconf 1.1 at Mon May 27 15:08:43 2019
loadrt trivkins
loadrt [EMCMOT]EMCMOT base_period_nsec=[EMCMOT]BASE_PERIOD 
servo_period_nsec=[EMCMOT]SERVO_PERIOD num_joints=[TRAJ]AXES
loadrt hal_parport cfg="0 out"
loadrt stepgen step_type=0,0,0,0
 
The important constants come from the INI file:
 
[EMCMOT]
EMCMOT = motmod
BASE_PERIOD = 24000
SERVO_PERIOD = 100
 
A BASE_PERIOD value like 24,000 nanoseconds is the same as 24 Microseconds 
which works out to a real time rate of almost 42kHz or in other words something 
can happen every 24 uSeconds or up to 41,666.7 times per second.
 
Have I got that right?   Is the real time component of Linux CNC running all 
the tasks that are started with the loadrt with a 24uS period?In other 
words all loaded "loadrt tasks" have to finish within 24uS or the system will 
start to have jitter or miss events.
 
The following lines configure that real time task stepgen to produce our 
stepping motor pulses and the values are also nanoseconds..
setp stepgen.0.steplen 1
setp stepgen.0.stepspace 0
 
Both values inside the motmod and parallel port tasks appear to set it to that 
value or the minimum BASE_PERIOD.  Whichever is shorter.  At least that is how 
I interpret it.  
 
Is that correct?
 
What that would mean is that although it wants a 1nS step length the reality is 
the minimum period is 24uS and since a step pulse is exactly that, a pulse, the 
step space is also 24uS.   So that implies the fastest step rate possible is 
24uS ON and 24uS OFF or 48 uS minimum period which gives a 20.833kHz stepping 
rate.  
 
For a stepping motor driver with 10uStep per step that's still pretty well 
faster than it can actually turn.  For a Servo motor with a 2500 line encoder 
it's way too slow so a step multiplier or encoder divider would be required.
 
The time to change direction is probably a bit more reasonable.  
setp stepgen.0.dirhold 45000
setp stepgen.0.dirsetup 45000
The 45uS I believe ends up being rounded up to the next integral BASE_PERIOD 
tick so in fact 45,000 becomes 48,000 for setup and hold values.  
 
Now the trajectory planner.  Am I correct when I interpret that the trivkins 
planner runs at the BASE_PERIOD rate every 24 uS but uses the SERVO_PERIOD of 
1mS (100nS) for trajectory updating.
 
Once every 1mS a new velocity is calculated for each of the axis based on where 
the axis is supposed to be.  An example here perhaps.
 
To move the target point along a 45 degree angle the X and Y axis each move the 
exact same distance.  If the position-scale is the same for each then each will 
receive a step pulse at the same time.  And if their maxaccel is the same then 
they will also accelerate up to that stepping rate and decelerate at the same 
rate to reach the end position.
 
The stepgen.c file using the function make_pulses(void *arg, long period){…}  
does the work to do all this.
 
But I've not yet figured out how the G-Code line, if X and Y are 0.000, 
G01 X1.0 Y1.0 F60 
 
turns into the stepping pulses.  
 
The Feed Rate is 60 IPM (assuming imperial units) which is 1 inch per second.  
If each axis requires 10,000 steps per inch then the stepping rate will be 
10,000 steps per second.
 
That's a step pulse every 100 microseconds.  So make_pulses() will generate 
pulses along the line of 
1   0 0 1 0 1 0 0 0 
1
0.  0.24  0.48  0.72  0.96  0.000120  0.000144  0.000168  
0.000192  0.000216
 
There's a jitter of 20uS and then 16 uS that drops by 4uS each step pulse.
 
BTW. This is where the external step generators based on FPGAs do so well since 
they can be programmed to have a 1mHz base period clock and can be programmed 
to create stepping pulses in intervals of 100 x 1uS for much less jitter.
 
But back to my final question for this post.  Is the Servo Period the time 
interval used to calculate the next motor velocity? 
So the acceleration is actually based on changing the velocity every 1mS for 
that 100nS SERVO_PERIOD value?
 
Thanks
John Dammeyer
 
 
"ELS! Nothing else works as well for your Lathe"
Automation Artisans Inc.
www dot autoartisans dot com 
 

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