Web based Machinekit UI

[Jason Kridner]

This seems to be an often asked question. If I interpret things right, the answer is always to remote an X interface with an X server or VNC. This answer won't do for me, so I hope to avoid going off on that tangent. I need the UI to be served up in an HTML/CSS/JS-based browser. 

Am I correct to assume that no one has reached a viable prototype of such an interface?

One of the answers thrown out is to use a Qt5 app. I am wondering if the idea is to use Qt WebKit Bridging (http://doc.qt.io/qt-5/qtwebkit-bridge.html). Does anyone have experience with that? Is it worth exploring?

[Michael Haberler]

Hi Jason,

> Am 19.08.2015 um 22:21 schrieb Jason Kridner <jkri...@gmail.com>:
>
> This seems to be an often asked question. If I interpret things right, the answer is always to remote an X interface with an X server or VNC. This answer won't do for me, so I hope to avoid going off on that tangent. I need the UI to be served up in an HTML/CSS/JS-based browser.
>
> Am I correct to assume that no one has reached a viable prototype of such an interface?

there are two 'hooks' into the machinekit stack:
- a high-level one (the 'linuxcnc' API as exposed by the linuxcnc Python module, and a C++ API)
- a low-level API into HAL territory

Status of UI's:
- there is a web-based UI called emcweb, which uses the legacy linuxcnc C++ API (the equivalent of the linuxcnc Python module); beyond that it lacks capabilities to talk to HAL, but as far as I can tell it works
- there was an effort called RockHopper which targeted both API's but it never reached maturity

Status of API's:
- the 'native' API in machinetalk is zeroMQ/protobuf based, which is what Alex' UI's are using
- there is the 'webtalk' websockets/JSON bridge into machinetalk which can be used for web-based interaction; it has not seen substantial use but I plan to support it in case that happens; it does work with the HAL API and likely with the linuxcnc API (since then the mkwrapper effort has happened which gives a zeroMQ/protobuf API into the legacy linuxcnc API, it might well work). Example use: https://github.com/machinekit/machinekit/tree/master/src/machinetalk/tutorial/motorctrl


so clearly there is a need, some parts available but nothing coherent has appeared yet.



The closest match I see: Bob van der Linden has taken up an effort to tie both API's into node.js, using the node protobuf and zeromq bindings: https://github.com/bobvanderlinden/pymachinetalk-client, see the issue tracker there where we discuss that effort

(the 'python' part comes in as part of API exploration, eventually it will be native node.js)

I would suggest you get in touch and join forces; happy to coach from the sideline but be warned - complete JS/node.js/JSON/web idiot here ;)

> One of the answers thrown out is to use a Qt5 app. I am wondering if the idea is to use Qt WebKit Bridging (http://doc.qt.io/qt-5/qtwebkit-bridge.html). Does anyone have experience with that? Is it worth exploring?
>

Alex mentioned this recently. He'll likely answer this


- Michael

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

[Alexander Rössler]

Jason Kridner writes:

> This seems to be an often asked question. If I interpret things right, the answer is always to remote an X interface with an X server or VNC. This answer won't do for me, so I hope to avoid going off on that tangent. I need the UI to be served up in an HTML/CSS/JS-based browser.
>
> Am I correct to assume that no one has reached a viable prototype of
> such an interface?

That's correct for web interfaces.

>
> One of the answers thrown out is to use a Qt5 app. I am wondering if
> the idea is to use Qt WebKit Bridging
> (http://doc.qt.io/qt-5/qtwebkit-bridge.html). Does anyone have
> experience with that? Is it worth exploring?

No, it is a native solution. No web stuff necessary. It uses the native
ZeroMQ and Protobuf C++ interfaces to expose services to the user
interface. Service discovery is done using QJDNS, also naively in
C++. The user interface itself is written using QML, Qt's declarative
user interface language, any imperative code is written in
JavaScript. One could use JavaScript frameworks such as Three.js inside
the UIs.

The idea is to have single client per platform. This client is built by
a build server:
http://buildbot.roessler.systems/files/machinekit-client/
The UIs are deployed remotely using the config service. So building new
user interfaces can be done without building a new client. This
effectively means one could also have more than one user interface per
application and more than one Machinekit configuration per host
computer.

A simple example:
https://github.com/strahlex/anddemo
Something more sophisticated for 3D printers:
https://github.com/strahlex/Machineface

The status of MachinekitClient in combination with Machineface is
production ready. It will be shipped with the first devices in the next
few weeks.

--
Alexander

[Jason Kridner]

Rockhopper doesn't look all that usable for controlling a mill.

I've been trying emcweb (comes up and says MiniEMC2), but I can't seem
to get it to even 'home'.

Anyone tried building GladeVCP using GTK-3's Broadway web interface?

On Thu, Aug 20, 2015 at 3:26 PM, Bob van der Linden
<bobvand...@gmail.com> wrote:
> Hi Jason,
>
> Together with another company I've worked on a 3D printer web gui that works
> with Machinekit on a BeagleBone Black. It is closed source, but I based it
> on the LinuxCNC/Machinekit Python API
> (http://linuxcnc.org/docs/html/common/python-interface.html). It wasn't
> really a direct connection from the webserver to the Machinekit API.
>
> I've also dabbled a bit with the Rockhopper webinterface, just to see how
> things work, but it was more of a debugging environment for me and others to
> work in from our laptops. Adding some buttons for us to do some tasks more
> easily: go to a few fixed positions to do calibration, tasks like that. It
> was all printer specific stuff.
>
> That said, like Michael mentioned, the Machinetalk API will become the
> standard for Machinekit. It'll allow applications running on the same system
> as well as remote systems to control and monitor Machinekit. I'm slowly
> starting with a client-side library in Python that makes use of the
> Machinetalk API. I hope to include most of the functionality that the
> original Python API has (state-changing, mode-changing, homing and sending
> mdi commands).
>
> Eventually I want to see a similar node.js interface, because that's what
> I'd like to use. Like Michael said, Python is used for now, partly because
> it was used in existing examples of Machinetalk communication, but also
> because protobuf's support for Python.
>
> The repository with the initial progress is here:
> https://github.com/bobvanderlinden/pymachinetalk-client
>
> This should make it much easier to implement a webinterface, based on a
> stable API.
>
> Greetings,
> Bob

[Bob van der Linden]

I've started work on a web interface. You can find it here: https://github.com/bobvanderlinden/node-machinetalk-example

Please consider it more as an example of what the underlying library (node-machinetalk) can do. It allows jogging, executing MDI commands and open/run programs.

Here is a screenshot of the current version:

https://dl.dropboxusercontent.com/u/183064/2015-10-29_234139.png

As you can see, very much work-in-progress.

Just like Alexander's clients, it makes use of Machinetalk. That means you have to configure Machinekit to use mkwrapper. In addition set REMOTE=1 in /etc/linuxcnc/machinekit.ini if you want to host the webserver on a different system (like your own PC).

It will discover the Machinekit instance using mdns, so (currently) you need to have Bonjour/Avahi running where the webserver is running.