Dne neděle 31. března 2019 17:35:55 UTC+2 John Morris napsal(a): > > You're right, Machinekit has been more about HAL than the EMC application > on top of it, although @machinekoder's `mkwrapper` and QtQuickVCP are major > innovations in Machinekit that straddle that boundary.
It's exceptional work because it helped with Machinekit's visibility in general hobby CNC community. And it's too bad nobody picked up the framework to create open-source graphically pleasing remote user interface. However, from my view, the mkwrapper looks like a temporary bandair until the NML layer is stripped off and everything runs on Machinetalk (I am not sure if Machinetalk is one all-reaching and all-encompassing name for the whole communication layer or just for some part of it.) Too bad that to attract community and gain momentum, people want exactly and only the CNC stack. Nice UI will always win against multicore HAL. > For me the split is not a major architectural change, but rather to split > out HAL to showcase it as an independent entity on which other applications > can be built atop. EMC is one such application, and I've worked on other > applications, such as a ROS integration and an autoclave control. > > The split conveys other advantages, as well. For non-CNC applications, > the separate mk-hal code base is lightweight: faster to build, smaller, > fewer dependencies. I'm also hoping the split provides an opportunity to > pull back in the many improvements made over the years on the EMC side in > the LinuxCNC project, since Machinekit hasn't kept up with those changes. > For me, the split kind of is a major architectual change on part of multicore HAL support. Or at least before I opened this thread I have seen it this way. I consider the application layer or better yet the distributed networked topology the Machinekit's main asset. The Machinetalk in comparison with NML shifted the focus towards the HAL part (the remote components, talk about synchronized threads/clock synchronization and so on). So now there could be HAL->motion->NML but HAL->motion-part->Machinetalk->motion-part->Machinetalk. Fact that you can have one multicore Machinekit-HAL SBC next to other multicore Machinekit-HAL SBC, both doing it's own thing, both controlled by some kind of "server". It was possible in LinuxCNC with real hardware signaling pins, but extracting it to abstract communication layer sounds so much more interesting. And that is what I though the split to MK-HAL and MK-CNC was. MK-HAL would run on Zynq board, MK-CNC would run on Odroid and UI would run on RasPI. At the hearth of the machine would be switch and (separate) emergency stop circuit. > Understand that my opinion doesn't necessarily reflect the general > community consensus. I'm jumping in to help out with this work because I > think it's been sorely needed for a long time, and I'm super excited to see > people stepping up to sort out this extremely tedious but IMO valuable > change. > No disrespect, but given number of your commits, you represent big chunk of the community. I have been thinking about nice Core library which would represend object mapper to remote running Machinekit Instance hiding the ugly server side communication. That's one of the reasons why I consider Machinetalk so interesting. I know there are the QtQuickVCP and python implementations, but I much prefer modern standard C++ and don't like python (I am little horrified how much is python creeping in the code base), so that's why I am studying MK source. > John > > > ________________________________________ > From: [email protected] <javascript:> <[email protected] > <javascript:>> on behalf of [email protected] <javascript:> <[email protected] > <javascript:>> > Sent: Sunday, March 31, 2019 8:45 AM > To: Machinekit > Subject: [Machinekit] Border between Machinekit-HAL and Machinekit-CNC > > 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? > > 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. > > 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 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.) > > (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.) > > -- > 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] <javascript:><mailto: > [email protected] <javascript:>>. > Visit this group at https://groups.google.com/group/machinekit. > For more options, visit 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. For more options, visit https://groups.google.com/d/optout.
