> On 19 Sep 2019, at 17:50, <[email protected]> <[email protected]> wrote:
>
> Sep 18, 2019, 20:19 by [email protected]:
>
>> @cern
>>
>> Curious, what is the state of machinetalk?
>>
>> I am at some point planning on running a remote GUI, pretty much as you
>> described with a de10 nano as the RT pc/FPGA and some ARM or small X86
>> running the interface. I didn’t get too far in depth of what I need to do
>> with remotely controlling it, too busy with hardware but I thought the
>> remote concept of machinekit was solid.
>>
> This is only my view at the situation and as such there is going to be a
> difference of opinions. Mainly what Machinetalk is and what it should do.
>
> The Machinetalk and HALtalk is a joint baby of Michael Haberler and Alexander
> Rössler (for whom I think it was a diploma work). By post-mortem
> investigation, there were a quite big plans for what Machinetalk should be
> able to do. It was intended as a replacement of the NML and also shift from
> current position, when NML sits on top of (for example) motion component,
> nearer the HALayer core. That way it would enable node structure of machine
> system setup. (As a example, imagine two RTAPI instances (msgd and rtapi_app
> daemons) running infinite real-time loop tasks like now, but getting the
> instruction from one separate planner, which it itself is controlled from
> numerous terminals [GUIs].) Instances of Machinekit should be also able to
> communicate with each other, not only with current clien-server. As there was
> intention for direct control of rtapi_app created HAL.
>
> But then Michael Haberler performed his exit stage left without finishing his
> work (he even wanted to write documentation) and Alexander Rössler was always
> (and by his online activity still is) interested more in GUI and HMI work and
> replacing AXIS with something remote/running on Android/written in modern
> language.
>
> So, the current situation is that the Machinetalk (and affiliated
> technologies) is deeply ingrained into Machinekit, but not deeply enough as
> too much LinuxCNC ways is still visible. And then it's development stalled.
> And that is the root of my frustration.
>
> So, to @Bas, if you want to use only the UI components, you are fine as it
> works. (But is still only a clutch, as the messages are translated to NML to
> communicate with Machinekit-CNC side.)
I’m afraid you misunderstand. I do not use the CNC stuff. Just the HAL layer.
Pins, No NML.
The entire “let’s replace nml” has halted because 1: this is hard work and 2:
it is a lot of work and 3: there’s nobody who wants to do that.
> However, look for example at the NOTYET portion of code in rtapi_app and then
> how HALCMD communicates with rtapi_app. It uses the Machinetalk. But then
> not. It uses the ZeroMQ layer and Protobuf serialization. And then it
> registers itself as a HAL module, which I consider a braindead move (OK, I
> get it why it does that, but it's bad architectural design and means that the
> process needs to run on the same system as a rtapi_app). Saner approach would
> be to enforce the rtapi_app only place where access to the HAL shared memory
> space happen. CMDLINE would message rtapi_app socket with command, rtapi_app
> would execute it and send back a status. That way you can milk the great
> feature of ZeroMQ and use HALCMD from everywhere, even Windows Machines.
> (Typical machine programmer monkey cannot use Linux.)
>
> I think the best approach would be to implement what I described here:
> https://github.com/machinekit/machinekit-hal/issues/230
> <https://github.com/machinekit/machinekit-hal/issues/230> with Linux based
> permissions on file access, onto this connect new process which would do the
> Machitalk access (machinetalk_app), which would do all what is done now plus
> manage permissions (which current implementation of Machinetalk does not even
> take into account) based on certificates, protocols and interfaces (you can
> have an interface you consider implicitly safe which is direct connection to
> other parts of the machine and then another which is LAN) onto which would be
> connected the HALCMD and other similar applications or remote/nonRT connected
> rtapi_app (Machinekit-HAL) instances. But, as I said, it is only my opinion.
>
> Also, part of Machinekit is the router message pipe (currently not used, I
> think) which is intended for direct messaging between two HAL modules.
> Imagine module which has a ring buffer. This ring buffer is filled from one
> side by (for example) RT HAL module, then on other end emptied by this
> router, send over ZeroMQ to other machine and there the dealer puts this
> message back into receiving ring buffer of some local HAL module. Problem
> with this is that the HAL module works with structures, but the router has to
> serialize this to Protobuf format and remote router has to deserialize it.
> For this, something with same-on-wire-same-in-memory format would be better.
> Like Flat buffers (pending consideration on memory alignment).
>
> Machinetalk is also big on multipart messaging concept. Which is considered
> by parental ZeroMQ community as an obsolete (or starting to be obsolete) and
> is no longer supported with new messaging patterns and sockets - like the
> UDP, which for direct communication between two Machinekit/Machinetalk
> instances would be the best.
>
> (BTW, Machinetalk with DNS-SD will have a big problem with non-Ethernet
> network, for example were you implement the ZeroMQ pattern over RS-232
> serial, for which there already was interest.)
>
> It would be also great to use the current HAL-REMOTE component pattern for
> PIN creation before the actual HAL component is instantiated. I see the use
> for going away with the postgui.hal hack and streamlining the HAL
> configuration setup and tear down for non-realtime capable components.
>
> Sorry for the rant, but that is what I see is problematic with Machinetalk. I
> want independent islands of functionality which don't care about where they
> run and are able to dynamically change each other.
>
> But it needs people interested in it. And so far, nobody (with big enough
> means) really is.
>
> Cern.
>
>
>
> --
> 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].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/machinekit/Lp9CwT---3-1%40tuta.io.
--
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].
To view this discussion on the web visit
https://groups.google.com/d/msgid/machinekit/CD19E8B0-DD42-4756-8114-F5A62D63CA7B%40basdebruijn.com.
