Hedge Hog- I have been struggling with what appear to be similar issues with the general concepts that you have been. I have written some notes to myself about what I have discovered at [link](https://github.com/bschousek/piphat/blob/master/idiot.md) and perhaps they will be useful to you as well.
Brian On Wednesday, May 3, 2017 at 7:31:52 PM UTC-5, Hedge Hog wrote: > > > On Tuesday, May 2, 2017 at 5:35:33 PM UTC+10, Bas de Bruijn wrote: >> >> >> >> On 02 May 2017, at 08:18, Hedge Hog <hedgeho...@gmail.com> wrote: >> >> Thanks for taking the time to reply Alex, >> >> Re Q3 and using HAL to control the stepper motor. Is there some example >> you know of that I could review? >> >> >> Why don't you take the stepgen maxvel and maxaccel pins? You'll have to >> set them to a certain value anyway. >> http://www.machinekit.io/docs/man/man9/hal_pru_generic/ >> <http://www.google.com/url?q=http%3A%2F%2Fwww.machinekit.io%2Fdocs%2Fman%2Fman9%2Fhal_pru_generic%2F&sa=D&sntz=1&usg=AFQjCNFwDekP5rJs4HiKcHW7vc8BvSlp9Q> >> > > Thanks for that reference, I'll start there. Apologies if I appear to be > obtuse or needy. > It strikes me as quite a steep learning curve, and I'm really struggling > to wrap my head a round: a) the components b) where they are documented and > c) which re relevant to the issue/problem/question I have. > > >> Will your use case include a user setting these pins in Hal? In not, then >> is this "privilege" enough? >> > > I'm sorry I do not know what to say. > Are HAL instructions/settings compiled in any way? are they compiled at > run time? Are the compiled into the binary that is distributed to the user? > Do they just sit there and are interpreted - so the user could edit them? > I feel quite embarrassed :) I've been reading for several days and I do > not feel I've even managed to get some f the basics straight in my mind. > > >> If the tp has bigger values then the stepgen has. The stepgen will not be >> able to keep up and will be limited to these values. So you won't violate >> your hardware specs, but get deviation from the path. >> > > Okay this is great. > There are TP settings and stepgen settings. Rather than pester you with > Q's - Where is best to read about these sorts of component hierarchies, and > who can stand on whose toes? > > >> If you don't want that you need to be sure that the limits on the tp are >> lower than your stepgen. >> > > Okay this is great too. > It sounds like I'm responsible for ensuring that there are no conflicts, > i.e. MK does not, by default, ensure the TP path is adhered to by adjusting > relevant settings (maybe with warnings) to ensure that TP settings are > lower than the stepgen settings. > > Again rather than reproduce/rewrite the docs in the mail-list, could you > point me to where in the docs this these responsibilities are described/ > > Best wishes > Hedge > > >> If not, does this approach employ some sort of Trajectory Planner API, or >> would this approach require implementing a TP from scratch. >> >> If I understand correctly, that understanding comes mostly from reviewing >> some of the issues in GRBL, a TP is a non-trivial undertaking. >> >> Best wishes >> Hedge >> >> On Monday, May 1, 2017 at 2:47:22 PM UTC+10, Alexander Rössler wrote: >>> >>> I can answer Q3: >>> You can protect your stepper motor spec on the HAL level. To ensure the >>> acceleration and maximum velocity values are never violated one could drive >>> the stepper via PID loop tuned with the correct parameters. If you want to >>> ensure the user cannot edit or override the values you can compile them >>> into a HAL component. >>> >>> Am Samstag, 15. April 2017 07:49:33 UTC-5 schrieb Hedge Hog: >>>> >>>> Hi, >>>> I am considering a 3D printing use case, which is likely different from >>>> most CNC use cases in that the bed load/inertia is relatively >>>> constant/stable. >>>> That's a generalization, but probably reasonable to say that in 80% of >>>> cases the mass and forces will be within a very narrow range. >>>> Compared to say a CNC machine carving a cubic foot of wood then a cubic >>>> foot of steel. >>>> >>>> I have read [1]-[8] and have three questions. >>>> From [1]-[8] I can't see that the pull-in/pull-out envelope (or slew >>>> range) is identified for a stepper motor. Nor does it appear that inputs >>>> are sought that would allow them to be guesstimated. >>>> >>>> Q1) Am I wrong (and there is a set of approximations used to define the >>>> slew range given the inputs sought)? >>>> >>>> AFAICT: >>>> a) the trajectory planner might be working with a single point on the >>>> pull-out curve of a motor, so you can expect the TP to try change >>>> direction >>>> in the slew-range of a stepper motor. >>>> b) The TP does not consider/use the stop-start range where direction >>>> can be reversed without deceleration. >>>> >>>> Q2) Which of the above possibilities is applicable? >>>> >>>> Q3) Is there a way to ensure that an end user cannot get the trajectory >>>> planner to violate a stepper motors specs? >>>> I suppose these settings would have to be a compiled, or set by >>>> privileged user access, and can't be overridden by a configure file >>>> settings. >>>> >>>> Thanks again for all the effort that has gone into MachineKit >>>> >>>> Best wishes >>>> Hedgehog >>>> >>>> [1]: http://www.machinekit.io/docs/quickstart/stepper_quickstart/ >>>> [2]: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Stepper_Formulas >>>> [3]: >>>> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Stepper_Motor_Speed_Limitations >>>> [4]: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Mechanical_Spreadsheet >>>> [5]: http://www.soundproofingforum.co.uk/halitosis/ >>>> [6]*: http://www.machinekit.io/docs/config/stepconf/ >>>> [7]: http://www.machinekit.io/docs/common/Stepper_Diagnostics/ >>>> [8]: http://www.machinekit.io/docs/motion/tweaking_steppers/ >>>> >>>> -- >> 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 machinekit+...@googlegroups.com. >> Visit this group at https://groups.google.com/group/machinekit. >> For more options, visit https://groups.google.com/d/optout. >> >> -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
