On 09/09/2018 03:05 AM, Chris Morley wrote:
I see that machinekit has broken out HAL and cnc (Well and lots of others) into
different repositories.
https://github.com/machinekit
[https://avatars1.githubusercontent.com/u/6759549?s=280&v=4]<https://github.com/machinekit>
machinekit · GitHub<https://github.com/machinekit>
github.com
GitHub is where people build software. More than 28 million people use GitHub
to discover, fork, and contribute to over 85 million projects.
It also seems they have updated HAL considerably,
They were working on RT multicore support, anytime instantiation of HAL
components
cython support.. probably other stuff - I'm not sure if it includes ARM or FPGA
upgrades.
I was thinking that maybe linuxcnc should discuss if that is something that
would be of interested.
pros I see:
-chance to break HAL out of cnc stack
-seemingly an upgrade in capability
-someone else has done a lot of work/testing already
-might allow more cross work of developers between the projects
cons:
-surely a lot of work to incorporate (though it does support legacy code, if I
understand right)
-lack of experience with concepts/code - will take time to become comfortable
-we'd have to admit they are not bad people :)
Ok that last one was meant as fun.
There are very smart and hard working people on both projects, it would be nice
to benefit both
projects.
I have not really looked at the code, nor am qualified to give indepth opinion
of the code.
I have watched the video of the multicore idea.
https://www.youtube.com/watch?v=brT0bEkJLSY
There are more videos (including one about the trajectory planner that we now
use)
Thoughts?
Chris M
【I accidentally sent this from the wrong address, and it was bounced...]
Thanks for raising this topic, Chris, it would be great to see more
cooperation between the LCNC and MK projects.
I'd also like to bring the more actively maintained EMC application from
the LCNC project together with the new features in HAL from the MK
project. Another way to achieve that is to update LCNC so that EMC can
be built against an external MK HAL. That might be an easy way to get
something started where we could start exploring the problem early. If
it were successful, this approach could also be a conservative way to
give users the option of using MK HAL from mainline LCNC branches while
still maintaining the current HAL as the default.
[Chris M replied to ask what's new in MK HAL that's not in LCNC HAL, and
I replied...]
TBH, at some point I lost track of what was added to MK HAL. I think
you're right, connecting LCNC EMC with MK HAL would be an all-or-nothing
affair, since the major restructuring would make it difficult to pick
out individual features, if they're even separable at this point. I
still think that LCNC could be taught to build against MK HAL, though,
without committing to throwing away current HAL.
Also, IMO, the MK project's splitting HAL and EMC was a good move, since
HAL is awesome on its own: I've used it to build dumb things like an
incubator and autoclave, and smart things like a ros_control hardware
interface (dig through my GH repos to find these). Splitting these not
only dumps a huge amount of build complexity and unnecessary
dependencies for HAL-only projects, but also exposes HAL as something
that can gain its own following.
Off the top of my head, here are the MK HAL-specific features I am
familiar with:
- `rtapi_msgd` runs alongside `rtapi_app` and relays log messages over
ZeroMQ
- "HAL talk" passes signals over ZeroMQ, enabling remote components
(I've used this extensively in combination with Alexander Roessler's
QtQuickVCP remote GUI; my incubator and autoclave are public examples)
- "Instantiable components" allow adding new comp instances on the fly;
useful when e.g. including a HAL file so you don't have to declare all
instances at the first `loadrt`
- Cython bindings to HAL enable replacing traditional `.hal` files with
Python code; this has been useful to me when writing configurations for
robots that have several variants: the flexibility of Python greatly
simplifies the HAL config
- Multi-core: enables running HAL threads with CPU affinity; I recently
found that combined with `rtpart`, a `latency-test` that normally has
40us jitter (on a J1900) has 6us when the HAL thread is given a
dedicated core (this may help solve some chronic EtherCAT "missed
datagram" issues we've been suffering)
- Ring buffer API: Currently only used by HAL talk AFAIK, a
standardized way of passing blocks of data into/out of HAL in a RT-safe way
- (Not sure how much in HAL and how much in the hm2 firmware, but)
Support for hm2 on Zynq SOCs
...and probably other things I'm unaware of or have forgotten. I have
never seen documentation for these things, but I may not have looked in
the right place.
NML is part of EMC, and connects the UIs (status, command, error) and
motion/io to task, so MK HAL is completely independent. My
understanding is weak here, but Alexander Roessler wrote some sort of
NML wrapper called "machine talk" that delivers UI messages to a remote
GUI, and he has two QtQuickVCP GUIs "Cetus" and "Machineface" for a CNC
mill and 3D printer (respectively, or possibly vice-versa) to go along
with that. He posted here maybe a year ago asking whether there was
interest in porting that to LCNC.
[My apologies; I meant to keep this on-list, but I'm still getting used
to a new email setup after switching to M$ infrastructure that's not
blocked here in China, where I'll be for a while.]
John
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
