On Sunday, March 31, 2019 at 1:45:55 AM UTC+1, cern wrote: > > Been looking into the distinction of Machinekit-HAL and Machinekit-CNC > repositories and so far what I can tell the Machinekit-HAL is perfectly > happy to run on its own but the Machinekit-CNC needs as a prerequisite the > Machinekit-HAL. I also see that the majority of work done in Machinekit as > a fork of LinuxCNC was about the HAL layer, so it's possible to say that > Machinekit is more Machinekit-HAL than Machinekit-CNC. What I would like to > know is what's the end game of splitting? >
Machinekit-HAL is indeed the HAL part of the original LinuxCNC. The realtime Hardware Abstraction Layer. Machinekit-CNC is the CNC application on top of Machinekit-HAL. Combined they are the original fork of LinuxCNC: Machinekit. The reason that Machinekit forked from LinuxCNC and most work has been put into the HAL layer has a few reasons. tOne of the original reasons of the fork from LinuxCNC was that the developers that split of were not satisfied with the development of LinuxCNC. They envisioned that you should be able to run the realtime environment on multiple kernels instead of being tied to RTAI. Further more there were a lot of new boards/platforms, so energy went into running not only on a PC, but a BeagleBone board, and other ARM devices. Raspberry Pi, De0-NANO, to name a few. Add to that the ability to run threads on multiple cores in a realtime safe way. Apart from that hardware part, The CNC application is a very big codebase, having evolved over the years, and improving that needs people that are able to understand the application. Technology has moved from a single desktop PC with a Parallel port to newer smaller devices. > > If it is intended for Machinekit-CNC to forever require the Machinekit-HAL > or if there is push for these two projects to be independent - i.e. if it's > to be possible to install only Machinekit-CNC and talk to Machinekit-HAL on > a different machine (or even the same machine) over the application bus? > (As opposed by the RT-capable field bus, what I call application bus is the > higher level messaging protocols and connected services like Machinetalk, > HALtalk, and whatnot.) Application bus which does not care if it's > interprocess or off-system. > Yes, you can't install machinekit-CNC without machinekit-HAL on the same machine. That was one of the reasons that a lot of work went into remote components and machinetalk/haltalk and ringbuffers. One of the things that can be done is to use machinekit-hal as the realtime motion stack, and have planning done by for example ROS (non rt planning). You don't need the full CNC stack in a lot of cases. > > I guess that the motion (and other) component would then need to be split > into several parts (but then it is unyielding blob anyway), one RT HAL side > and other not-RT. Would the current ring buffer FIFO be enough to > facilitate the distinction? (Given one example is given as the > streamer-hal_streamer component, it should.) > The problem is indeed a clear distinction between what is needed in realtime, and what is not. Hence the ringbuffer. That's a realtime safe scheme for getting info in and out of the realtime part. The interpolator component uses such a scheme, as well as the jplanner component (both non-RT to RT). For a component like delayline, it uses a ringbuffer to delay samples for an amount of cycles (RT -> RT). The thing is, you can attach to the same ringbuffer from multiple components, RT or non-RT. This is an example of putting pin values in a ring (RT) and reading these from a python script (non-RT). https://github.com/machinekit/machinekit-hal/tree/master/src/hal/sample_channel > > The question is not if somebody is going to develop it but what the > authors of the split would like IT to be. (Something like these ZeroMQ RFCs > which are so popular here.) > Personally, I value the HAL part the most. But it all depends on what people are interested in. > (For example, it could be possible to then develop and configure the > system so the MACH3/4 would be the Machinekit-CNC and Machinekit-HAL would > function as the SmoothStepper or CSMIO/IP-A real-time controller. Not that > I am interested in it, just an example of how my thoughts go.) > Building LinuxCNC on top of machinekit-HAL would make more sense to me. Hope this answers some of your questions. -- 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.
