[1] could certainly use some updating. My key high level insight from today is that the block diagram for the trajectory planner is now *outside* the emcmot loop per this blog entry <http://blog.machinekit.io/2015/02/loadable-trajectory-modules.html>. Many of the internals of the trajectory planner are exposed as HAL pins and I was making things much more complicated than they had to be. I remain convinced that Python could be fast enough to meet the timing requirements, but currently the easier path is to create a realtime component using C. This is *greatly* simplified by using the component generator documented here <http://www.machinekit.io/docs/hal/comp/> and here <http://www.machinekit.io/docs/hal/instcomp_writing_a_component/> and elsewhere. It takes care of 99% of the boilerplate and makes it easy to link C functions to HAL pins. Then the exposed trajectory planner pins can be connected via HAL commands to my C function.
Note to my future self: look at the documentation for instcomp and wordsmith it to not rely on back-references to the comp documentation. [1]: http://www.machinekit.io/docs/code/Code_Notes/#motion-controller-introduction <http://www.google.com/url?q=http%3A%2F%2Fwww.machinekit.io%2Fdocs%2Fcode%2FCode_Notes%2F%23motion-controller-introduction&sa=D&sntz=1&usg=AFQjCNGY6UYFKnqvT5uTn_hlW61_-K_c1g> On Tuesday, May 9, 2017 at 6:14:35 PM UTC-5, Hedge Hog wrote: > > > > On Tuesday, May 9, 2017 at 12:30:09 PM UTC+10, Brian Schousek wrote: >> >> I'm having good luck achieving microsecond resolution pulse trains using >> DMA on a Raspberry Pi at near real-time rates, and I'm confident that with >> some optimization this will be workable for step generation with low cpu >> usage. I currently have this step generation hacked into a Machinekit >> configuration which monitors the trajectory planner position pins. When a >> loop in Python detects a change in axis.0.motor-pos-cmd, for example, it >> queries axis.0.joint-vel-cmd and creates a stream of n steps at the proper >> frequency where n is the number of steps that will fit into my millisecond >> servo loop. >> >> The DMA library I am using is capable of synchronizing sequential >> waveforms, so I would like to be able to look ahead in the trajectory >> planner queue a step or two and construct the waveforms in advance where >> possible, which should help solve some latency issues. I have a few >> questions towards achieving this: >> >> 1) Is there a better mechanism to detect a new trajectory step than >> monitoring changes in the position-commanded HAL pin? >> 2) Is there visibility into the trajectory planning queue somewhere? >> 3) Perhaps these are not exposed in the current Python bindings; if not, >> is there a good example of accessing it via C calls? >> 4) Are there any other tips on source code areas I should investigate as >> resources in putting this together? >> >> Brian >> > > I have similar questions, although I behind you on the implementation > curve. Is there any chance you could add you notes/learnings to the MK > documentation: > here at [1] is one place you might place any high level insight that you > feel might help. > here at [2] is probably where you can add the most value :) > > If time or other constraints prevent you adding to the docs could you post > your notes here? > > [1]: > http://www.machinekit.io/docs/code/Code_Notes/#motion-controller-introduction > [2]: > http://www.machinekit.io/docs/code/Code_Notes/#backlash-and-screw-error-compensation > > Best wishes > > > > -- 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]. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
