[Machinekit] Re: protobuf/zeromq definition<->??<->HAL

[Hedge Hog]

I think I can answer one of my own questions, Brian would be interested in 
hearing your experience (see below):

On Friday, May 12, 2017 at 10:11:54 AM UTC+10, Hedge Hog wrote:
>
>
>
> On Friday, May 5, 2017 at 5:14:42 AM UTC+10, Alexander Rössler wrote:
>>
>> Hi Brian,
>>
>> This is indeed a complex problem which Protobuf does not solve out of the 
>> box. This problem was one of the reasons why I started the Machinetalk GSL 
>> project. The protocol models describe to which Machinetalk message a 
>> Protobuf message belongs. 
>> https://github.com/machinekoder/machinetalk-gsl
>>
>> There is also code generator for the documentation in the repository. The 
>> generated docs can be found here: 
>> https://github.com/machinekoder/machinetalk-doc
>>
>> If you are more interested in this part of Machinetalk I recommend you to 
>> read 
>> http://machinekoder.com/machinetalk-explained-part-5-code-generation/
>>
>> As for the messages in motcmds.proto -> most of the messages aren't in 
>> use by any service yet. Michael originally created them for the eventual 
>> replacement of NML by Machinetalk.
>>
>
> Can you elaborate on the status of MT in terms of replacing NML?
>

According to Michael Haberler at [1]: "It is so bad I think 'fixing up' NML 
is hopeless - it's beyond repair."
so that sounds like NML is to be retired completly.

The discussions at [1] also outlines some of the 'business requirements' a 
replacement would need to provide.

Unless I am reading this wrong it does not sound like the issue was that 
the message types or content was the pain point.
That is, the set of instructions/actions and the data/information being 
passed around are OK.  
It is more the implementation detail/choices that were painful.

Brian, 
I would be interesting to hear your experiences.
E.g I wanted to do task A, which i expected to be a single message, instead 
I had to do K, then B, only then could I do A.  Which is nuts because I had 
already done K and B in getting C.  And it only makes sense (or you can 
only) do A from C.

Hope that makes sense.

Best wishes



[1]: 
http://emc-developers.narkive.com/MNnPnur8/rfc-requirements-for-linuxcnc-middleware
 

> Also what the intent/scope of MT is in terms of replacing NML?
>
> For example:
> Is the goal to make MT messages map as exactly to NML messages? Or are you 
> retiring some NML messages?
> Is the goal to make MT live alongside NML or will there be a hard cut over 
> from NML to MT?
>
> Are the requirements for MT settled?
>
> If it is not too late, can I ask that the use of required elements in the 
> protobuf messages be reconsidered?
>
> Specifically, in the light of the comments from the protobuf2 dev that it 
> was a mistake, and caused pain at Google:
>
>
> https://capnproto.org/faq.html#how-do-i-make-a-field-required-like-in-protocol-buffers
>  
> I'd suggest that if Google struggled with this we are guaranteed that our 
> users will find this painful.  
> Especially if the one of the use case is that users be able to hook up 
> various MK components/machines from time to time.
>
> I've developed some thoughts on the MT requirements, but haven't pushed 
> them because they are incomplete and I'd rather show a PoC.
> If anyone wants to review or contribute let me know and I'll push more 
> regularly.
>
>
>> Best regards,
>> Alexander
>>
>> Am Montag, 1. Mai 2017 12:22:47 UTC-5 schrieb Brian Schousek:
>>>
>>> I understand the motivation and appreciate the beauty of the messaging 
>>> approach. I seem to be missing something that is probably obvious in the 
>>> mechanics however. I can understand individual elements of 
>>> publish/subscribe, encode/decode, the anddemo at 
>>> https://github.com/machinekit/pymachinetalk 
>>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fmachinekit%2Fpymachinetalk=D=1=AFQjCNHgC5O9RyQQVRugtXpbQ2mrYp91Mw>
>>>  
>>> makes sense to me, etc.
>>>
>>
> Is this considered a canonical example of usage or more of a "hello world" 
> of MT?
>
> Best wishes
>
> Hedge
>
> I don't understand how to figure out how to initiate a channel containing 
>>> a given message. For example, I would like to monitor the messages as 
>>> defined in motcmds.proto 
>>> <https://github.com/machinekit/machinetalk-protobuf/blob/master/src/machinetalk/protobuf/motcmds.proto>.
>>>  
>>> Are these message streams by definition flying around somewhere that I just 
>>> need to listen to? If so, where does it happen so I can look at the code 
>>> and further understand. Or perhaps th

[Machinekit] Re: MT Requirement: Start-up sequence

[Hedge Hog]

For anyone following along at home

On Tuesday, May 9, 2017 at 3:39:09 PM UTC+10, Hedge Hog wrote:
>
> Hi,
> Alex has an excellent 5-part series explaining the Machinetalk 
> requirements, part 2 I refer to is here [1].
>
> The requirement at hand is described as:
>
>
> *Start-up sequence*
> *The middleware shall only use libraries, standards, and tools, that 
> already have been widely adopted by the open source community and industry 
> to keep long-term maintenance and support costs low.*
>

The original list of requirements is at [1].

According to [1] this is 5.2:
"The message transport should support any order of startup of producers and 
consumers of messages."
 
The linuxCNC maillist discussion is at [2]

[1]: http://static.mah.priv.at/public/wip/html/wip/requirements.html
[2]: 
http://emc-developers.narkive.com/MNnPnur8/rfc-requirements-for-linuxcnc-middleware

Hope that helps.

Best wishes.


However this is the same as the *Based on Widely Adopted Solutions* 
> requirement.
>
> Can anyone point to the correct startup sequence requirement?
>
> [1]: machinekoder.com/machinetalk-explained-part-2-middleware-requirements
>
> Thanks in advance
>
> 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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: protobuf/zeromq definition<->??<->HAL

[Hedge Hog]

On Friday, May 5, 2017 at 5:14:42 AM UTC+10, Alexander Rössler wrote:
>
> Hi Brian,
>
> This is indeed a complex problem which Protobuf does not solve out of the 
> box. This problem was one of the reasons why I started the Machinetalk GSL 
> project. The protocol models describe to which Machinetalk message a 
> Protobuf message belongs. 
> https://github.com/machinekoder/machinetalk-gsl
>
> There is also code generator for the documentation in the repository. The 
> generated docs can be found here: 
> https://github.com/machinekoder/machinetalk-doc
>
> If you are more interested in this part of Machinetalk I recommend you to 
> read http://machinekoder.com/machinetalk-explained-part-5-code-generation/
>
> As for the messages in motcmds.proto -> most of the messages aren't in use 
> by any service yet. Michael originally created them for the eventual 
> replacement of NML by Machinetalk.
>

Can you elaborate on the status of MT in terms of replacing NML?
Also what the intent/scope of MT is in terms of replacing NML?

For example:
Is the goal to make MT messages map as exactly to NML messages? Or are you 
retiring some NML messages?
Is the goal to make MT live alongside NML or will there be a hard cut over 
from NML to MT?

Are the requirements for MT settled?

If it is not too late, can I ask that the use of required elements in the 
protobuf messages be reconsidered?

Specifically, in the light of the comments from the protobuf2 dev that it 
was a mistake, and caused pain at Google:

https://capnproto.org/faq.html#how-do-i-make-a-field-required-like-in-protocol-buffers
 
I'd suggest that if Google struggled with this we are guaranteed that our 
users will find this painful.  
Especially if the one of the use case is that users be able to hook up 
various MK components/machines from time to time.

I've developed some thoughts on the MT requirements, but haven't pushed 
them because they are incomplete and I'd rather show a PoC.
If anyone wants to review or contribute let me know and I'll push more 
regularly.


> Best regards,
> Alexander
>
> Am Montag, 1. Mai 2017 12:22:47 UTC-5 schrieb Brian Schousek:
>>
>> I understand the motivation and appreciate the beauty of the messaging 
>> approach. I seem to be missing something that is probably obvious in the 
>> mechanics however. I can understand individual elements of 
>> publish/subscribe, encode/decode, the anddemo at 
>> https://github.com/machinekit/pymachinetalk 
>> 
>>  
>> makes sense to me, etc.
>>
>
Is this considered a canonical example of usage or more of a "hello world" 
of MT?

Best wishes

Hedge

I don't understand how to figure out how to initiate a channel containing a 
>> given message. For example, I would like to monitor the messages as defined 
>> in motcmds.proto 
>> .
>>  
>> Are these message streams by definition flying around somewhere that I just 
>> need to listen to? If so, where does it happen so I can look at the code 
>> and further understand. Or perhaps these messages need to be turned on 
>> somewhere? Or perhaps the messages are just defined here and it is left as 
>> an exercise to the coder to generate them?
>>
>> In short, I feel like I understand the overarching intent, and also 
>> understand much of the underlying detail, but I am not able to figure out 
>> the connective tissue between the two. Would somebody please point me 
>> towards enlightenment?
>>
>> Brian
>>
>

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

[Machinekit] Re: How do I hook into the trajectory planner queue?

[Hedge Hog]

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 machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Simplified MT lang bindings using Ragel: PoC

[Hedge Hog]

Hi,
When initially reading the mail list I noted several people acknowledging 
that MK/MT is a steep learning curve with a complex software stack.
That has been my experience.

While this poc introduces Ragel, it loosens the requirement to use GSL.  
In addition with Ragel the project introduces the tool that is generally 
acknowledged to produce very efficient FSM's.
There is some learning curve for Ragel.  The benefit is you add a very 
powerful tool to your IP.

Below is a gist showing a proof-of-concept for a much simpler approach to 
Machinetalk bindings.
I've used ruby as the example just to keep it simple.

Other approaches are also possible, and I don't claim this is the best 
practice

https://gist.github.com/hedgehog/de4b423f31451035514362a4a2e0f7c6

It would seem that one way to ensure users are running the same logic 
across different bindings - without restricting their ability to 
explore/experiment with alternative implementations - is to have a 
reference implementation in c (or bash for scripting) which the 3rd party 
bindings are encouraged to call.

Swapping out the reference/MT implementation with a custom/experimental one 
then becomes a one-liner in the client library.

I think comments are best recorded here, with changes to the gist forked 
over at github.

Appreciate any thoughts on this or other approaches.  

Best wishes
Hedge

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

[Machinekit] MK/MT CAP constraints

[Hedge Hog]

Hi, 
While these topics are on my mind.

Is there a MK view/position yet on which of the CAP constraints MK/MT 
require?

In this post, here [1], Michael makes a clear distinction between RT and 
non-RT domains.
However it is not clear to me which of Consistency, Availability or 
Partition tolerance MK/MT requires.  
Is it a free for all, with every implementation free to choose? Can they be 
different across components? etc. etc.  

Are there any requirements a MT implementation must satisfy/can-assume?

[1]: http://lists.ros.org/pipermail/ros-users/2015-September/069664.html

Appreciate any insights

Best wishes
Hedge

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

[Machinekit] MT Requirement: Start-up sequence

[Hedge Hog]

Hi,
Alex has an excellent 5-part series explaining the Machinetalk 
requirements, part 2 I refer to is here [1].

The requirement at hand is described as:


*Start-up sequence*
*The middleware shall only use libraries, standards, and tools, that 
already have been widely adopted by the open source community and industry 
to keep long-term maintenance and support costs low.*
However this is the same as the *Based on Widely Adopted Solutions* 
requirement.

Can anyone point to the correct startup sequence requirement?

[1]: machinekoder.com/machinetalk-explained-part-2-middleware-requirements

Thanks in advance

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

[Hedge Hog]

On Saturday, May 6, 2017 at 7:16:52 PM UTC+10, Bas de Bruijn wrote:
>
>
> > On 06 May 2017, at 10:00, Alexander Rössler <alexander@roessler.systems> 
> wrote: 
> > 
> > 
> > Hedge Hog writes: 
> > 
> >> On Fri, May 5, 2017 at 5:52 AM, Alexander Rössler 
> >> <mail.ar...@gmail.com > wrote: 
> >>> 
> >>> 
> >>> Am Dienstag, 2. Mai 2017 14:25:11 UTC-5 schrieb Hedge Hog: 
> >>>> 
> >>>>  
> >>>> 
> >>>> There are now several message formats that offer considerable speed 
> >>>> advantages over Protbuf. 
> >>> 
> >>> So far speed has not been a problem with Protobuf. However, 
> Flatbuffers look 
> >>> very interesting since the API and supported languages seems similar 
> to 
> >>> Protobuf. On the other hand, Protobuf has a very wide adoption and is 
> can 
> >>> also be used for storing data. 
> >> 
> >> Can you elaborate on the 'storing data' requirement? 
> >> Is this a MUST, RECOMMENDED, or OPTIONAL requirement? 
> > Storing data is definitely an OPTIONAL requirement. 
> > 
> >> 
> >> Is there a requirement that the message decoding support random reads? 
> > Not necessarily. However, there are some messages that are relatively 
> > big such as the status messages from mkwrapper. The concept Machinetalk 
> > uses is incremental and full updates to sync the state. The only 
> > requirement that arises from this concept is that it must be possible to 
> > detect optional fields which are not set. On the other hand, a different 
> > message design might also solve this problem. 
> > 
> >> 
> >> If not I'd lean toward SBE for speed.  However it does bring with it 
> >> some version constraints - from memory - new fields have to be added 
> >> at the end of the existing version.  Happy to stand corrected. 
> >> 
> >> Anyway, I *think* that MK/T messages are sufficiently small that 
> >> random reading is not a MUST have requirement? 
> > It depends on how the user design the messages of a MT procotol. 
> > 
> >> 
> >>>> 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]. 
> >>> 
> >>> Most of the other messaging middleware only support either RPC or 
> >>> publish-subscribe. Machinetalk services are stateless on the server 
> side and 
> >>> stateful on the client side. 
> >> 
> >> Thanks this is very useful to know. 
> >> 
> >>> The use of multi-channel protocols brings some 
> >>> additional advantages that we do not fully leverage yet. Such an 
> advantage 
> >>> would be to use a multicast protocol for publishing status updates 
> >>> efficiently to multiple clients and at the same time having a reliable 
> RPC 
> >>> connection to execute commands. 
> >> 
> >> Do I understand correctly: 
> >> - The RPC client/server is the responsibility of the language/library 
> >> that is interfacing this. I now see that the RPC client/server events 
> >> and states are defined in the SCXML files in the machinetalk-gsl repo 
> >> - thanks. 
> >> - The canonical RPC client/server implementation is in pymachinetalk? 
> >> - Different languages will be using different implementations of all 
> the FSM. 
> >> 
> >>> The only attractive alternative to 
> >>> Machinetalk I have found so far is DDS. 
> >> 
> >> Interesting I had thought of DDS as an alternative ZeroMQ+ProtoBuf 
> >> rather than Machinetalk. 
> >> Wouldn't you still need some logic (MT) to interface 'politely' with 
> MK? 
> >> Anyway, even say you didn't: MT would still be needed as an API for 
> >> which the MK community could build different implementations and link 

Re: [Machinekit] MachineKit bindings

[Hedge Hog]

Thanks again Alex,
I'll look into those definitions.

Best wishes
Hedge

On Fri, May 5, 2017 at 6:03 AM, Alexander Rössler
<mail.aroess...@gmail.com> wrote:
>
>
> Am Dienstag, 2. Mai 2017 07:03:43 UTC-5 schrieb 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]
>
> Okay, good.
>
>>
>>
>> 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.
>
> The idea is to keep the FSM language independent which is reached by
> modeling the FSM in the SCXML format:
> https://github.com/machinekoder/machinetalk-gsl/blob/master/models/machinetalk/common/rpcclient_fsm.scxml
> You can choose any (or even none) underlying FSM library to work with.
>
>>
>> [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 co

Re: [Machinekit] Re: Stepper motors (3D-Printing): TP and slew-range

[Hedge Hog]

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=D=1=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 viola

Re: [Machinekit] MachineKit bindings

[Hedge Hog]

On Wednesday, May 3, 2017 at 1:35:38 AM UTC+10, Bas de Bruijn wrote:
>
>
>
> > On 02 May 2017, at 14:03, Hedge Hog <hedgeho...@gmail.com > 
> 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 
>

Thanks Bas.  Appreciate the confirmation. 

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

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

Re: [Machinekit] Machinekit messaging (machinetalk farbic)

[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

[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 separ

Re: [Machinekit] Machinekit messaging (machinetalk farbic)

[Hedge Hog]

again, thanks Alex.  that series looks like the perfect starting point - 
apologies for missing them - my Gogle fu must be slipping.

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.

[Machinekit] Re: Stepper motors (3D-Printing): TP and slew-range

[Hedge Hog]

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

[Machinekit] Stepper motors (3D-Printing): TP and slew-range

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

Re: [Machinekit] MachineKit bindings

[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.
>
> where machinekit.i is: 
> /*Using SWIG 3.0.12
> Install instructions here:
> http://weegreenblobbie.com/?p=263
>
> COMMAND:
> swig -cpperraswarn -E -xml machinekit.i
> */
>
> %module machinekit
> /* Structure is based on (14 April 2017)
>  http://machinekoder.com/machinetalk-explained-part-1-introduction/
>  */
> /*%include "machinetalk.i"*/
> %include "hal.i"
> /*%include "taskexecutor.i"*/
> /*%include "motioncontroller.i"*/
> /*%include "trajectoryplanner.i"*/
> /*%include "iocontroller.i"*/
> /*%include "gcode.i"*/
>
> and hal.i is:
>
> %module hal
>  %{
>  /* Includes the header in the wrapper code */
>  #include "../../src/rtapi/rtapi.h"
>  #include "../../src/hal/lib/hal.h"
>  %}
>
>  /* Parse the header file to generate wrappers */
>  %include "../../src/rtapi/rtapi.h"
>  %include "../../src/hal/lib/hal.h"  //HAL needs RTAPI/ULAPI
>
>
> -- 
> 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 messaging (machinetalk farbic)

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

[Machinekit] MachineKit bindings

[Hedge Hog]

Hi,
I've just introduced myself as a newbie in a previous post, and was hoping 
to make my first emails contain some contribution.
Unfortunately I've hit a snag, and have to gather the projects view before 
proceeding.

Initially I thought to learn Machinekit (MK) by creating a binding to a 
script language - Ruby, if it matters.
I wanted most of my time spent exposing MK's functionality, so decided to 
try to SWIG (3.0) generate the interface/wrapper files.  The hope being 
that others could come along a use the SWIG generated bindings as the 
platform for their domain specific semantics, maybe even a DSL.

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

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.

where machinekit.i is: 
/*Using SWIG 3.0.12
Install instructions here:
http://weegreenblobbie.com/?p=263

COMMAND:
swig -cpperraswarn -E -xml machinekit.i
*/

%module machinekit
/* Structure is based on (14 April 2017)
 http://machinekoder.com/machinetalk-explained-part-1-introduction/
 */
/*%include "machinetalk.i"*/
%include "hal.i"
/*%include "taskexecutor.i"*/
/*%include "motioncontroller.i"*/
/*%include "trajectoryplanner.i"*/
/*%include "iocontroller.i"*/
/*%include "gcode.i"*/

and hal.i is:

%module hal
 %{
 /* Includes the header in the wrapper code */
 #include "../../src/rtapi/rtapi.h"
 #include "../../src/hal/lib/hal.h"
 %}

 /* Parse the header file to generate wrappers */
 %include "../../src/rtapi/rtapi.h"
 %include "../../src/hal/lib/hal.h"  //HAL needs RTAPI/ULAPI


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