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 ...