Usual set of noob questions I'm afraid...

[Dave Covert]

Ok, so I want to build a 4'x8' CNC router (I have the table built and am starting on the gantry). 
I have a BBB and would like to use Machinekit (I think).
I have a couple of noob questions I need answered please...

1) Do I actually need MachineKit? or just LinuxCNC?

2) Let's say I use a NEMA 34 for the gantry and NEMA 24s for the Y & Z axes and drive them with something like this stepper driver.  What goes between the BBB and the stepper driver?

Thank you for your time,
Dave

[Michael Haberler]

> Am 22.03.2015 um 05:03 schrieb Dave Covert <dave...@gmail.com>:
>
>
> Ok, so I want to build a 4'x8' CNC router (I have the table built and am starting on the gantry).
> I have a BBB and would like to use Machinekit (I think).
> I have a couple of noob questions I need answered please...
>
> 1) Do I actually need MachineKit? or just LinuxCNC?

LinuxCNC does not run on the BBB. Machinekit is a fork of LinuxCNC which runs on a wider range of platforms, among other features.

So - yes.

>
> 2) Let's say I use a NEMA 34 for the gantry and NEMA 24s for the Y & Z axes and drive them with something like this stepper driver. What goes between the BBB and the stepper driver?

I'd use something which easily plugs into this stepper driver's parport-like plug, like the Xylotex capes. Jeff Pollard of Xylotex usually is tuned in here, he'd be a better reference than me on the issue.

-Michael

>
> Thank you for your time,
> Dave
>
>

> --
> 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.
> Visit this group at http://groups.google.com/group/machinekit.
> For more options, visit https://groups.google.com/d/optout.

[Viesturs Lācis]

On Sunday, March 22, 2015 at 6:03:07 AM UTC+2, Dave Covert wrote:

1) Do I actually need MachineKit? or just LinuxCNC?

Just like Michael pointed out, LinuxCNC will not run on BBB or any other hardware with ARM CPU. Just one small not from my personal experience - at the current moment BBB leaves a lot to be desired in graphical performance. There is serious effort being invested in remote GUIs and AFAIK a new kernel for BBB will have some improvements on hardware drivers for graphics, so my personal opinion is that at the moment for serious work using conventional PC provides better user satisfaction. And yes, Machinekit will run also on PCs.

2) Let's say I use a NEMA 34 for the gantry and NEMA 24s for the Y & Z axes and drive them with something like this stepper driver.  What goes between the BBB and the stepper driver?

Either some parport-style cape for BBB or some FPGA board for PC to do hardware signal generation and provide I/O pins. Mesa or Pico Systems are most commonly used manufacturers. 

[Michael Haberler]

> Am 22.03.2015 um 09:12 schrieb Viesturs Lācis <viestur...@gmail.com>:
>
>
>
> On Sunday, March 22, 2015 at 6:03:07 AM UTC+2, Dave Covert wrote:
>
> 1) Do I actually need MachineKit? or just LinuxCNC?
>
> Just like Michael pointed out, LinuxCNC will not run on BBB or any other hardware with ARM CPU.

I think Jeff Epler has LinuxCNC running on some Odroid with a modified kernel, so this might not be entirely accurate to the letter; but I think it is safe to say that multiple hardware platforms and a wide range of realtime kernels are not in that project's core focus; more like "desktop CNC". But better enquire yourself.

> Just one small not from my personal experience - at the current moment BBB leaves a lot to be desired in graphical performance.

right, but "desktop CNC on an ARM" might just be a fact of life for people using the legacy UI's based on NML because of limited options. And I hope that limitation will be history soon.

It is certainly not where I and many others want to head, which is a headless, remote realtime subsystem driven over a network connection which could - among other applications - serve something like the LinuxCNC application.

> There is serious effort being invested in remote GUIs and AFAIK a new kernel for BBB will have some improvements on hardware drivers for graphics, so my personal opinion is that at the moment for serious work using conventional PC provides better user satisfaction.

Graphics on the BB might be possible, it might make sense on and off; again, cramming everything onto the same platform which runs RT was a rich source of problems in the past, which is why I am lukewarm about repeating the exercise; it's just heading down the wrong lane, even if it could be done. And there is no point at that price.

- Michael

> And yes, Machinekit will run also on PCs.
>
> 2) Let's say I use a NEMA 34 for the gantry and NEMA 24s for the Y & Z axes and drive them with something like this stepper driver. What goes between the BBB and the stepper driver?
>
> Either some parport-style cape for BBB or some FPGA board for PC to do hardware signal generation and provide I/O pins. Mesa or Pico Systems are most commonly used manufacturers.
>

[Dave Covert]

I don't think I was that concerned about graphics anyway. My plan was to draw my designs on the lab PC, use Filezilla to FTP the file to the Bone, and then use VNC to run the GUI of MachineKit to run the file out.

Rational?

Dave

[david marquart]

This works, I had issues trying to run AXIS over VNC, but tkemc worked pretty good.  I believe the AXIS issue is the preview window on it (opengl related issues with vnc) but the details are a little foggy.  As far as the ftp goes it may be easier to just add a network location and "map" a drive to get your file on the machine.

[Timothy March]

You may want to try this and run Machinekit from pc
https://emc2arduino.wordpress.com/2013/12/25/hal2arduino-0-5-released/#comments

[Doug LaRue]

Doesn't using ssh with X forwarding eliminate the graphics issues of the BBB? I mean I thought that was the whole idea behind XWindows and the Xclient and Xserver design where the Xserver is what does the heavy graphics. It would be great to get to an even lighter UI experience as far as control goes and therefore also get to devices like phones and tablets but for now, installing an Xserver on your computer and using ssh with X11 forwarding should do the trick.

Or has 3D things become tied to the much to the Xclient that it doesn't matter much how powerful your Xserver machine is?

Doug

[Charles Steinkuehler]

The problem is X predates 3D graphics acceleration and when you watch
the 3D preview in a remote X11 window the calculations are all done on
the BeagleBone with the resulting 2D image sent across the network to
the client.

But you'll get reasonable performance if you just click over to the DRO
tab and ignore the 3D preview. This is typically how I run remote (via
ssh and X11 forwarding) or local (HDMI/DVI monitor connected to the BBB)
UIs when using the BeagleBone.

--
Charles Steinkuehler
cha...@steinkuehler.net

[Doug LaRue]

On Tuesday, March 24, 2015 at 3:03:04 PM UTC-7, Charles Steinkuehler wrote:

On 3/23/2015 4:02 PM, Doug LaRue wrote:
> Doesn't using ssh with X forwarding eliminate the graphics issues of the
> BBB? I mean I thought that was the whole idea behind XWindows and the
> Xclient and Xserver design where the Xserver is what does the heavy
> graphics. It would be great to get to an even lighter UI experience as far
> as control goes and therefore also get to devices like phones and tablets
> but for now, installing an Xserver on your computer and using ssh with X11
> forwarding should do the trick.
>
> Or has 3D things become tied to the much to the Xclient that it doesn't
> matter much how powerful your Xserver machine is?

The problem is X predates 3D graphics acceleration and when you watch
the 3D preview in a remote X11 window the calculations are all done on
the BeagleBone with the resulting 2D image sent across the network to
the client.

Yikes, that's ugly. I had just thought that the updates to X over the years kept up with the technology since OpenGL goes back to the 90s. Bummer it hasn't.

 

But you'll get reasonable performance if you just click over to the DRO
tab and ignore the 3D preview.  This is typically how I run remote (via
ssh and X11 forwarding) or local (HDMI/DVI monitor connected to the BBB)
UIs when using the BeagleBone.

yes, it's good that there is an easy option to 'turn off' the 3D output for remote use but maybe a software hack of being able to set the 3D refresh/update rate to something tied to the layers would be helpful. ie a setting of 1 only updates the 3D display on layer change, a 0 updates at full FPS and anything in between, is a percentage of full FPS. 

Doug

[Kent A. Reed]

On 03/25/2015 12:44 PM, Doug LaRue wrote:

On Tuesday, March 24, 2015 at 3:03:04 PM UTC-7, Charles Steinkuehler wrote:

On 3/23/2015 4:02 PM, Doug LaRue wrote:
> Doesn't using ssh with X forwarding eliminate the graphics issues of the
> BBB? I mean I thought that was the whole idea behind XWindows and the
> Xclient and Xserver design where the Xserver is what does the heavy
> graphics. It would be great to get to an even lighter UI experience as far
> as control goes and therefore also get to devices like phones and tablets
> but for now, installing an Xserver on your computer and using ssh with X11
> forwarding should do the trick.
>
> Or has 3D things become tied to the much to the Xclient that it doesn't
> matter much how powerful your Xserver machine is?

The problem is X predates 3D graphics acceleration and when you watch
the 3D preview in a remote X11 window the calculations are all done on
the BeagleBone with the resulting 2D image sent across the network to
the client.

Yikes, that's ugly. I had just thought that the updates to X over the years kept up with the technology since OpenGL goes back to the 90s. Bummer it hasn't.

 

But you'll get reasonable performance if you just click over to the DRO
tab and ignore the 3D preview.  This is typically how I run remote (via
ssh and X11 forwarding) or local (HDMI/DVI monitor connected to the BBB)
UIs when using the BeagleBone.

Doug:

Errrm, yes, the X-protocol itself can handle 3D. To cite Wikipedia, "X's network protocol is based on X command primitives. This approach allows both 2D and 3D operations to be fully accelerated on the remote X server." That's not the end of the story, but you'll have to do some digging to figure out where the logjam is occurring.

Two years ago, when the Beagleboard's BBB was still new territory for us, I started making some measurements of the impact of the different UIs available at the time on the performance of a BBB as an Xclient. Personal tragedy intervened and I never got back to the task, but I posted preliminary findings at https://sites.google.com/site/manisbutareed/beaglebone-black-linuxcnc.

For some of us, fixing Axis isn't an interesting problem, but if you are interested, then ....

Regards,
Kent

[Doug LaRue]

I've been poke around and will continue to figure out how it works but in the mean time I ran across something called VirtualGL which is what is used in VNC to get accelerated OpenGL on the remote machine. I'll see if this can be of any help here. http://sourceforge.net/projects/virtualgl/?source=navbar

I also ran across something interesting in regards to increasing the video framerate for openCV with an optimized libjpeg. This might also help with any web cam stuff(streaming) used in Machinekit. Also related to this improved performance was how to setup an optimized build environment for the BBB which uses distcc so an x86 PC can be used in conjunction with the BBB for faster building/compiling. Is this what you guys are using?

 http://blog.lemoneerlabs.com/3rdParty/Darling_BBB_30fps_DRAFT.html

I will look into these three: optimizing OpenGL for remote XServer display(VirtualGL maybe), setting up a distributed BBB build env and building the faster libjpg and see if that can help things like video streaming.

Doug

[Kent A. Reed]

On 03/25/2015 02:44 PM, Doug LaRue wrote:
> I've been poke around and will continue to figure out how it works but
> in the mean time I ran across something called VirtualGL which is what
> is used in VNC to get accelerated OpenGL on the remote machine. I'll
> see if this can be of any help here.
> http://sourceforge.net/projects/virtualgl/?source=navbar
>

Whether optimizing OpenGL transport is helpful depends on how Axis
generates OpenGL calls. Start at the pointed end of the stick:
src/emc/usr_intf/axis/scripts/axis.py and the supporting C code in
src/emc/usr_intf/axis/extensions for the supporting libraries which wrap
OpenGL in Python and Tcl (too bad we couldn't throw in some Java, C++,
Ruby, maybe a little Haskell just to round out the mix).

> I also ran across something interesting in regards to increasing the
> video framerate for openCV with an optimized libjpeg. This might also
> help with any web cam stuff(streaming) used in Machinekit.

Sounds intriguing, but I see the website you reference is 18 months old.
I wonder if by now the popular distros already build for NEON.

> Also related to this improved performance was how to setup an
> optimized build environment for the BBB which uses distcc so an x86 PC
> can be used in conjunction with the BBB for faster building/compiling.
> Is this what you guys are using?
> http://blog.lemoneerlabs.com/3rdParty/Darling_BBB_30fps_DRAFT.html
>

I can't speak for the collective "you guys" but some of us are either
building MK natively on ARM boards (notably non-BBB quad-core boards to
get better throughput) or cross-building MK on multi-core x86 machines.
I'd not heard of distcc before, which looks like a cute way to get some
of both but IMHO is just yet-another way to skin a cat (don't mind me,
I'm a curmudgeon). You could rig it up across multiple ARM boards too
(poor-man's cluster) and hence skip the cross-building part.

> I will look into these three: optimizing OpenGL for remote XServer
> display(VirtualGL maybe), setting up a distributed BBB build env and
> building the faster libjpg and see if that can help things like video
> streaming.

The more folks banging on keys, the better!

Regards,
Kent

[Doug LaRue]

On Wednesday, March 25, 2015 at 1:35:58 PM UTC-7, Kent Reed wrote:

On 03/25/2015 02:44 PM, Doug LaRue wrote:
> I've been poke around and will continue to figure out how it works but
> in the mean time I ran across something called VirtualGL which is what
> is used in VNC to get accelerated OpenGL on the remote machine. I'll
> see if this can be of any help here.
> http://sourceforge.net/projects/virtualgl/?source=navbar
>

Whether optimizing OpenGL transport is helpful depends on how Axis
generates OpenGL calls. Start at the pointed end of the stick:
src/emc/usr_intf/axis/scripts/axis.py and the supporting C code in
src/emc/usr_intf/axis/extensions for the supporting libraries which wrap
OpenGL in Python and Tcl (too bad we couldn't throw in some Java, C++,
Ruby, maybe a little Haskell just to round out the mix).

I got a hour to look around and from what I could figure out, GLX is the XServer module for 3D extensions to X and if you are running an XServer with that loaded then when you start your remote(BBB) XClient(Axis) with X forwarding and your local XServer has a nice OpenGL driver(ie DRI rendering) then things should be pretty good. It's the VNC type of remote displays which do what Charles mentioned, ie create an image of the rendered OpenGL window and send the image over the network. I would imagine they would be smart enough to use MPEG or something like that which really only send the difference with the previous frame/image.

So unless the network traffic of standard OpenGL calls causes too much CPU usage the best solution is probably as Charles mentioned, don't show the 3D window OR a modification to the source is added to change the FPS of the 3D rendering window and therefore reduce the network traffic.

 

> I also ran across something interesting in regards to increasing the
> video framerate for openCV with an optimized libjpeg. This might also
> help with any web cam stuff(streaming) used in Machinekit.

Sounds intriguing, but I see the website you reference is 18 months old.
I wonder if by now the popular distros already build for NEON.

> Also related to this improved performance was how to setup an
> optimized build environment for the BBB which uses distcc so an x86 PC
> can be used in conjunction with the BBB for faster building/compiling.
> Is this what you guys are using?
> http://blog.lemoneerlabs.com/3rdParty/Darling_BBB_30fps_DRAFT.html
>

I can't speak for the collective "you guys" but some of us are either
building MK natively on ARM boards (notably non-BBB quad-core boards to
get better throughput) or cross-building MK on multi-core x86 machines.
I'd not heard of distcc before, which looks like a cute way to get some
of both but IMHO is just yet-another way to skin a cat (don't mind me,
I'm a curmudgeon). You could rig it up across multiple ARM boards too
(poor-man's cluster) and hence skip the cross-building part.

I went through and did the distributed CC thing and it works pretty cool. You install the cross compiler on your PC, set up a couple of env vars and start the distributed CC daemon specifically allowing the BBB IP to connect to it. On the BBB you also install distcc, create some symbolic links from the distcc, distcpp, distgcc, distg++, etc files to /usr/local/bin/., set up some env vars so that compiles use the remapped /usr/local/bin/cc links and start building/making/compiling on the BBB. What happens is the compiling occurs on the PC with how ever many threads you specify on both ends. Linking with libraries happens on the BBB so all the extra libs don't have to be installed on the PC cross compiler setup.

So I guess the advantage of using distcc is that the PC build environment is much easier to set since all the libraries linking with stay on the BBB. I've only tried it so far with hello_world and compiling the 1.3 and 1.4 versions of libjpeg-turbo.  I should time it with distcc, remove all the sym links and build strictly on the BBB and see what the difference is.  I'll post back on that.

 

> I will look into these three: optimizing OpenGL for remote XServer
> display(VirtualGL maybe), setting up a distributed BBB build env and
> building the faster libjpg and see if that can help things like video
> streaming.

The more folks banging on keys, the better!

yes but I really should finish getting my machinekit rebrain of avr/marlin finished along with at least 3 other projects going on simultaneously  here at HQ.  I do want to dig into Machinekit and create and/or fix things for sure.

Doug

[Doug LaRue]

using distcc(ie cross compiling) makes a fast improvement in compilation speed. Remember, I downloaded the source on the BBB, ran ./configure on the BBB and just ran "make clean; time make" over and over on the BBB but sometimes with the distcc configured and once unconfigured so it was all being done on the BBB. 

distcc- building libjpeg-turbo version 1.4 - using "time make" - hostPC Ubuntu 14.04 4core i5-3230M CPU @ 2.60GHz

Run 4 times using distcc over eithernet while logged in via USB

1-ethernet-4 procs

real    2m58.121s

user    0m50.684s

sys     0m49.443s

2-ethernet-4 procs

real    2m58.318s

3-ethernet-4 procs

real    2m56.757s

4-usb-4 procs

real    2m57.112s

Run over the USB network resulted in about the same as over ethernet

5-usb-4 procs

real    2m55.201s

Run local on the BBB

6-local

real    11m30.546s

[John Morris]

Doug,

What you're doing here is really interesting. I never would have
thought to run the main build on the BBB, but distribute compilation to
PCs with cross-compiler. I'm going to have to try this out.

I updated the Machinekit build system a few months back so that ARM
cross-compiles can run completely on x86. On a multi-core machine, I
get about the same sub-3 minute compile as you do, either while
cross-compiling or native.

The advantage your method has over mine is the cross-compile package
deps are very hard to get right. Debian package 'Multi-Arch:' tags are
supposed to help when automatically installing build dependencies with
e.g. 'mk-build-deps -a armhf', but in practice those tags are absent in
some cases and don't help with cross toolchain deps in any case. You
can see the ugly way I handle this here with a manual list of package deps:

https://github.com/zultron/machinekit/blob/docker/docker/Dockerfile.trusty-armhf-cross#L36-L80

Gemi, Kent and I have been playing with emulated and cross builds for
ARM, and Gemi has found some interesting ways to hybridize this like you
have. I'm about to start thinking about this again soon once other
projects wind down, and I'd love your help.

John

> --
> 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

> <mailto:machinekit+...@googlegroups.com>.

[Kent A. Reed]

On 03/26/2015 12:03 PM, John Morris wrote:
> Doug,
>
> What you're doing here is really interesting. I never would have
> thought to run the main build on the BBB, but distribute compilation
> to PCs with cross-compiler. I'm going to have to try this out.
>
> I updated the Machinekit build system a few months back so that ARM
> cross-compiles can run completely on x86. On a multi-core machine, I
> get about the same sub-3 minute compile as you do, either while
> cross-compiling or native.
>
> The advantage your method has over mine is the cross-compile package
> deps are very hard to get right. Debian package 'Multi-Arch:' tags
> are supposed to help when automatically installing build dependencies
> with e.g. 'mk-build-deps -a armhf', but in practice those tags are
> absent in some cases and don't help with cross toolchain deps in any
> case. You can see the ugly way I handle this here with a manual list
> of package deps:
>
> https://github.com/zultron/machinekit/blob/docker/docker/Dockerfile.trusty-armhf-cross#L36-L80
>
>
> Gemi, Kent and I have been playing with emulated and cross builds for
> ARM, and Gemi has found some interesting ways to hybridize this like
> you have. I'm about to start thinking about this again soon once
> other projects wind down, and I'd love your help.
>
> John
>

My only concern is that the last distcc package, dated Oct 2011, was
distcc-3.2rc1-1 from which I infer the air was let out of their tires
before it got out of release-candidate status. I'd love to know why.

That doesn't mean I didn't download it as soon as Doug brought it to our
attention:) Can't say how far I will get playing with it before I depart
for Munich next week to visit my sister.

Regards,
Kent

[Jeff Means]

Yes driving the xserver over whatever network is _STILL_ running the xserver on the BBB! Please get this fact that no matter what this is just remoting the desktop from the BBB but it is still generated and updated on the BBB as such it could be even more lag sensitive having network conditions thrown in as well. :-(

Jeff Means

[Daren Schwenke]

Not exactly true.  With the extensions properly setup, rendering is offloaded to the client.  

Then just the opengl calls, not the entire X display, go over the wire and the server (the BBB) no longer has to render anything.

As our current debian lacks hardware acceleration support for this, the opengl is all done in software.  It runs pretty well considering the latter.

Hardware acceleration works fine in later releases, but the realtime bits aren't there yet.  There's the rub.

So pursuing proper setup of the opengl extensions for remote rendering would probably work pretty well.  I haven't bothered to find out.

I second the comment on using distcc for compiling from the BBB.  Worked great and was seamless once setup, for opencv at least.  Never tried compiling Machinekit.

[Kent A. Reed]

On 03/18/2016 05:12 AM, Daren Schwenke wrote:
> Not exactly true. With the extensions properly setup, rendering is
> offloaded to the client.
> Then just the opengl calls, not the entire X display, go over the wire
> and the server (the BBB) no longer has to render anything.

A minor nitpick. Calling the BBB a server in the context of the X
Windows System is a misnomer.

In X, "client" and "server" designations are all about the programs.
Machinekit is an X-client program running on the BBB, requesting
bitmapped display and input-device resources from an X-server program
which may be running locally or remotely. Many discussions involving X
get tangled up over the terminology, and not just "client" and "server".
I just used "local" and "remote" to mean a program running on the same
(local) computer or on a different (remote) computer, where the remote
computer is the one with the display, keyboard, mouse, etc.. Many
discussants assume "local" always means whatever computer they're
sitting at. Like I said, it's all about the programs.

None of which detracts from your central point. Bring on the extensions!

Regards,
Kent

PS - The boys at MIT laid out their principles for X in 1984. I believe
it has lasted as long as it has because of one of the designers' core
principles: "It is as important to decide what a system is not as to
decide what it is. Do not serve all the world's needs; rather, make the
system extensible so that additional needs can be met in an upwardly
compatible fashion" [quoted from Wikipedia]. Sound familiar? I believe
Herr Haberler has had similar things to say about machinekit. Let's hope
it lives as long.

[Daren Schwenke]

Yeah.. it was late.  I know better.  :)

It has lasted so long because it's been completely bastardized to do things it wasn't intended to do, over and over.  

Now it's such a nightmare to work on people can't wait to get rid of it.

Bring on Wayland.

--
website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit

--- You received this message because you are subscribed to a topic in the Google Groups "Machinekit" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/machinekit/bIU9ZMhXCYw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to machinekit+...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.

[Kent Reed]

I know well what "it was late" means. Been there, done that!

As for Wayland, sure, bring it on. I've been expecting to see it "real soon now" for half a decade. It's getting closer to being fully integrated into major distros but I'm getting old. We'll see.

Regards,

Kent

[Means, Jeffrey D.]

Thanks for the non flaming answers. I still think from my experimenting with x it does take a hefty chunk of processor time that would be better served dealing with not having to be a head if we were able to get an udp/tcp front-end that was not forced to depend on an x server application for display needs.

[Kent A. Reed]

On 03/21/2016 03:45 PM, Means, Jeffrey D. wrote:

Thanks for the non flaming answers. I still think from my experimenting with x it does take a hefty chunk of processor time that would be better served dealing with not having to be a head if we were able to get an udp/tcp front-end that was not forced to depend on an x server application for display needs.

I've lost the thread of this conversation. What is meant by "my experimenting with x" and "take a hefty chunk of processor time"? Does this mean you've done quantitative work like I started on years ago before machinekit forked from LinuxCNC and mhaberler had only recently reported his success bringing up a BBB (https://sites.google.com/site/manisbutareed/beaglebone-black-linuxcnc)? If so, please publish your numbers. My work was preliminary and has been gathering dust. I would be happy to see someone else do work like it now that more GUI possibilities like machineface exist. Just remember those timeless quotes from Lord Kelvin (hero of my former employer, the National Institute of Standards and Technology). A particularly good one is:

    "I often say that when you can measure what you are talking about, and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meagre and unsatisfactory kind"

Regards,
Kent

[Means, Jeffrey D.]

You actually just hit the problem I was trying to address by mentioning that SSH adds to the processor load dramatically, and running X over the connection only makes things worse. What I was really trying to get at was the difference between a truly headless sever running in text mode for console access only, and a network connection which is doing an on the fly encryption, and compression to the network traffic, which by the way also includes the graphics updates being sent to the x-client. Mind you that the x-server running on the beaglebone is doing most of the heavy lifting for all screen/window updates including serving the screen updates which are to be displayed on the client. This is where I'm having issues. Have you any numbers where you ran the beaglebone in init level 3 text mode, using machineface/ mklauncher for UI on a client system? I'm trying to get these numbers (running top via a tty) but I was wondering if you had any such experience already?

Thanks (you can tell me if I'm over complicating things here but I think it should be noticeable to get rid of the x-server on the beaglebone altogether. Not to mention memory (RAM) load as well in this case.)

Jeff Means

[Kent A. Reed]

On 03/22/2016 09:49 AM, Means, Jeffrey D. wrote:
>
> You actually just hit the problem I was trying to address by
> mentioning that SSH adds to the processor load dramatically,
>

Of course you don't have to use SSH on a protected LAN, and you can
chose SSH encryption schemes which are easier on the CPU than is the
default scheme.

> and running X over the connection only makes things worse.
>

The question is, how much does the X-client on the BBB have to do, and
Daren was pointing out that with certain X-extensions that load can be
lessened. I don't have numbers.

> What I was really trying to get at was the difference between a truly
> headless sever running in text mode for console access only,
>

Headless just means the BBB has no local display, keyboard, mouse,
whether one is running X-clients or not. In X-terminology, the
BBB/machinekit combo is an X-client, not an X-server.

> and a network connection which is doing an on the fly encryption,
>

But see above.

> and compression to the network traffic,
>

Compression can actually help, depending on the details of the network
capabilities.

> which by the way also includes the graphics updates being sent to the
> x-client. Mind you that the x-server running on the beaglebone is
> doing most of the heavy lifting for all screen/window updates
> including serving the screen updates which are to be displayed on the
> client. This is where I'm having issues.
>

Again, think about Daren's comment (and note X server and X client are
reversed in the above). Those updates have to be communicated somehow no
matter what protocol is in play. I don't know the details of Qt versus X
when it comes to rendering our screens so I can't comment.

> Have you any numbers where you ran the beaglebone in init level 3 text
> mode, using machineface/ mklauncher for UI on a client system? I'm
> trying to get these numbers (running top via a tty) but I was
> wondering if you had any such experience already?
>

No. All my experiments came to a stop as I devoted all my time to care
for my wife in her losing battle against cancer. I haven't returned to
them since so machinetalk is new business. I did install an early
version of it and got working displays on my Android tablet and phone,
but that was to understand how the connection is established. I haven't
had time to do anything beyond that and I'm certainly out of date now.

> Thanks (you can tell me if I'm over complicating things here but I
> think it should be noticeable to get rid of the x-server on the
> beaglebone altogether. Not to mention memory (RAM) load as well in
> this case.)
>

In the words of Shakespeare, "Lay on, Macduff!" Let us know what you find.

(I'm wondering though, how much difference practically this change makes
in terms of the BBB performance running machinekit. If it isn't compute-
or memory-bound then maybe little; if it is, then maybe more. We shall see.)

> Jeff Means
>
>

Regards,
Kent

[Daren Schwenke]

From a quick query on my machineface based system:

X + window manager is using half the ram of mklauncher + configserver.

mklauncher on my box uses ~24% cpu while running.

Axis was nearly 100% cpu, but that was largely due to the opengl software calls I'm sure.

The next step would be setup the opengl extensions.  I have no reason to do that.

[Means, Jeffrey D.]

Thanks for the heads up. As soon as I get though this'd current migraine I'll try to put together some really current numbers with x and without and since we've tossed SSH into the mix I'll go ahead and generate some of those numbers as well

[Doug LaRue]

I don't know if this went anywere, ie setting up distcc to build Machinekit, but with all the other ARM stuff going on around the world(rPi, etc) cross compiling came up and as usual up came requirements for native building of some parts and I mentioned distcc.  While I missed the news in 2018 distcc was updated to v3.3 in 2018.

Happy Solstice, Merry Christmas or whatever you're into this time of year.