Re: [Machinekit] Config error for Probotix cape. 'PRU control files not found in /sys/class/uio/uio0'
On 5/2/2017 2:25 PM, gburbeck wrote: > so the output immediately after a reboot: > > $ uname -a > > /Linux beaglebone 3.8.13-xenomai-r83 #1 Thu Jan 5 01:32:32 UTC 2017 armv71 > GNU/Linux/ That should be fine. > on trying to start machinekit -> the usual failure > inspected /sys/class/uio -> still empty > machinekit persistently failed to start > > reboot and did the same as above > after the first failure > inspected /sys/class/uio -> populated with eight symlinks uio0-uio7 > > subsequent start of machinekit was successful Hmm...maybe it's just a timing issue. Can you try manually loading the overlay prior to launching Machinekit? To do this, reboot, and before you try to launch machinekit run: config-pin overlay cape-universal ...then see if the uio devices are there. If they are, Machinekit should start normally. If the uio symlinks aren't there, the problem has something to do with the overlay not properly loading. ...but if it's a timing problem (the uio device symlinks taking too long to show up), I'm not sure why they wouldn't eventually appear and Machinekit ought to work if you tried launching it again. -- Charles Steinkuehler char...@steinkuehler.net -- 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.
Re: [Machinekit] Machinekit messaging (machinetalk farbic)
I preface this post with the acknowledgement that these areas are a movable feast, and at some point you just have to ship something I also ack that I'm not 100% conversant with MK's use cases and requirements. Nonetheless, I believe the following might be of interest. There are now several message formats that offer considerable speed advantages over Protbuf. In fact I wonder if it isn't possible to simplify MK by replacing ZeroMQ and Protobuf with something like Cap'n Proto, Maybe ZeroMQ + Flatbuffers if the MK components are (as good as) stateless and even SBE if random reads of messages is not required? For what it is worth I think the Flatbuffers note, see [3], that Cap'n Proto has "no optional fields to allow deprecating fields or serializing with missing fields for which defaults exist" might not be all it appears to be when you review [1]. In my opinion, the feature comparison in [1] is more credible than that at [3]. The issue seems to come down to how stateless/stateful are the different components of MK. My naive understanding is that the important parts MK are stateful. I won't by surprised to find out that is naive - kinda like that moment you were exposed to the dual representation in LP. Nonetheles I found these interesting, [1], [2]. In particular [2] was interesting for the comment that, given their targeted use cases it would make more sense to build ZeroMQ on Cap'n Proto rather than pass Cap'n Proto messages around with ZeroMQ. I might have the wrong end of the stick here Earlier I posted a comment that I wondered if driving and interacting with a 3D-Printer or any CNC machine wouldn't be easier/best using a FSM (if this was true Ragel was the suggested building block), If that idea isn't nuts, then I also wonder if ZeroMQ + Protobuf aren't doing together what Cap'n Proto can do alone? Again I have little insight into how much method chaining there is between MachineTalk mediated components, so the benefits may not outweigh the costs of switching. Anyway, hope someone found these new or interesting [1] https://capnproto.org/news/2014-06-17-capnproto-flatbuffers-sbe.html [2] https://capnproto.org/faq.html [3] http://google.github.io/flatbuffers/md__benchmarks.html On Monday, May 1, 2017 at 2:33:35 PM UTC+10, Alexander Rössler wrote: > > I wrote a blog post about the design decisions behind Machinetalk some > time ago: > > http://machinekoder.com/machinetalk-explained-part-2-middleware-requirements/ > > ZeroMQ won the game because is was the best networking middleware choice > for this application the time we started to work on Machinetalk. > > With Machinetalk GSL, Machinetalk also becomes transport agnostic. That > makes things like WebVCP possible. > > Am Freitag, 14. April 2017 07:12:25 UTC-5 schrieb Hedge Hog: >> >> Thanks Schooner, I wasn't aware it was dead - unfortunate. >> >> On Friday, April 14, 2017 at 9:50:30 PM UTC+10, Schooner wrote: >>> >>> >>> On 14/04/17 12:33, Hedge Hog wrote: >>> >>> Hi, >>> I'm new to Machinekit, via the world of 3D Printing. I'm new there too, >>> but doing my homework on 'best-practice' around boards and drivers lead me >>> here (via grbl, marlin, linuxcnc). >>> >>> I was very impressed you're using zeromq - my experience is that not too >>> many know about it outside of finance (at least that was true 7 years >>> ago). >>> It was that project choice that convinced someone here knows what they >>> are doing. >>> >>> Given that the use of ZeroMQ is in its early days in Machinekit I have >>> to ask: >>> >>> >>> It has been used since before the split with linuxcnc, so longer than >>> Machinetalk has existed as a separate entity >>> >>> Was there a reason(s) nanomsg wasn't adopted? I'm assuming it existed at >>> the time :) >>> Are there plans to migrate to nanomsg? >>> >>> >>> Shouldn't think so, the nanomsg project seems to have imploded whereas >>> zmq is actively maintained >>> http://sealedabstract.com/rants/nanomsg-postmortem-and-other-stories/ >>> >>> If it does what we need, why change? >>> >>> >>> >>> Best wishes >>> Hedgehog >>> -- >>> 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.
Re: [Machinekit] Config error for Probotix cape. 'PRU control files not found in /sys/class/uio/uio0'
so the output immediately after a reboot: $ uname -a *Linux beaglebone 3.8.13-xenomai-r83 #1 Thu Jan 5 01:32:32 UTC 2017 armv71 GNU/Linux* $ ls -l /sys/class/uio *total 0* on trying to start machinekit -> the usual failure inspected /sys/class/uio -> still empty machinekit persistently failed to start reboot and did the same as above after the first failure inspected /sys/class/uio -> populated with eight symlinks uio0-uio7 subsequent start of machinekit was successful -- 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.
Re: [Machinekit] Config error for Probotix cape. 'PRU control files not found in /sys/class/uio/uio0'
On 5/2/2017 11:38 AM, gburbeck wrote: > Hi Charles/Nick > > I too am having an issue with a PRU control files not found in > /sys/class/uio/uio0 >&2 error - I'm not sure it this will help but I'll > explain > my findings from the little testing I have done today. > > Yesterday I rebuilt my "bone-debian-8.5-machinekit-armhf-2016-07-18-4gb.img" > based machinekit to the "bone-debian-8.7-machinekit-armhf-2017-02-12-4gb.img" > and with a couple of small tweaks to the .hal and ,ini files I got it working. > > When I rebooted this morning I got the PRU error. So it's probably a kernel error, since the file that's gone missing is in sysfs and the problem happens after a reboot. What does "uname -a" report for your kernel version? Is there anything at all in /sys/class/uio ? ...besides the kernel, it could also be an issue with the device tree or maybe device naming conventions (ie: udev and friends), so it could be that a user-space update or configuration change triggered the problem even though it's related to the kernel. -- Charles Steinkuehler char...@steinkuehler.net -- 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.
Re: [Machinekit] Config error for Probotix cape. 'PRU control files not found in /sys/class/uio/uio0'
Hi Charles/Nick I too am having an issue with a PRU control files not found in /sys/class/uio/uio0 >&2 error - I'm not sure it this will help but I'll explain my findings from the little testing I have done today. Yesterday I rebuilt my "bone-debian-8.5-machinekit-armhf-2016-07-18-4gb.img" based machinekit to the "bone-debian-8.7-machinekit-armhf-2017-02-12-4gb.img" and with a couple of small tweaks to the .hal and ,ini files I got it working. When I rebooted this morning I got the PRU error. I have now had a little time to investigate and find that on the second attempt of starting machinekit it works - this is consistent across multiple reboot attempts. Happy to provide further input if requested. @Charles - I'd also like to thank you for all you effort. Reading your posts inspired me to get my linuxcnc system running on a Beaglebone and I am very grateful. -- 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.
Re: [Machinekit] MachineKit bindings
> On 02 May 2017, at 14:03, Hedge Hog wrote: > > finite state machines: I did contemplate whether such an approach to a > 3D-printer would add value. I'm still thinking. But I'm inclined to the > view that if it does, then it won't be specific to Ruby and would be of wider > interest. In which case using Ragel [4] to generate the FSM, and have > bindings to the c for various languages. I agree its not specific to a language. It helps keeping your application/machine manageable. I recently used the python transitions package. https://github.com/tyarkoni/transitions -- 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.
Re: [Machinekit] Machinekit messaging (machinetalk farbic)
I preface this post with the acknowledgement that these areas are a movable feast, and at some point you just have to ship something I also ack that I'm not 100% conversant with MK's use cases and requirements. Nonetheless, I believe the following might be of interest. There are now several message formats that offer considerable speed advantages over Protbuf. In fact I wonder if it isn't possible to simplify MK by replacing ZeroMQ and Protobuf with something like Cap'n Proto, ( maybe Flatbuffers if the MK components are (as good as) stateless and even SBE if random reads of messages is not required)? The issue seems to some down to how stateless/stateful are the different components of MK. My naive understanding is that the important parts MK are stateful. I won't by surprised to find out that is naive - kinda like that moment you were exposed to the dual representation in LP. Nonetheles I found these interesting, [1], [2]. In particular [2] was interesting for the comment that, given their targeted use cases it would make more sense to build ZeroMQ on Cap'n Proto rather than pass Cap'n Proto messages around with ZeroMQ. I might have the wrong end of the stick here Earlier I posted a comment that I wondered if driving and interacting with a 3D-Printer or any CNC machine wouldn't be easier/best using a FSM (if this was true Ragel was the suggested building block), If that idea isn't nuts, then I also wonder if ZeroMQ + Protobuf aren't doing together what Cap'n Proto can do alone? Again I have little insight into how much method chaining there is between MachineTalk mediated components, so the benefits may not outweigh the costs of switching. Anyway, hope someone found these new or interesting [1] https://capnproto.org/news/2014-06-17-capnproto-flatbuffers-sbe.html [2] https://capnproto.org/faq.html Best wishes Hedge On Monday, May 1, 2017 at 2:33:35 PM UTC+10, Alexander Rössler wrote: > > I wrote a blog post about the design decisions behind Machinetalk some > time ago: > > http://machinekoder.com/machinetalk-explained-part-2-middleware-requirements/ > > ZeroMQ won the game because is was the best networking middleware choice > for this application the time we started to work on Machinetalk. > > With Machinetalk GSL, Machinetalk also becomes transport agnostic. That > makes things like WebVCP possible. > > Am Freitag, 14. April 2017 07:12:25 UTC-5 schrieb Hedge Hog: >> >> Thanks Schooner, I wasn't aware it was dead - unfortunate. >> >> On Friday, April 14, 2017 at 9:50:30 PM UTC+10, Schooner wrote: >>> >>> >>> On 14/04/17 12:33, Hedge Hog wrote: >>> >>> Hi, >>> I'm new to Machinekit, via the world of 3D Printing. I'm new there too, >>> but doing my homework on 'best-practice' around boards and drivers lead me >>> here (via grbl, marlin, linuxcnc). >>> >>> I was very impressed you're using zeromq - my experience is that not too >>> many know about it outside of finance (at least that was true 7 years >>> ago). >>> It was that project choice that convinced someone here knows what they >>> are doing. >>> >>> Given that the use of ZeroMQ is in its early days in Machinekit I have >>> to ask: >>> >>> >>> It has been used since before the split with linuxcnc, so longer than >>> Machinetalk has existed as a separate entity >>> >>> Was there a reason(s) nanomsg wasn't adopted? I'm assuming it existed at >>> the time :) >>> Are there plans to migrate to nanomsg? >>> >>> >>> Shouldn't think so, the nanomsg project seems to have imploded whereas >>> zmq is actively maintained >>> http://sealedabstract.com/rants/nanomsg-postmortem-and-other-stories/ >>> >>> If it does what we need, why change? >>> >>> >>> >>> Best wishes >>> Hedgehog >>> -- >>> 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.
Re: [Machinekit] MachineKit bindings
For those following along at home: With respect to: protobuf: it looks like the reference library in Ruby is Google's upb, see [1], which is the encoder/decoder in MRI (see [2]) via Google's protobuf [3] finite state machines: I did contemplate whether such an approach to a 3D-printer would add value. I'm still thinking. But I'm inclined to the view that if it does, then it won't be specific to Ruby and would be of wider interest. In which case using Ragel [4] to generate the FSM, and have bindings to the c for various languages. [1]: https://github.com/google/upb [2]: http://blog.reverberate.org/2015/05/status-update-on-upb-and-my-new-role-on.html [3]: https://github.com/google/protobuf/tree/master/ruby [4]: http://www.colm.net/open-source/ragel/ On Monday, May 1, 2017 at 2:40:11 PM UTC+10, Alexander Rössler wrote: > > Depending on what you are trying to achieve there could also be other > solutions to support Ruby. If you are looking for Ruby bindings to support > Machinetalk then I recommend you to read up on this article: > http://machinekoder.com/machinetalk-explained-part-5-code-generation/ > > Here are the dependencies: > http://zeromq.org/bindings:ruby > https://github.com/ruby-protobuf/protobuf > https://github.com/tenderlove/dnssd > maybe: https://github.com/piotrmurach/finite_machine > > Create a basic working example -> create a code generator (probably > similar to the python one) -> run the code generator -> implement the > details > > Should give you working Machinetalk bindings pretty quickly. > > Am Freitag, 14. April 2017 19:16:25 UTC-5 schrieb Hedge Hog: >> >> Thanks for the prompt response Schooner... >> >> On Friday, April 14, 2017 at 11:05:12 PM UTC+10, Schooner wrote: >>> >>> >>> On 14/04/17 13:05, Hedge Hog wrote: >>> >>> >> >>> Unfortunately it seems that getting SWIG to consume the MK code base >>> won't be trivial and _may_ require changes to the code to play nice with >>> language bindings generated by SWIG. I'm new to swig. So, of course, I may >>> just be revealing my ignorance and there are no changes required to the >>> base code :) >>> >>> >>> There are already comprehensive python bindings and a lot of them are >>> generated by cython as part of the build. >>> That would be a place to start looking. >>> There are additional python bindings specifically for machinetalk >>> https://github.com/machinekit/pymachinetalk >>> >>> Thanks. That is where I started as a way to identify the MK parts >> (currently) usefully publicized. >> >> You won't be able to just run a tool and magically generate bindings, the >>> code is far too complex and interdependent. >>> >> >> That is correct I don't think SWIG even suggests that. >> In fact a quick glance at SWIG 3.0 would persuade any bystander that >> there is no magic. >> >> I think there is an understanding that to be least painful your API would >> need to be written with the target languages _and_ SWIG in mind. >> That imposes some constraints in exchange for some benefits. >> Some projects (correctly) reject that compromise, saying it is up to the >> external libraries to make their syntax/idioms/semantics fit the parent >> project. >> I suppose I'm trying to gauge where MK community stand on these >> trade-offs. >> >> I would suggest that if anyone ever considered making an API change that >> taking into consideration the ability to support otherlanguage bindings >> might be a benefit to weigh against the costs of the change. >> >> The value-add proposition is that you could (MK code and external targets >> permitting) use SWIG to generate several bindings with little additional >> effort. >> Of course if some language forms a community large enough it is possible >> they will hand craft their own - but that takes a large community and we >> are not there yet. >> >> >> >> I have no idea if there is an appetite for Ruby bindings, I have no use >>> for the existing python ones so am not the person to ask :) >>> >>> Thanks again >> Best wishes >> Hedgehog >> >>> >>> The question becomes: >>> Is there appetite in the project to support SWIG generated bindings >>> (letting/encouraging each language's aficionados build what they want on >>> top of them)? >>> Should any SWIG interface files sit in the MK repo or as a separate >>> repo? >>> I'd imagine the generated code would sit in a separate repo unless >>> you/we wanted to support generating and testing these bindings as part of >>> the build process? >>> >>> Best wishes >>> Hedgehog >>> >>> PS The error I've hit with a very trivial p-o-c SWIG interface file is: >>> >>> $ swig -cpperraswarn -xml machinekit.i >>> ../../src/rtapi/rtapi.h:70: Warning 205: CPP #error ""Please define >>> either RTAPI or ULAPI!"". >>> ../../src/hal/lib/hal.h:130: Warning 205: CPP #error "HAL needs >>> RTAPI/ULAPI, check makefile and flags". >>> ../../src/rtapi/rtapi.h:325: Error: Syntax error - possibly a missing >>> semicolon. >>> >>> whe
Re: [Machinekit] Re: Cant use custom compiled kinematics - insmod error
On 02/05/17 10:10, schoone...@btinternet.com wrote: On 01/05/17 17:58, David Bynoe wrote: Thank you for the tips, that relink solves the install problem but it doesn't fix the insmod errors, I get the same ones as before. The kinematics file I want to use is this one: https://github.com/dbynoe/Spark-Drawbot/blob/master/kinematics/drawbotkins.c That version has automatic homing features and some other stuff that will be removed but its known working on linuxcnc. It was built for this machine: https://www.youtube.com/watch?v=hrsDBdnj5E8 I am curious about what changed, I thought the whole point of comp was that it allowed the building of hal components and kinematics files outside of the source tree. Seems crazy that a full rebuild/reinstall is necessary for one minor piece of translation code. comp has never been for compiling kinematics files outside the tree. It is for building realtime modules from scripts requiring the minimal C knowledge by the user. It might be possible to build your file with comp, if you specify the correct linkage, but you will notice that all the other kinematic modules are not built using it. The kinematics file you are trying to use has no support for vtables, that is at the heart of the problem and is what has changed since it allegedly 'worked OK' If you switch on debugging before launching and look at /var/log/linuxcnc.log you will find the point of failure as (yes I have built it) May 2 09:15:17 INTEL-i7 msgd:0: hal_lib:22291:rt halg_reference_vtable:104 HAL error: vtable 'drawbotkins' version 1000 not found May 2 09:15:17 INTEL-i7 msgd:0: hal_lib:22291:rt MOTION: hal_reference_vtable(drawbotkins,1000) failed: -2 You need to read https://github.com/machinekit/machinekit/issues/438 and look at the changes made to kinematics.h and trivkins.c to use vtables I have built the drawbotkins module in the file tree and created a demo sim for it as per the screenshot attached. It is of general interest as it demonstrates the vtable code required and for the amended kinematics module itself, so I will get it included in the repo kinematics code and it will be in the packages in a day or so. regards The PR is at https://github.com/machinekit/machinekit/pull/1205 You can see the code changes etc in that and watch it to see when it is likely the new packages will be available (about 3 hours after merge) The sim is just to demo loading and homing, if you try to run gcode you will get in all sorts of problems :-P It would be good if you could provide a better sim in due course. I have an older version of a machine kit image on a beaglebone circa 2015 and comp just worked out of the box. Wanted to modernize so I could use a touch screen and wifi. Here is it running before: https://www.youtube.com/watch?v=z0YQYwmbbT0 On Monday, 1 May 2017 07:03:13 UTC-7, Schooner wrote: On 01/05/17 14:11, Marius Alksnys wrote: > AFAIR I used this command: > sudo ln -s /usr/lib/linuxcnc/xenomai /usr/lib/linuxcnc/posix > > After that comp installs components correctly. That will get around the issue of posix flavour and give somewhere to install to and source from, certainly.;-) There may well be an issue still with the kinematics linkage as per the previous message I quoted, that is best dealt with by building within the source tree. Give comp a try and see what happens, if you get an insmod error that it is unable to find vtable or similar you are back to a source build > > 04/30/2017 09:48 PM, David Bynoe rašė: >> I am having issues getting custom kinematics modules compiled and >> working on the debian jessie machinekit system image for beagle bone >> black. (full system details below) >
Re: [Machinekit] Re: Stepper motors (3D-Printing): TP and slew-range
> On 02 May 2017, at 08:18, Hedge Hog 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/ Will your use case include a user setting these pins in Hal? In not, then is this "privilege" enough? 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. If you don't want that you need to be sure that the limits on the tp are lower than your stepgen. > 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+unsubscr...@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.
