status update

[Michael Haberler]

I thought I'd let you know what's going on, after some silence post the machinetalk merge.

Now that HAL is covered for remote operations, attention turns to the 'last frontier' ;) getting rid of NML in the task/interpreter/motion complex. The approach we chose is to use a 'shim layer' - a translation service mapping NML to protobuf/zeromq interactions so that development on the UI side can proceed in parallel with restructuring task.

That translation shim - currently called mkwrapper - technically is a demon talking to NML on the host side and protobuf/zmq on the client side. It is written in Python and will show up in the repo soonish; it is a temporary helper so we can define and stabilize the new API.

Also in the pipe is the way how preview is done - in the legacy code base, preview is generated by an RS274 interpreter resident in the UI, and bringing a ton of dependencies to the UI. Downstream preview graphics commands will be generated in the same place where task and interpreter run, and the UI is only responsible for interpreting and displaying those.

Alex is pretty far down the road with a Qt-based UI which handles both task/interpreter and preview type interactions based on the above ideas, but it's his turn to report the status on that.

I've been pondering for a while how to manage the rewrite of task/interpreter and some motion toplevel code. The approach Alex and myself settled for was internally fork task/interpreter/motion/iocontrol and go for a parallel development based on the new middleware. This means for the time being there will be NML-based variants, as well as protobuf/zeromq based variants in the repo, and the config files will determine which one is used. I think this gives us the freedom we need while rocking the boat as minimal as possible.

I'll shortly publish a spec for a modified embedding of interpreters (note plural) in task. This will address https://github.com/machinekit/machinekit/issues/106 - the basic idea is to have multiple interpreters with canon layers as needed (for machine control, as well as preview generation), and activate those as needed.

A key upside is the fact that interpreters will now be their own threads - meaning a running interpreter is now free to interact with a UI in any shape or form - something plainly impossible due to the (sorry, botched) control flow in the legacy code base. Also, various absurd contortions in task to support readahead and MDI will just go away. Switchable interpreters will also pave the way for MDI-while paused, which will build upon the current jog-while-paused code in motion.

A precursor for this effort is a merge pending by Alex, which adds mkwrapper and new protobuf definitions. None of this should affect or concern running code.


- Michael

ps: hoping to get over my author's block for the Machinetalk documentation soon ;)

[Schooner]

Great work Michael and Alex

On 24/09/14 11:02, Michael Haberler wrote:
> Switchable interpreters will also pave the way for MDI-while paused, which will build upon the current jog-while-paused code in motion.

This opens the road block to a lot of stuff that ought to be able to be
done.

The ability to execute code when motion is paused, will do away with the
need for a lot of convoluted remapping and simplify a lot more.

Run from line will hopefully then be able to look back through the code
, set to the last feed rate and spindle speed etc before re-commencing
the code.
Something some 1980s controllers have been able to do for ever, but
Linuxcnc never could!

Look forward to seeing it

regards

[Kent A. Reed]

On 09/24/2014 06:02 AM, Michael Haberler wrote:
> I thought I'd let you know what's going on, after some silence post the machinetalk merge.
>

Michael and Alex, you're rocking the house! (and that's a good thing if
you don't know the slang)

Besides your obvious high-quality technical work, your goal-setting and
planning are excellent. I see the use of a shim layer and of properly
managed variants as a variant of the surgeon's oath "First, do no harm."
Nice.

Regards,
Kent

[Alexander Rössler]

I have also not reported for some time now. Just the few posts showing some UI
thingy to keep the hope alive.

As Michael has already reported I worked the last one and a half months on
both mkwrapper and the UI counterpart. mkwrapper is just a simple wrapper
around NML with the utilities of Machinetalk. This gives us the time to
replace NML in the background and to make finally use of Machinetalk for more
than demo applications. Basically this enables the first time real remote UIs.

On the QtQuickVcp side I added a few new modules dedicated to mkwrapper a.k.a.
Machinekit.Application and to preview a.k.a. Machinekit.PathView. The first
one should be ready very soon, but documentation is still a rare thing.
Preview is basically working too, but still work in progress.

So what is missing:
- A few QML components dedicated to jogging, already in the demo UI, but not
in QtQuickVcp as well as merging the development branch into master.
- A name for the demo UI. As should be similar to Axis I thought about Allies,
but I am not sure.
- Lots of documentation.
- For Windows support of QtQuickVcp someone needs to tackle a nmake port of
the machinetalk-protobuf Makefile. This may bring some Mach3 users to
Machinekit.

Regards
Alexander

[thematsche]

On 2014-09-24 12:02, Michael Haberler wrote:
> Now that HAL is covered for remote operations, attention turns to the 'last frontier' ;) getting rid of NML in the task/interpreter/motion complex. The approach we chose is to use a 'shim layer' - a translation service mapping NML to protobuf/zeromq interactions so that development on the UI side can proceed in parallel with restructuring task.
>
> That translation shim - currently called mkwrapper - technically is a demon talking to NML on the host side and protobuf/zmq on the client side. It is written in Python and will show up in

Wow, the mountain comes to the prophet. :D


citation from http://sourceforge.net/p/emc/mailman/message/32044584/ :

"Especially as interim solution for the next stable branches in terms of a "nml to websocket bridge/gateway".
I think it's a easy task for jeff and/or axel. (I wasn't saying anything ;) "


Regards

[Michael Haberler]

That is in place, it's called webtalk - run the src/machinetalk/tutorial/motorctrl demo and connect to http://<ip>:4711/index.html to see it in action

However this needs work - do you think we could flatter you into contributing as well? (like, not saying anything ;-?)

-m

[Michael Haberler]

Am 24.09.2014 um 12:52 schrieb Schooner <schoo...@tiscali.co.uk>:

> Great work Michael and Alex
>
> On 24/09/14 11:02, Michael Haberler wrote:
>> Switchable interpreters will also pave the way for MDI-while paused, which will build upon the current jog-while-paused code in motion.

>

> Run from line will hopefully then be able to look back through the code , set to the last feed rate and spindle speed etc before re-commencing the code.
>
> Something some 1980s controllers have been able to do for ever, but Linuxcnc never could!

fulfilling that hope is mere work - you start with a spec please;) I have no idea what 1980's controllers were able to do.

Can you lay out what needs to be fixed in the current model?

Note that a variation on the interpreter flow doesnt magically improve it's capabilities to track source lines/context, or make it able to look back or step back. Same thing for 'going back a path' like for EDM.

-m