PulseRates

davidf willing & able :)
jmkasunich ok, first - base period
davidf I'll try to 'stand it
jmkasunich the code that makes steps runs periodically
jmkasunich base_period is the time between each run
jmkasunich in nanoseconds
jmkasunich so if you set base_period to 50000, then the step code will run 20,000 times per second
jmkasunich because 1 second divided by 50000nanoseconds = 20000
davidf run being a group of output pulses?
jmkasunich no
jmkasunich it has nothing to do with output at this point
jmkasunich that is just how often the code runs
davidf k
davidf oh.
jmkasunich the code runs at the same speed all the time, and every time it runs it decides "should I make a pulse now?"
davidf ok
jmkasunich so if the base period is 50000, the code is running 20,000 times per second, whether you are making one pulse per second, or 100, or 10000
davidf I see
jmkasunich in order to make a single pulse, the code has to decide "its time to make a pulse", and turn the output on
jmkasunich the next time it runs, it turns the output off
davidf Ah, so there is overhead for the code, and so input_scale needs to be enough below the base frequency to allow for that.
jmkasunich the soonest it can make another pulse is the time after that
jmkasunich you're getting ahead... be patient
davidf sorry.
jmkasunich k
jmkasunich anyway, if the code is running 20,000 times per second, the fastest it can make pulses is 10,000 times/second
jmkasunich because it needs one run to turn the pulse on and one to turn it off
jmkasunich if you want faster pulses, you have to run the code more often
jmkasunich thats why you use shorter base_period
jmkasunich with a base period of 10000 nanoseconds, the code is running 100,000 times every second
jmkasunich and you can in theory make 50,000 step pulses per second
jmkasunich but when that code is running 100,000 times per second, it doesn't leave the CPU much time for anything else - thats why your computer starts to get slow when you have very small base_period
jmkasunich got it so far?
davidf yes.
jmkasunich what SWP told you was the absolute theoritical maximum step pulse frequency you can get for any given base_period
jmkasunich but you _don't_ really want to ask for that high of a frequency
jmkasunich let's use your numbers - base_period is 10000, the code is running 100,000 times a second
jmkasunich and the maximum frequency is 50,000 steps/sec
davidf at BP = 12000, max = 41600, I'm at 40000 ... That ok you think?
davidf I'm running at 12000...
jmkasunich it depends
jmkasunich you keep trying to connect BP to input scale, but thats not all there is
jmkasunich machine velocity also matters
robin_sz 50k steps .... 2000 steps per rev ... 25 revs/second ... thats  1.25 in/ second on 20 tpi screws
robin_sz 80 ipm ...
robin_sz yes?
davidf yes...
robin_sz umm I thought you said it did 120 ipm?
davidf But I'm running 40000, not 50000
jmkasunich stop!
* robin_sz estops
davidf not now, I've reconfigured for max vel = 60 ipm.
jmkasunich stopping davidf 
jmkasunich 40000 is your input scale, right?
robin_sz indeed. I did notice he was changing stuff halfway through the explanation
davidf yes
jmkasunich that has absolutely nothing at all to do with the 50000 steps/sec in robins math
* robin_sz suspects hes fiddling instead of reading.
jmkasunich you keep confusing scale and step-rate
* robin_sz nods
davidf ok sorry. I am trying & don't mean to be a pain...
jmkasunich just listen for a while
jmkasunich don't fiddle with anything
robin_sz scale is a physical thing .. how many pulses per inch. not a speed thing. its fixed by physucal properies like gearing and tpi
* robin_sz nods
davidf me too.
jmkasunich I'm trying to do this step-by-step, so you actually _understand_ what you are doing (and can do it yourself), instead of blindly taking advice from us
davidf please.
jmkasunich robin has a good idea, lets start with scale (I was starting with base period, maybe this is better)
jmkasunich like he said, scale is nothing more than pulses per inch
jmkasunich so it is determined by your screw, motor, and drive, and nothing else
jmkasunich it has nothing to do with base_period at all
jmkasunich (but once you understand how everything interacts, you can tweak things for the best combination)
jmkasunich lets forget for the moment that you can change the steps/rev on your drives
jmkasunich so, the screw pitch is fixed, the gear ratio is fixed (you don
jmkasunich oops
jmkasunich so, the screw pitch is fixed, the gear ratio is fixed (you don't have any gears, right), and the steps per rev are fixed
davidf right.
jmkasunich therefore, there can be only one value of scale
robin_sz steps per rev are selectable in his case ... which is kinda relevant
jmkasunich 20 revs per inch times 2000 steps per rev = 40000 steps/inch
jmkasunich yeah, I know, and I'll get back to that
robin_sz yep, just reminding for the later calculation
davidf yes
jmkasunich once we see the limits of 2000 steps per rev, he'll be able to see the reason for changing to something else
* robin_sz nods sagely
jmkasunich anyway, as long as the drive is set for 2000 steps/rev, scale _must_ be 40000 steps/inch
davidf yes I do understand that aleady jmkasunich 
jmkasunich now going back to base period, if its 12000, then the code runs 1e9/12000 times per second
jmkasunich 83,333
jmkasunich that gives you a max step rate of 83,333 / 2 = 41667 steps per second
davidf That's what I meant to say above.
jmkasunich _if_ you are gonna run right up to the theoritical limit, your max speed is 41667 steps/sec divided by 40000 steps/inch, or 1.0417 inches/second
jmkasunich 62.5 inches/min
davidf Im with you...
jmkasunich in practice, I don't think its wise to ask for more than about 2/3 of the theoritical maximum, 1/2 is even better
davidf ah.
jmkasunich do you want me to explain why? or skip that and move on?
davidf Please do explain.
jmkasunich ok
davidf If you don't mind...
jmkasunich at the max step rate, the code is flipplng the step bit every time it runs
jmkasunich on, off, on, off, on, off, etc
jmkasunich suppose you ask for a slightly lower frequency
jmkasunich I need numbers for this
jmkasunich lets assume BP = 10000, the numbers are simpler
davidf k
jmkasunich if you are doing on, off, on, off, on, off, etc, with each on and off lasting 10000nS, that is 20000uS between rising edges, or 50,000 steps/second
jmkasunich suppose you want 45000 steps/second
jmkasunich 45000 steps/sec = 22,222nS between steps
jmkasunich but our code is running every 10,000nS
jmkasunich so it can't do exactly 45000 steps/sec
davidf uh huh.
jmkasunich it can do on,off,on,off,on,off,on,off, for 20,000nS per step, or it can do on,off,off,on,off,off,on,off,off,on,off, etc, for 30,000nS between steps
davidf does get more complicated, I see.
jmkasunich if you want something in between, the best it can do is flip back and forth between on/off/on and on/off/off/on so that the average speed is what you want
jmkasunich and thats exactly what it does
jmkasunich but that flipping makes pulse jitter
jmkasunich the closer you go to the theoritical maximum speed, the worse the jitter gets
davidf The light is dawning... :)
jmkasunich in the case I just mentioned, you have to jitter between 20000nS (50000 steps/sec) and 30000nS (33333 steps/sec)
jmkasunich suppose instead of 45000 steps/sec you were asking for 4500
jmkasunich that means a period of 222,222nS
jmkasunich it still can't do that exactly
jmkasunich it will have to flip between 220000nS and 23000nS
davidf is that a typo?
jmkasunich 220000nS = 4545 steps/sec
jmkasunich yes
davidf k
jmkasunich 230000nS = 4347 steps/sec
davidf much smoother
jmkasunich right
robin_sz mm .. can I interject?
jmkasunich sure
robin_sz I tink they will both be about as smooth .. 
robin_sz the usteppign will tend to average out the jitter
jmkasunich hush you
jmkasunich I'm trying to explain to him, not confuse him
jmkasunich ;-)
robin_sz k
jmkasunich with EMC1, my explanation was definitely correct, because it would run at one speed or the other for a full millisecond, then flip to the other speed trying to average out to the right value
robin_sz true ... 
jmkasunich for emc2 its more complex, because emc2 flips between speeds on a pulse-by-pulse basis
jmkasunich that is better, but more complicated to understand
jmkasunich anyway, I think davidf now understands why you don't want to use every last bit of the theoritical speed
* Bo^Dick has quit ()
robin_sz but, basically, its smoother, and we all know smoother is better, because jitter saps power.
jmkasunich right
* pier has quit ("Leaving")
jmkasunich I forget where I was going with all this :-(
jmkasunich damn senility
davidf You were going right here, I think.
jmkasunich heh
davidf No really.
jmkasunich so, you now know how to calculate scale for any given screw/gear/motor/drive combo
jmkasunich and you know how to calculate max step frequency for any given base period
jmkasunich and you know that you _don't_ want to use the absolute max frequency
jmkasunich so, at BP = 12,000, max_freq = 41,600
davidf yes. I sort of did already, but I just didn't understand that I shouldn't be working so near  the max step frequency.
jmkasunich if you decide you are willing to go to 2/3 of that, max_working_freq = 27730 steps/sec
davidf 'k
jmkasunich 27730/40000 steps/inch = 0.693 inches/sec, or 41.6 inches/min
robin_sz fast enough for a small mill for sure
davidf That would be ok.
davidf Yes.
jmkasunich good
jmkasunich now - you are getting that with a base period of 12000nS
jmkasunich the code is running 83,000 times per second, which loads the PC quite a bit
davidf yes a lot.
jmkasunich it doesn't take much to delay the PC by 12000nS (thats only 1.2 millionths of a second)
jmkasunich oops, 12 millionths
jmkasunich still, pretty damned quick
jmkasunich so, what can we do?
jmkasunich your drive can be changed from 2000 steps/rev to 1000steps/rev
robin_sz buy a motion controller?
davidf lower the uSteps yes.
robin_sz oops ;)
jmkasunich that changes your scale from 40000 steps/inch to 20000steps/inch
davidf Cut the pulse rate in half.
jmkasunich if you want to keep the speed the same, the pulse rate is cut in half
jmkasunich so you can double the base period
davidf yes.
davidf I had all that actually.
jmkasunich (or split the difference - multiply the base period by 1.5 or so, that way you reduce the CPU load, and instead of going at 2/3 of the theoritical frequency you will only go at about 1/2
robin_sz such a nice and complete explanation though ...