side-by-side install linuxcnc and machinekit

183 views
Skip to first unread message

sliptonic

unread,
Nov 23, 2019, 1:42:48 PM11/23/19
to Machinekit
I converted my mill back to linuxcnc a while back because of compatibility problems with gmoccapy.   
However, I'd like to experiment with mlampert's machinekit workbench in FreeCAD.

Is it possible to install both side-by-side?  (Debian stretch)

Any gotchas to be aware of?


Bas de Bruijn

unread,
Nov 23, 2019, 3:34:26 PM11/23/19
to sliptonic, Machinekit
As far as i’m aware of you can install both as a RIP (run in place) built from source.
Then running the rip-environment script from one of both allows you to use one of both

sliptonic

unread,
Dec 2, 2019, 4:26:53 PM12/2/19
to Machinekit
I've made some progress on my side-by-side configuration.  I can now selectively start either LinuxCNC or Machinekit in a RIP.
The linuxCNC config still isn't working since it's at version 2.9 which has the JA branch merge and some part of the configuration is causing following errors.   
My present configuration not withstanding, the JA changes look really interesting, especially for my Scara robot.    What's the outlook for the JA changes to be ported into machinekit?

My machinekit install will start and run locally on the mill with the gmoccapy UI.  

When I try to start with mklauncher, mkwrapper and cetus, however, I get results that I don't understand:  It starts without error on the mill machine.  
I launch the client on a remote machine and it instantly finds the mill machine.  I browse for remote UI and select cetus.  
Cetus launches with all controls greyed out for approximately 45 seconds.  Then the controls activate for a few seconds before greying out again.  This continues indefinitely.

Instead of the machinekit client and cetus,  I tried connnecting with mlampert's FreeCAD machinekit workbench and get similar behavior.  It seems to find the mill machine immediately but takes a long time to 
communicate anything with it.  If initiate homing, the homing sequence actually starts about a minute later.

I'm not sure how to troubleshoot further so I'm looking for suggestions.

Mill machine is running Debian stretch with 4.9.0-11-rt-amd64  kernel.

justin White

unread,
Dec 2, 2019, 8:04:38 PM12/2/19
to Machinekit
I went through the JA switch with LinuxCNC when I started using a Mesa 7i96 which was only supported in 2.8pre1 not 2.7. 2.8+ will prompt to rewrite the hal and ini files automatically, but I had a PIA of a time with Python stuff because they added an extra argument to select control of the joint or the axis but didn't document it well.

I was kind of wondering about the JA inclusion into MK but seeing as how MK is super far behind in Mesa drivers and plenty of other things I'm not sure it's at the top of the list. Not sure about the remote setup but machinekit doesn't seem to like to print to the terminal like LinuxCNC does. If you set the debug level it with throw errors to a logfile in /var/log/linuxcnc.log or something like that. Might try looking there.

Bas de Bruijn

unread,
Dec 3, 2019, 1:00:33 AM12/3/19
to sliptonic, Machinekit


On 2 Dec 2019, at 22:26, sliptonic <shopint...@gmail.com> wrote:

I've made some progress on my side-by-side configuration.  I can now selectively start either LinuxCNC or Machinekit in a RIP.
The linuxCNC config still isn't working since it's at version 2.9 which has the JA branch merge and some part of the configuration is causing following errors.   
My present configuration not withstanding, the JA changes look really interesting, especially for my Scara robot.    What's the outlook for the JA changes to be ported into machinekit?

I think that the best hope is that someday LCNC can be built on top of Machinekit-HAL. I think chances of ports to Machinekit are nonexistent.
Maybe some developers can chime in.

My machinekit install will start and run locally on the mill with the gmoccapy UI.  

When I try to start with mklauncher, mkwrapper and cetus, however, I get results that I don't understand:  It starts without error on the mill machine.  
I launch the client on a remote machine and it instantly finds the mill machine.  I browse for remote UI and select cetus.  
Cetus launches with all controls greyed out for approximately 45 seconds.  Then the controls activate for a few seconds before greying out again.  This continues indefinitely.

Instead of the machinekit client and cetus,  I tried connnecting with mlampert's FreeCAD machinekit workbench and get similar behavior.  It seems to find the mill machine immediately but takes a long time to 
communicate anything with it.  If initiate homing, the homing sequence actually starts about a minute later.

I'm not sure how to troubleshoot further so I'm looking for suggestions.

I have no in depth knowledge on the remote stuff so I hope someone with more knowledge can chime in. I’d start with Justin’s remark in setting the debug level to 5 and digging thu the linuxcnc log.


Mill machine is running Debian stretch with 4.9.0-11-rt-amd64  kernel.






On Saturday, November 23, 2019 at 12:42:48 PM UTC-6, sliptonic wrote:
I converted my mill back to linuxcnc a while back because of compatibility problems with gmoccapy.   
However, I'd like to experiment with mlampert's machinekit workbench in FreeCAD.

Is it possible to install both side-by-side?  (Debian stretch)

Any gotchas to be aware of?


--
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 machinekit+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/c039685f-072f-41f3-9df3-af30a1348566%40googlegroups.com.

markus

unread,
Dec 3, 2019, 2:44:37 PM12/3/19
to Bas de Bruijn, sliptonic, Machinekit
> I think that the best hope is that someday LCNC can be built on top
> of Machinekit-HAL. I think chances of ports to Machinekit are
> nonexistent. Maybe some developers can chime in.
>

Newbie here - what does that mean running LCNC on top of MK HAL ?

Bas de Bruijn

unread,
Dec 4, 2019, 5:34:57 AM12/4/19
to markus, sliptonic, Machinekit
Machinekit-HAL is the HAL part without the CNC application. The Machinekit HAL differs a lot with the HAL from LinuxCNC. Multicore capabilities, instantiatiable components, remote capabilities and whatnot.
So Linuxcnc can potentially reuse Machinekit-HAL.

markus

unread,
Dec 4, 2019, 12:11:15 PM12/4/19
to Bas de Bruijn, sliptonic, Machinekit
Thanks - what I'm not quite clear on is where does
MK-HAL end and LCNC start. Is there a library, program, interface that
needs adapting? If one wanted to have a go at it, what would be a
general plan of attack and where would one start? I can't commit on
anything at the moment but I'm genuinely interested in how this works.

justin White

unread,
Dec 4, 2019, 8:45:57 PM12/4/19
to Machinekit
LinuxCNC was the open source continued developement of EMC > EMC2 which was developed by NIST as a government awarded contract then dropped. Some years ago Machinekit was forked off of LinuxCNC because I believe some of the LinuxCNC devs were not happy with progression and the time it took to merge new ideas. LinuxCNC aimed to be stable and ready for industry  while MK seems to prefer advancing in about as many directions as it can handle.

Among those MK advancements was a somewhat recent (I believe) split of the real-time hal portion and CNC controller/userspace portion into 2 separate stacks. LinuxCNC never split the hal and "CNC" potions, it's still just one big program. While MK made some really interesting and probably smart moves with multi-core, split stack, mksocfpga, etc.. LinuxCNC's own advancements, from what I see have been lost and never integrated back into MK. The JA split and Mesa drivers are the ones that bite me the worst on MK.

I don't really see the logic in trying to run LinuxCNC in some split fashion on top of MK-hal.....The Joints/Axis split isn't that big of a deal unless you need to run some crazy hexapod thing or something, it mainly erks me because configs are just a bit more difficult to move between LCNC and MK, tho LCNC stable is at 2.7 which IIRC was prior to the JA split. I think if you're capable a better use of time would be to try to integrate some of LinuxCNC's changes into MK, whether that be a forked branch or PR or something. You're probably not really missing anything unless there's something specific that you need.

Personally I think the 2 projects could use some parity with JA, Mesa drivers,  and UI toolkits. Maybe it's me but I've found QTquickVCP to be a huge PIA, everytime I sit down and try to get something going I fail miserably. LinuxCNC has adopted QT recently as well with the QTVCP tools. I hate to say it but I'm fairly certain that I could sit down and look at LinuxCNC's documentation on qtvcp and get a UI started in a day. Honestly I wish either of them would have just moved to GTK3 to replace GTK2 since updating UI's would have been a hell of a lot easier, I actually did re-do my custom LCNC GTK2 UI in GTK3 halfway before I realized LCNC pretty much abandoned the GTK3 branch before completing it.

Anyway, I'm ranting.....I think they're 2 great projects that could certainly benefit from some cooperation. Each has something I wish the other had.
Reply all
Reply to author
Forward
0 new messages