The BASE_PERIOD value is in nanoseconds and the clue is _PERIOD which is the inverse of FREQUENCY. So 1000Hz => 1/1000 = 0.001 or 1000 microseconds. 2000Hz => 1/2000 = 0.0005 or 500 microseconds.
As the frequency gets higher, the period gets smaller. JOHN > -----Original Message----- > From: Dan Henderson [mailto:luvtof...@gmail.com] > Sent: May-08-20 4:42 AM > To: Enhanced Machine Controller (EMC) > Subject: Re: [Emc-users] Fluctuating RPM using CUI ATM 10 encoder > > 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 _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
