Sep 20, 2019, 16:16 by [email protected]: > > >> 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. > Ah yes, I did. HALtalk works. But then I always thought that HALtalk is only a subset of Machinetalk.
BTW, given that you use it in - probably - professional manner, do you think that the HAL_REMOTE_COMPONENT idea would be usable for creating orphaned pins inside HAL for real-time components if my realtime character device communication idea was possible? > > 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. > I can relate to that. It's just that it seems that replacing the NML was the main motivation behind Machinetalk. Given the fact, that NML is layered upon the CNC side, it is not that interesting to me at the moment. Cern. >> 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. > -- 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/LpKgYQ2--3-1%40tuta.io.
