Jon,
Yours is 24,000 and equals to 41.6667kHz? Mine is 100,000 and equates to 10 
kHz.  I’m confused by your math here? Thanks. 

Sent from my iPad

> On May 7, 2020, at 9:39 PM, John Dammeyer <jo...@autoartisans.com> wrote:
> 
> 
>> 
>> From: Dan Henderson [mailto:luvtof...@gmail.com]
> 
>> Thanks for that Jon. That helps explain this a bit further. I believe the
>> base period in the ini is set to 100,000. Not sure if that is nS or u
>> value? Can this be change to suit or is it tied to the speed of the system?
> 
> Hi Dan,
> All of my comments are based on what I think I've learned so far.  If anyone 
> else sees an error please correct me.
> 
> It's in nano-seconds and it's pretty big on your system and works out to 
> 10kHz.  That's the max step rate you will get from your system as long as you 
> have the addf parport.0.reset base-thread.  Otherwise the max step rate is 
> half that.
> 
> You generally get that value from running the program that tests your system 
> for latency.  The jitter you get from that test will change how accurate that 
> 24uS period actually is.
> 
> From my INI file
> BASE_PERIOD = 24000  <-- This is 24,000 nS or 24uS or 0.000024 seconds and 
> equivalent to 41.6667kHz. 
> SERVO_PERIOD = 1000000 <-- this is 1 million nano-seconds or 1mS equivalent 
> to 1kHz.
> 
> So what does it mean?
> From your HAL file.
> 
> 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="0xe000 out 0xe800 out"
> loadrt stepgen step_type=0,0,0
> loadrt encoder num_chan=1
> loadrt abs count=1
> loadrt scale count=1
> loadrt lowpass count=1
> loadrt near
> loadrt pwmgen output_type=1
> 
> Inside each of these files is a function called 
> int rtapi_app_main(void) {...}
> 
> In that function the command line arguments like step_type are parsed and 
> default values are set up. Here's how the Parallel port read function is 
> configured.
>    /* make read function name */
>    rtapi_snprintf(name, sizeof(name), "parport.%d.read", n);
>    /* export read function */    
>               retval = hal_export_funct(name, read_port, 
> &(port_data_array[n]),0, 0, comp_id);
> with the names of the functions you add later in the HAL file with commands 
> like:
> 
> addf parport.0.read base-thread
>    
> each addf function with base-thread as an argument must run to completion in 
> less than 24uS on my system or there won't be time for anything else.    Each 
> of these programs, generally found in the src/hal or src/emc path.
> 
> The ones marked servo-thread  run once every SERVO_PERIOD which is set at  
> 1mS.  
> 
> The PID runs once per 1mS.  The stepgen runs every 24uS on my system.
> 
> Hopefully this helps.  So you know the 'why' rather than just do this and 
> tell us what happened.
> 
> John Dammeyer
> 
>> 
>>> On Thu, May 7, 2020 at 6:54 PM John Dammeyer <jo...@autoartisans.com> wrote:
>>> 
>>> 
>>> If you look at the source code for "encoders.c" John Kasunich's excellent
>>> documentation says this:
>>> 
>>>    "The driver exports variables for each counters inputs and output.
>>>    It also exports two functions.  "encoder.update-counters" must be
>>>    called in a high speed thread, at least twice the maximum desired
>>>    count rate.  "encoder.capture-position" can be called at a much
>>>    slower rate, and updates the output variables."
>>> 
>>> So if your encoder provides a quadrature count of 200 lines (800
>>> quadrature) and you turn that spindle at 4700 RPM (78.3333RPS) then 800
>>> pulses/turn * 78.33333 turns/sec  = 62.666KHz so your BASE_PERIOD must be
>>> at least 125kHz (8,000 nS)
>>> 
>>> In your working example 1200 RPM is 20 RPS * 800 = 16,000 and twice that
>>> is 32,000Hz (31,250 nS BASE_PERIOD).
>>> What is your BASE_PERIOD set at in your INI file?
>>> 
>>> Work it backwards.  For example my PP HAL file says 24,000nS for the BASE
>>> THREAD (41,667kHz).  Assuming I have a 200 line encoder on the spindle then
>>> 41,667kHz/2=20,8333 and divided by 800 = 26 RPS or 1562 RPM.  Since I want
>>> to turn my spindle up to 3000 RPM that means either I have to decrease the
>>> BASE_PERIOD (increase frequency)  or reduce the spindle encoder count to
>>> about 100.
>>> 
>>> That means I need no more than 100 slots per rev on a disk.  That's doable
>>> and from what I've read lots of people can thread with that.
>>> 
>>> And, Sam Sokolik has been able to do rudimentary hex holes (although
>>> slowly) with less than that.
>>> 
>>> Now since I have a MESA 7i92H all the numbers will change.  I've not yet
>>> looked at the MESA software.
>>> 
>>> Haven't even really followed the entire path from a
>>> G33.1 Z-0.55 K0.025
>>> to the Z axis motion in steps/second tracking spindle RPM.
>>> 
>>> John Dammeyer
>>> 
> 
> 
> 
> _______________________________________________
> 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

Reply via email to