Re: [Machinekit] Config error for Probotix cape. 'PRU control files not found in /sys/class/uio/uio0'

2017-05-02 Thread Charles Steinkuehler
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)

2017-05-02 Thread Hedge Hog
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'

2017-05-02 Thread gburbeck
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'

2017-05-02 Thread Charles Steinkuehler
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'

2017-05-02 Thread gburbeck
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

2017-05-02 Thread Bas de Bruijn


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

2017-05-02 Thread Hedge Hog
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

2017-05-02 Thread Hedge Hog
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

2017-05-02 Thread schoone...@btinternet.com

  
  

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

2017-05-02 Thread Bas de Bruijn


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