How often are upstream changes merged?

[jallwine]

It looks like the last merge was in October 2020. Is it difficult to merge in the latest?

[cerna]

@jallwine,

I originally wanted to merge after the upstream Python3 will be fully integrated with Debian packaging. It looked it will happen any moment back in October, but as with everything it took more time and as far as I know it still is not done.

(And then I forgot about it.)

I hope it will be a simple merge with maybe a few conflicts here and there. I will look over the weekend.

The build is a bigger problem, as upstream is not supporting Multi-Arch, so you have to use QEMU Static builder.

[jallwine]

That shouldn’t be a problem. I’m currently using QEMU to build from source as a RIP environment so that I can build it with Python 3 support and develop further on the BeagleBone if necessary without needing to do a full build. Are the latest MachineKit-HAL packages Python 3 compatible? I think I have an old MachineKit-HAL version set so that I have Python 3.

[cerna]

Are the latest MachineKit-HAL packages Python 3 compatible?

The latest packages are not only Python3 compatible, these are Python3 exclusive. This is the problem with upstream Debian packaging. So far it is using the Python2 (you can select Python3 when building by hand and not via the debian/rules script as seen here from the current master), which is why you have to build it against Machinekit-HAL package from time before the Python3 switch.

[jallwine]

How difficult would it be to build MachineKit-HAL and EMCApplication with the latest version of Python (or any arbitrary locally installed version)?

[cerna]

@jallwine,
quick test in https://github.com/cerna/emcapplication/tree/emcapplication-02-july-2021 seems to be working - at least on amd64 and while using non-realtime POSIX system.

How difficult would it be to build MachineKit-HAL and EMCApplication with the latest version of Python (or any arbitrary locally installed version)?

I just tried it with the Debian 10 Buster standard 3.7.x and it seems to be working fine. The problem is in the Debian packaging - the moment I redo it (and frankly, redoing the Machinekit-HAL swo far seems enough for me), I am opening myself to quite hard maintenance burden.

[jallwine]

Thanks @cerna! I don’t expect it to work out of the box with any Python version. I’m happy to do the work necessary if it’s feasible, but I don’t know how to judge that. I’m not all that familiar with Debian packaging, but would it be feasible to take out the Python package dependency and set a few paths to a locally installed version?

[the-snowwhite]

@jallwine
I wonder which gui option you are using with the beaglebone:
@cerna
ARAIK there are no current remote gui options with the current mk-hal emca combo.
I tried to fix it but could only get the py2 Machinekit client (mkwrapper ?)communication version in py 2.
All of my attempts with my py 3 update versions failed:
Python version of hal was easiely includable and works well except the mcode .ngc macropart.
I decided to wait for more folks...

[jallwine]

@the-snowwhite, we’re using a fork of Rockhopper that we’ve put a lot of work into along with a custom web UI that we’ve built from scratch. We haven’t released the new UI yet nor the latest Rockhopper changes (we hope to within the next couple months).

Rockhopper isn’t too much different than what we have on production machines currently (this one is still on Python 2 and doesn’t have the axes/joints changes):
https://github.com/PocketNC/Rockhopper

Our production UI is a fork of EmperorWeb (the new one we rewrote from scratch using React):
https://github.com/PocketNC/pocketnc-ui

[jallwine]

I should clarify that our current production machines still use the archived version of MachineKit. We’re in the process of getting a working version of MachineKit-HAL+EMCApplication with the new UI and modified version of Rockhopper.

[cerna]

@the-snowwhite,
Yes, I know. I looked at it some time back, but was not able to get it working in five minutes (or five hours), only get it to some semi working state.

Maybe much of this is self-inflicted, and I would be able to get it to working state given enough time, but I really don't like how it was all interweaved together in the monorepo and to make working on it more pleasant, first the split into modularized approach would need to happen. (Better one that what was in Machinekit-HAL+Machinekit-CNC.) So that is what I was targeting so far.

So far the message specification even for CNC part of thing is still part of Machinekit-HAL. (Should not be.) And it is all in one package (messages used for CNC communication, messages used for HAL part etc.)

---

BTW, for example, the most build changes to get the current upstream merged was about the libtooldata.so - which is a new implementation of tool database merged I think in January. Problem is, it introduces a completely new IPC mechanism based on POSIX shared memory paradigm (even though it has a "fallback" NML communication, but we all know how this ends).

[cerna]

@jallwine,
have you tried that branch? Is it working?

I was looking at merging the latest changes and creating a PR, but the switchable kinematics and latest Python+GTK changes will need deeper thought, so I would PR just that what I had working.

[jallwine]

Sorry, I haven't had a chance to try it yet.