May 27, 2019, 9:15 PM by [email protected]: > Thanks for the pointer, I had not looked at those fields in Container > yet - I can see that there were grand plans indeed, what I don't see > is where they were supposed to go. > Have you looked at the videos at https://www.youtube.com/channel/UC3FVtrJ8U91iODq5motHMow <https://www.youtube.com/channel/UC3FVtrJ8U91iODq5motHMow> and read the wiki at https://github.com/mhaberler/asciidoc-sandbox/wiki <https://github.com/mhaberler/asciidoc-sandbox/wiki> ? There are some basic pointers. Otherwise, only the code and your imagination.
> > And I mean that in many ways. It's not clear where each one of > these services was supposed to be implemented, how they were supposed > to be integrated with the rest (.ini file or some new mechanism) and > finally - I'm not entirely sure what problems some of them were > supposed to solve. > > For instance status.config - if that had a fixed > (configurable in some way) port the service_announcement you > pointed to would make sense and be quite useful. > > Can you elaborate what you meant by different transports? What is it > you are looking for? > Well, ignore the overly dramatic parts of my monologue. When one says Machinekit (in extension from LinuxCNC), then even though many people will imagine Axis user interface and CNC mill connected by MESA card or parallel port, it is not by default one running program but set of arbitrary number more or less closely connected programs. Some of these program from definition and by logic need to run on the same system. Like the rtapi_msgd and rtapi_app which are connected by shared memory segment. Rtapi_app is then connected to some form of RT capable system. It can be the RT-Preempt patched linux kernel (pretty much standard libc), or the Xenomai Native API or whatever. Then there are programs which do not necessarily need to run on the same system, these program don't even need to run on Linux but could pretty well run on Windows too. Basically they can run anywhere from machine point of view. Cue for example the HALCMD command line tool or the AXIS GUI or even the trajectory planner and G-code interpreter. So how I understand the Machinetalk idea it is global communication layer (application communication bus) for communication between Machinekit parts and more for communication with arbitrary outside programs (like work scheduling server). It should not care where the common parts of Machinekit are running (of course, parts which logically need to run on one system like the rtapi_msgd and rtapi_app are exception) if it is one i7 x86_64 computer or 10 small ARM based SBCs. Also, currently you can have one or more rtapi_apps running on one system. These (lets call them) Machinekit instances can be pretty much independent. So you should be able to operate system which can be arbitrarily deployed on one or multiple platforms/machines (call them PC for short) and these platforms/machines/PCs can be part of multiple systems (Like node controlling environment can be part of 3D printer and CNC mill at the same time). One example is the ATC to CNC mill. The ATC can (and maybe should) have it's own controller - Machinekit running it. This Machinekit controlling ATC will then communicate with Machinekit running the XYZSpindle milling motion. So you need communication inside one machine and outside the machine over local network or arbitrary form. (We are still talking about non-deterministic communication, no synchronized motion or RT threads.) One service may need to communicate with remote actor and local actor at the same moment. The remote actors can be multiple and reachable by different network/interfaces. Also, not every network connection can be considered safe. So far Machinekit implements Machinetalk which is either REMOTE or LOCAL. Remote means communication by TCP, local by IPC. But it's not that simple. You may want to communicate with local actors over IPC (with full rights, because who can get to the machine can do anything) and you may want to communicate with some remote actors by TCP with implemented CURVE and limited permissions on the same time on the same service. And then you want to communicate with another rtapi_app instance in the status/command mode. Locally you can use the IPC protocol, but remotely it is better to use the (multicasted) UDP over RADIO/DISH socket. (Little I described here: https://github.com/machinekit/machinekit-hal/issues/125 <https://github.com/machinekit/machinekit-hal/issues/125> ). Again same service can communicate on one time over UDP and IPC. Hope it shone at least a little light onto what I mean. Cern. > > Have fun, > Markus > > On Mon, 27 May 2019 17:35:00 +0200 (CEST) > <[email protected]> wrote: > >> 27. 5. 2019 3:20 od [email protected]: >> >> > In my quest to figure out how machinetalk works I came across the >> > following in mkwrapper.py: >> > >> > def main(): >> > parser = argparse.ArgumentParser( >> > description='Mkwrapper is wrapper around the linuxcnc >> > python module' 'as temporary workaround for Machinetalk based user >> > interfaces' ) >> > So if mkwrapper.py is/was considered a temporary workaround, how >> > does/should the real thing look like? >> > >> >> Problem with Machinetalk, one which needs to be remembered at all >> times, is that it is in an unfinished state from a development point >> of view and probably the specification was never finished also. Hard >> to say as Michael Haberler, who cooked it up at the beginning, left >> the project and I don't know if Alexander Roessler is active in >> Machinetalk development anymore. >> >> So short term band-aids become long term solutions. Not good but >> probably good enough for now. >> >> As you can see the Machinetalk suffers a little bit by grandiose >> dreams which never materialized. Like the preparation work in >> Container >> message, >> https://github.com/machinekit/machinetalk-protobuf/blob/master/src/machinetalk/protobuf/message.proto#L128 >> <https://github.com/machinekit/machinetalk-protobuf/blob/master/src/machinetalk/protobuf/message.proto#L128> >> , >> for ZeroMQ thought up service discovery instead of DNS-SD/mDNS. Also, >> it didn't cover the problem of multiple transport protocols >> (IPC/TCP/UDP), which I think is sorely needed. And the NOTYET defines >> are still open work in the source code. From today point of view, I >> think it needs some rework. And I am open to discussion on how to do >> this. (I am of the opinion that the definition should be accessible >> before the code.) >> >> Cern. >> > >> > >> > >> > -- >> > website: > http://www.machinekit.io <http://www.machinekit.io>> >> > blog: > http://blog.machinekit.io <http://blog.machinekit.io>> >> > github: > https://github.com/machinekit >> > <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] >> > <mailto:[email protected]>> . Visit this >> > group at > https://groups.google.com/group/machinekit >> > <https://groups.google.com/group/machinekit>> . To view this >> > discussion on the web visit > >> > https://groups.google.com/d/msgid/machinekit/6b0977ef-1595-4919-ae1b-faf3b8428670%40googlegroups.com >> > <https://groups.google.com/d/msgid/machinekit/6b0977ef-1595-4919-ae1b-faf3b8428670%40googlegroups.com?utm_medium=email&utm_source=footer>> >> > . >> > For more options, visit > https://groups.google.com/d/optout >> > <https://groups.google.com/d/optout>> . >> > >> -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/Lg-33iL--3-1%40tuta.io. For more options, visit https://groups.google.com/d/optout.
