Looking at Machinetalk capability sometimes seems like two steps ahead, three steps to the right and one step back per every move. But that's because it is in unfinished state and you have to think and guess about what the original author intended in the future for it to be. The main thing missing is clearly stated definition (software agreement) of how it all should work together.
I have an interest in machine kit since a lot of work has been done on > remote gui ability but not a fan of protobuf. Thus for me I will replace > protobuf with flatbuffers and at some point in the future and also start > thinking about perhaps replacing NML with flatbuffers. > Info on flatbuffers is at: https://google.github.io/flatbuffers/ > Machinetalk as whole solution was not intended (or at least I think so) for remote GUI only application. I am - for example - interested in distributed machine setup three or more ZYNQ boards or BBBs connected over application bus (Machinetalk) in one machine, each serving it's own domain specific tasks. So marshaling information onto wire is not done somewhere in one central interface on the outskirts of Machinekit installation. There are even two version of compiled IDL .proto outputs - one by normal protoc, second by the minimal C only nanopb <https://jpa.kapsi.fi/nanopb/>. I don't know flatbuffers at all, but some time ago I have read somewhere that it quite extensively use dynamic memory allocation, which is quite no-no for embedded C-only crowd. So I am not sure the change of protocol buffers to flatbuffers would be straightforward. I am not saying that I am big fan of protobuf (more to the point of I have no strong opinion) but I am not sure the switch would be worth it. (I know there is flatcc <https://github.com/dvidelabs/flatcc>for nanopb, but the work starts to add up.) I too am interested in using ZMQ to pass status and commands from guis to > linuxcnc. > So only non-queued communication? ya replacing NML to something modern and documented would be great. Still > beyond my skill. > So far what I was able to understand, Machinetalk is not intended as a direct replacement of NML layer. It's more shifted to the HAL layer. It's geared towards connecting over HAL islands too. (With the talk about synchronization of arbitrary HAL threads across separate Machinekit Instances and so on.) Unfortunately with out explained-example-code / simple user type docs I > would need to be a ZMQ/protobuffer/mk expert to use it. > I am sorry, but without becoming expert yourself your changes of finding one are pretty slim. I really wish we could get linuxcnc and MK working together so we didn't > need to duplicate effort... > There used to be animosity, so I would not hold my hopes up. The LinuxCNC project also was not really interested in idea of distributed machine control as I envision. But why not? Cern. Dne pondělí 15. dubna 2019 6:56:53 UTC+2 Chris Morley napsal(a): > > I am interested in ZMQ in linuxcnc and thought i might look at machinekits > implication. > I don't see any docs. > > Thanks. > Chris M > -- 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 [email protected]. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
