Glad to hear it worked! As for more detailed explanation, the stepgen is made of 2 distinct software parts:
- stepgen.c <https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_pru_generic/stepgen.c> that run on the main beagle board black CPU and handle all acceleration/velocity/position calculations from the following inputs data/parameters: position-cmd, minvel, maxvel, maxaccel, position-scale. This calculate the velocity <https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_pru_generic/stepgen.c#L303-L365> and then the "step rate" <https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_pru_generic/stepgen.c#L367-L377>. This calculation is done every is 100000ns/0.1ms in your case (loadrt threads name1=fast period1=*100000*) - which seems btw a little fast to me for the beagle bone black but I don't know what other use.. (I typically use 1ms). - pru_stepdir.p <https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_pru_generic/pru_stepdir.p> that run on the dedicate PRU processor and generate the actual step and direction signals from the "step rate" input calculated by the part above. This architecture setup make it possible to generate quite high step rate with the beagle bone black. This is because the pru_stepdir.p can run much faster (pru_period=*2500* => 2500ns in your case) than the stepgen.c loop. There is also some error compensation in the stepgen.c algorithm so the feedback position (ie number of steps) where pru_stepdir.p is at is also taken into consideration when recalculating the velocity and step rate. When your stepper is stopped, if you do not set minvel (it will use the default value: 0), the velocity/"step rate" passed to pru_stepdir.p will be very close to 0 (maybe something like 0.000001) but most likely never actually be 0. Then at the next iteration of the loop, it will compensate from the feedback position error, and the velocity/"step rate" will be about the same but opposite sign so it oscillate between something like -0.000001, and then +0.0000001, keeping alternating between +/- and triggering a direction change on the dir pin every period stepgen.c runs (0.1ms in your case). For example, if you move +100 steps, it will oscillate between something 99.999 and 100.001 steps. You might not see any step on the step pin as 0.001 is far less than *1* step but the dir pin will switch direction all the time. By setting minvel to a non null value, stepgen.c will first check if the calculated velocity (in absolute value) is greater than minvel before passing it to pru_stepdir.p and if it is bellow that it will set the velocity to exactly 0.0 calculate the "step rate" and the pru_stepdir.p will not trigger any change on the dir pin. /Damien On Friday, 31 January 2020 11:47:12 UTC+1, jgnoss wrote: > > > > Damien you are my hero. > Yes, that did the trick. Still necessary a bit of fine tuning but it goes > in the direction I want. > And with your description of the proper way, I'll be there in no time. > > I was wondering what that minvel parameter is for, but now it makes a lot > of sense. > > thanks a lot, > Ju > -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- You received this message because you are subscribed to the Google Groups "Machinekit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/3b3f4b9a-db27-4543-a13d-e4fa9532c7cc%40googlegroups.com.
