These are chat archives for machinekit/machinekit

29th
May 2016
zhivko
@zhivko
May 29 2016 14:59

OK following @mhaberler suggestion regarding modification of message proto, now I get:

typedef struct _pb_Container {
    pb_ContainerType type;
    pb_callback_t pin;

But I am not sure how can I set array of pins with this pb_callback_t... any idea - sample for this ?

zhivko
@zhivko
May 29 2016 15:07

I need to do similar as

    // add repeated submessage(s)
    pin = container.add_pin();

but this time with nanopb, pb_callback_t mechanism

Alexander Rössler
@machinekoder
May 29 2016 16:24
@koppi Interesting indeed.
Michael Haberler
@mhaberler
May 29 2016 17:35
@zhivko you want to use nanopb, you need to read up on the (excellent) nanopb documentation - it has a very good explanation and examples how to do this
Michael Haberler
@mhaberler
May 29 2016 18:52
there is no separate "machinekit nanopb" documentation - it is a straight import, so the nanopb docs and examples apply
the whole idea behind machinetalk is to replace a dead-end stack (NML/RCS) by known, used, well-maintained, stable projects and methods - which result in using google protobuf (c++), nanopb (C/RT), czmq/zeromq as messaging stack, mDNS for discovery, libwebsockets,JSON for web interfacing; there is no point in reinventing the wheels - because you can get a lot of leverage by outsourcing the support to other projects especially if your project has a small user and developer base
zhivko
@zhivko
May 29 2016 18:56
OK I tried to move back to google protobuf - but trying to compile it on SmingRTOS, thisis what I get:
C+ app/application.cpp
In file included from include/google/protobuf/stubs/atomicops.h:59:0,
                 from include/google/protobuf/stubs/once.h:81,
                 from include/google/protobuf/generated_message_util.h:44,
                 from /home/kz/git/SmingRTOS/samples/StepperDM542/include/machinetalk/generated/message.pb.h:22,
                 from app/application.cpp:3:
include/google/protobuf/stubs/platform_macros.h:84:6: error: "__LP64__" is not defined [-Werror=undef]
 # if __LP64__
I am not sure if I can just remove -Werror=undef compiler setting...
maybe better if I can somehow workaround this.
Michael Haberler
@mhaberler
May 29 2016 18:58
well to be realistic your best chance of support is the google protobuf mailing list
that said: look at the header
the error occors here:
sorry, cant tell - too short
which line number?
in platform_macros.h
zhivko
@zhivko
May 29 2016 19:00
84
include/google/protobuf/stubs/platformmacros.h:84:6: error: "_LP64" is not defined [-Werror=undef]

if LP64

I should add: #if !defined(
Michael Haberler
@mhaberler
May 29 2016 19:02
but evidently this has to do with the platform definition - protobuf requires atomic ops - no idea how that should map to "Sming"
btw there is another option which might be easier
that is the protobuf-c binding (note C, not C++)
zhivko
@zhivko
May 29 2016 19:03
Have you been able to checkout my branch - or it is too much effort for you ?
I mean you see it as too of topic ?
Michael Haberler
@mhaberler
May 29 2016 19:03
I am sorry, which branch?
of what?
zhivko
@zhivko
May 29 2016 19:03
namespace_aware
my SmingRtos try to use google proto and machinetalk
Michael Haberler
@mhaberler
May 29 2016 19:04
you pasted some example links, and I did look at them , but did not checkout or try any of this
it will be nice to have microcontroller example of using machinetalk
Michael Haberler
@mhaberler
May 29 2016 19:04
look be realistic: what should I do with this? I do not have the platform
zhivko
@zhivko
May 29 2016 19:05
ok understand
Michael Haberler
@mhaberler
May 29 2016 19:05
well yes - I can suggest an approach, but I cannot build some platform X for you
zhivko
@zhivko
May 29 2016 19:05
ok... but on using google protobuf for any uC platform (also arduino)
How should this work then:

if LP64

in platform_macro ??
Michael Haberler
@mhaberler
May 29 2016 19:06
(and frankly I am extremely busy with administrative crap very few people want to take on, like website, packaging and other mundane stuff)
everybody wants to push his own grandiose thing, when it comes down to housekeeping - nobody home
zhivko
@zhivko
May 29 2016 19:07
yes I see you and arceye are in web documentation publishing alot this weeks
Michael Haberler
@mhaberler
May 29 2016 19:07
not being personal - just saying how it is
well it is definitely not my big love or hobby
zhivko
@zhivko
May 29 2016 19:07
i will apreciate advise how to integrate this google protobuff to any uC platform.
applies to arduino also.
Michael Haberler
@mhaberler
May 29 2016 19:08
that is why I referred you to protobuf-c
Michael Haberler
@mhaberler
May 29 2016 19:09
you might want to explore this: https://github.com/protobuf-c/protobuf-c
I did use protobuf-c before and it works - it is not as easy to use as gpb C++ but reasonable
and much higher level than nanopb
zhivko
@zhivko
May 29 2016 19:10
this means rebuilding machinetalk proto with protobuf-c ?
so they will not reference google package anymore?
Michael Haberler
@mhaberler
May 29 2016 19:10
no
I am on their list, it is low-traffic but used, so certainly not dead
it uses the protoc tool, but you do not need protoc on the target platform
I had haltalk v1 using protobuf-c before I switched to c++
zhivko
@zhivko
May 29 2016 19:14
but how then it should work?
So I would need to use protobuf-c to compile proto to stubs that are not referencing google sources - I do not see how else I could do that...
Michael Haberler
@mhaberler
May 29 2016 19:14
it was obvious there is no advantage in using protobuf-c on a linux platform over gpb/c++ which is very polished, heavily used and very well documented
but on some random embedded platform it might be easier to get going
zhivko
@zhivko
May 29 2016 19:15
But this could be to complex for me... maybe better to write websocket server on BBB, and then write custome websocket client on SmingRTOS platform...
Probably this would be fastest route.
Michael Haberler
@mhaberler
May 29 2016 19:16
what is too complex, compile a library?
zhivko
@zhivko
May 29 2016 19:16
use protobuf-c to proces proto files to get stubs (in protobuf-c dialect that do not reference google sources)...
Michael Haberler
@mhaberler
May 29 2016 19:17
protobuf is still a second-order problem
the key problem is whether to talk to haltalk or the webtalk proxy
if the latter, you do not necessarily need protobuf but it helps creating the JSON objects
so assuming you get protobuf-c/gpb-c++/nanopb going: which transport are you going to use? zmtp does not support xpub/xsub sockers so directly talking to haltalk would require implementing that zmtp
zhivko
@zhivko
May 29 2016 19:19
I need to clarify - for now I used JAVA client that used zeromq and java stubs for machinetalk, to talk to mkwrapper.py.
Now - I would like to write custom python websocket server - that will use similar aproach like mkwrapper.py (and run in parallel with mkwrapper.py on BBB) , but on the out it will be wesocket server...
I hope it make sense
Michael Haberler
@mhaberler
May 29 2016 19:21
so you are basically duplicating what webtalk already does
why
zhivko
@zhivko
May 29 2016 19:22
is mkwrapper.py part of webtalk ?
Michael Haberler
@mhaberler
May 29 2016 19:22
no
it is a zeromq/protobuf adapter to the linuxcnc python module
the linuxcnc python module talks to the cnc stack, not HAL
so conceptually a layer above and no HAL access in mkwrapper
zhivko
@zhivko
May 29 2016 19:23
Oh .... hmmm ... bad...
Have you thought extending this to include hal interraction ?
or it is impossible ?
or any other limitation ?
Michael Haberler
@mhaberler
May 29 2016 19:24
haltalk does exactly that?
zhivko
@zhivko
May 29 2016 19:25
havent had chance to chack this layer... sorry
Michael Haberler
@mhaberler
May 29 2016 19:25
there is zero reason to move HAL functionality to mkwrapper
zhivko
@zhivko
May 29 2016 19:25
so maybe I am asking stupid questions...
Michael Haberler
@mhaberler
May 29 2016 19:25
you are missing out on the key server you want to talk to
also have a look at Alex's python client haltalk bindings
they might help in getting the idea across
I think it is in his repo, ask him
zhivko
@zhivko
May 29 2016 19:26
can you give hint why haltalk functionality should not be part of/in mkwrapper ?
Michael Haberler
@mhaberler
May 29 2016 19:27
because not every HAL application is a CNC stack application?
it has no place at that layer
do you understand what the Python linuxcnc module does, and what the CNC stack is about? like gcode etc?
HAL is about pins, signals, comps - that is like IP versus HTTP
they are conceptually different layers which is why there are different interfaces
if you want to open a http connection you dont start with fiddling an ethernet interface and vice versa - it is a different functional and protocol layer
zhivko
@zhivko
May 29 2016 19:31
yes functionality is different I understand this - I am abstracting things too much... taking a linuxcnc as black box.... so thinking why dont we have single interface to it - but obviously having more interfaces is the case.
Michael Haberler
@mhaberler
May 29 2016 19:31
what you are up to is definitely positively 100% interfacing to HAL
zhivko
@zhivko
May 29 2016 19:32
I mean machinekit
Michael Haberler
@mhaberler
May 29 2016 19:32
well below your web browser is also a whole range of layers and different API's, for the very same reasons
zhivko
@zhivko
May 29 2016 19:33
yes it is kind of protection layer (making it private)... I understand
Michael Haberler
@mhaberler
May 29 2016 19:33
well different concerns
zhivko
@zhivko
May 29 2016 19:33
So need to study haltalk
Michael Haberler
@mhaberler
May 29 2016 19:33
HAL is about pins, signals, comps
zhivko
@zhivko
May 29 2016 19:34
yes... So @strahlex has repo for haltalk?
Michael Haberler
@mhaberler
May 29 2016 19:34
the CNC stack is about g-code, mdi, machine modes, states, and when it was written there was no HAL, but actually compiled C hardware interfacing
Alex has written python client bindings to talk to haltalk
so they might be a model for what you are doing and trying things out with them will help you to replicate this in C
zhivko
@zhivko
May 29 2016 19:35
maybe you know the github link ?
Michael Haberler
@mhaberler
May 29 2016 19:36
on the condition you talk to Alex directly: I think this is it: https://github.com/strahlex/pymachinetalk
I suggest you try these and get the hang of it, how it all works together
zhivko
@zhivko
May 29 2016 19:38
OK thank you... will try this
Michael Haberler
@mhaberler
May 29 2016 19:38
the core problem is still the lack of xpub/xsub sockets in zmtp, but that might not be that hard to implement
as a general remark: I know embedded and bare-metal programming is considered easy and cheap
I think that is a nonsense argument because it overlooks the huge leverage of linux and the package streams available there
meaning: you drop the idea of a some funny bare-metal os, go for a cheap embedded linux platform and bang, you are there because the whole stack is an apt-get install away
zhivko
@zhivko
May 29 2016 19:42
yes but that 160MHz esp8266 platform is SO silly cheap... I do not know of linux alternative so cheap
Michael Haberler
@mhaberler
May 29 2016 19:42
your and my conceptions of "cheap" differ fundamentally
because I add in the effort to get the software going, the hardware cost is peanuts in comparison
zhivko
@zhivko
May 29 2016 19:43
if there is a way to have json protobuf message and haltalk server on BBB, than probably bare metal can do that...
Michael Haberler
@mhaberler
May 29 2016 19:43
I mean there are embedded linux platforms in the 10-20€ range. Why on earth would you possibly suffer an operating-free 8-bit processor if you can have that option?
that is likely very simple to do
what you mean, server
and accepts haltalk workload from clients
Michael Haberler
@mhaberler
May 29 2016 19:45
yes
but there is no reason why your "client" cannot be a simple embedded linux system with the machinetalk stack talking to it
zhivko
@zhivko
May 29 2016 19:47
I do not know of this lowcost linux alternative - but maybe it is my history - I made some nice project with the platform I have mentioned - and then you stick to this
Michael Haberler
@mhaberler
May 29 2016 19:48
it depends what you are up to
if you want to prove it works on sub-embedded linux, your options are json/websockets talking to webtalk, or zeromq/protobuf messaging, however that is implemented on the client device
it would be nice to have to be able to show, but if that is a good business decision is an entirely different matter
yeah habits
been there:)
zhivko
@zhivko
May 29 2016 19:49
does webtalk contains / supports hal layer functionality ?
Michael Haberler
@mhaberler
May 29 2016 19:50
webtalk is a proxy to/from haltalk, the latter does
zhivko
@zhivko
May 29 2016 19:51
OK, so I assume webtalk doesn't support other gcode, machinestatus functionalities ? JUst to confirm I got it right...
Michael Haberler
@mhaberler
May 29 2016 19:52
webtalk does not look at message contens, all it does is translate zeromq message framing and sockets, plust protobuf into a websockets connection where protobufs show up as json objects
so it doesnt support anything than translation
the functionality comes from haltalk "behind" it
like this $5 fellow - ok it lacks ethernet, but it's a linux device: http://lifehacker.com/the-raspberry-pi-zero-is-a-5-computer-the-size-of-a-st-1744253282
there is some 10$ Allwinner board which is 50% of a bb
ethernet, linux and all
zhivko
@zhivko
May 29 2016 19:55
5$ pi is interesting - how is that is miss ethernet?? How on earth you do the update of sw stack then ?
Is there some ethernet adapter available?
It could be interesting to try this ...
It would be nice if it could be also powered from this ethernet cable - but I think this is not the case ?
Michael Haberler
@mhaberler
May 29 2016 19:59
q: what is the business reasoning - how many copies are being deployed? or is this a hobby effort?
zhivko
@zhivko
May 29 2016 19:59
hobby effort
Michael Haberler
@mhaberler
May 29 2016 19:59
zhivko
@zhivko
May 29 2016 20:00
green is much more expensive than pi zero
Michael Haberler
@mhaberler
May 29 2016 20:00
how much do you ask for a zhivko hour?
zhivko
@zhivko
May 29 2016 20:01
10€
Michael Haberler
@mhaberler
May 29 2016 20:01
I mean mine goes at multiple greens if I chase a good customer
not boasting, just suggesting to rethink the economics
zhivko
@zhivko
May 29 2016 20:02
you are different caliber... since it is hobby I would like to keep cost low
Michael Haberler
@mhaberler
May 29 2016 20:03
ok, I send you a few greens and you commit a decent haltalk C client, we both win.
that'd be worth much more for the ecosystem altogether
I am trying to make a point
zhivko
@zhivko
May 29 2016 20:03
I think pi zero cost is too low, they cannot continue producing it at that price
I cannot promise anythink - actually I could you my BBB white I still have. The one that doesn't run machinekit...
But I thought I could get away with bare metal...
Don't you want to have arduino style webtalk client also...
Michael Haberler
@mhaberler
May 29 2016 20:06
first, not my problem, second - I tend to think in terms of system cost: hw plus effort rationalized over number of installs
zhivko
@zhivko
May 29 2016 20:06
Why you push this TI so much ?
Michael Haberler
@mhaberler
May 29 2016 20:07
me pushing what?
I am sorry?
zhivko
@zhivko
May 29 2016 20:07
sorry got a feeling that you maybe wanna have all on TexasInstrumments stack -- didn't want to offend or anything...
Michael Haberler
@mhaberler
May 29 2016 20:07
that is some serious bullshit
go follow the tracker and look where I put my time into and your sentence will come out complete nonsense
zhivko
@zhivko
May 29 2016 20:08
no offense here..
Michael Haberler
@mhaberler
May 29 2016 20:08
your impression derived from cursory reading != some other peoples inclination
zhivko
@zhivko
May 29 2016 20:09
I mean - I wanted just to emphasize that having platform that allows different platforms to intercommunicate - thats good thing - and best aspect of SW stack...
Michael Haberler
@mhaberler
May 29 2016 20:09
and if you follow the list, then you would have notice that the first idiot which comes around and says this is a BB project get a lengthy explanation from me about portable stacks
zhivko
@zhivko
May 29 2016 20:10
no no... havent read any other peoples inclination - please dont understand me wrong .
Michael Haberler
@mhaberler
May 29 2016 20:11
I am off for today, cu
zhivko
@zhivko
May 29 2016 20:11
since you are busy person I don't wanna steal your precious time...
OK...later