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.
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.
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.
John
________________________________________
From: [email protected] <[email protected]> on behalf of
[email protected] <[email protected]>
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]<mailto:[email protected]>.
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.
