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