The reason why I ask is that I have been looking up and studying the Machinekit source code for some time now but even looking at the code several times was in many cases not enough to fully facilitate my understanding of the actual inner workings and how the author intended it. So as to minimize projecting my ideas which have no holdings in reality, I needed to get some things straight before I go and shoot myself in the leg. (How long did it take for you to gen understanding of this OS base code?)
Dne neděle 31. března 2019 14:50:03 UTC+2 Bas de Bruijn napsal(a): > > > > 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. > I probably used not completely clear terminology. By "splitting" I meant the split from Machinekit repo to Machinekit-HAL repo and Machinekit-CNC repo. And by "repo" I don't neccesarily mean GitHub repository, but more like "project". The change from LinuxCNC to Machinekit and The Big Bang thereof I consider as a "fork". Sorry for the misunderstanding. > > >> >> 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. > Yes, I understand that. However the CNC stack contains many components or parts of components which would be usable outside typical CNC VMC or lathe machine. (Depends on what you consider CNC machine, for example autotracking cannon could be one, but Wikipedia doesn't consider it so.) > > >> >> 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 > Ringbuffers are clearly quite interesting feature (and for me at least holding some mystique) and something missing from the original LinuxCNC architecture, but so far I have seen it as only HAL construct. Maybe I am again projecting my own ideas but at first I have seen them as a kind of multilayer queued object I/O pins, but then there is no remote support for ringbuffers, ring? Is that because nobody coded it or because it is against some fundamental principle behind ringbuffer idea? > > > >> >> 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. > Yes, thank you. -- 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.
