some beginner questions

Hi,

I'm trying to get into axis, but its a lot harder than gscreen or qt ...

I read about disabling the generation of the overlay area, which I solved too.
What I did not find, is how to disable dro display at all.
I'd like something like in the dro-notebookpage, where each axis has its own dtg value, but in preview page, there's only one dtg value - pretty uncoordinated, which does not help me much.

Is there a way to disable dro display at all?
Or could I change the dtg display to match the look from the dro page?

I found the axis.tcl and axis.py, as well as glcanon - but I don't understand that much to do the changes on my own.

why not just set a general VAr and the glconon does not dislay or youdt you like to get it from the tab DRO

in glcannon the functions dro_format() and posstrs()
are the one to play with IIRC

For instance hal_gremlin overrides dro_format() for different dro behavior

Chris

Hi Chris,

I don't know yet, what's possible with python. Stil learning, stil at the very beginning ...
So sorry, if my question was too dumb for you!

I just try out, what's possible with linuxcnc on debian buster. Compiling git master succeeds without errors, but errors occur at runtime. Currenty axis is the only UI that works. But its very hard to get into it.
Anyway ... I like gtk and glade, so my target is getting an UI with gtk.

I tried your suggestion and changed dro_format - that worked for GL-tab - but on dro tab it removed the output too - unwanted

So I tried to understand more about glcanon ...

Did I get it right, that glcanon uses emcmodule from axis/extension as gl-core?
... and if so, gremlin from gscreen, that uses glcanon as base depends on emcmodule from axis too?

I read that boost from debian buster (1.67) now uses python version to build library names and for so enables support for python3 and python2 ...
To try that out, I started a build of linuxcnc withwhich seems to work.
It brings up errors for python3 migration like:
I tried to change the first line of gscreen to python3, which raised a lot of errors. Most of them where sourced by print statements without brackets ...
Then I read about "future" and tried it out.
It converted all print statements

Then I found out, that you where already working on python3 port?
At least there is a branch that feeds the idea ...
How far did you get with your tests?

I did do a fair amount of work converting Gladevcp to gtk3 but the problem was Gremlin the graphics display program. The library it uses didn't have a gtk3 version available at the time. I have not looked into it for a long time as I didn't have enough openGL programming experience to build a new version of Gremlin and got busy with Qtvacp. IIRC it worked ok but was missing some things - Xembed support, themes, graphics display and it didn't use the newest version of GLADE yet.

I have heard of people working on python3 support but no official conversation has gone on.

There is seldom a dumb question.
As you noted AXIS is very difficult to understand.
I modified glcannon enough to be able to have gscreen display what I wanted at the time.

Did I get it right, that glcanon uses emcmodule from axis/extension as gl-core?
... and if so, gremlin from gscreen, that uses glcanon as base depends on emcmodule from axis too?

glcannon does use the emc module to make a list of openGL commands that describes the gcode part visually.
I imagine it does it there because c++ is way faster.
glcannon then uses that list with other lists (eg origin mark, limits lines etc) and displays it as one scene.

Chris M

I imagine it does it there because c++ is way faster.

Well, that's obvious.

I think, if glcanon uses emcmodule from axis and gremlin uses glcanon, then emcmodule from axis is NOT an axis extension, but should belong to the core of linuxcnc.

To me it looks as if emcmodule from axis is what will be included by python scripts on "import linuxcnc".
.

Then I found out, that you where already working on python3 port?

I did do a fair amount of work converting Gladevcp to gtk3

I was talking about branch "python3_cython", where you participated

I think, if glcanon uses emcmodule from axis and gremlin uses glcanon, then emcmodule from axis is NOT an axis extension, but should belong to the core of linuxcnc.

It is a core python library that is true - it's python's interface to the motion controllers commands and status.
It's there for historic reasons; AXIS came first, then Gremlin then Gscreen. - So originally it was just a very useful AXIS library.

To me it looks as if emcmodule from axis is what will be included by python scripts on "import linuxcnc".

Yes you are right - the name changed again for historic reasons; When the project was forced to rename from emc2 to linuxcnc. I don't know why the choice to just change just the 'public' name, other then it was easier.

I was talking about branch "python3_cython", where you participated

Oh yes sorry.
I wanted to try out cython and it seemed useful to be able to easily make a python 2 or python 3 library.
If I made the effort to make an cython version of emcmodule, then I could have had a python 3 qtvcp running.
C++ is not my forte so I haven't got back to it.
I mentioned it to the guys working on python 3 work but they seemed uninterested - I assume they have a different work around.

Chris M

To me it looks as if emcmodule from axis is what will be included by python scripts on "import linuxcnc".

Yes you are right - the name changed again for historic reasons

Hm, I read about that.
Anyway - its not obvious to search in axis subdirectories for core functions.
Could you please shine me a light, where the name change happens?
From the "import linuxcnc" from python scripts I searched for linuxcnc.py or linuxcnc.h ...
... never thought, that emcmodule.cc from axis/extensions could contain the desired sources

How does gscreen and other non axis parts find that module?
.
And how does that all fit together at runtime?
I assume, that i.e. gscreen is a standalone process running inside a python interpreter instance. Does the interpreter load emcmodule.cc as shared object, or how should I imagine the core?
Most commands from emcmodule.cc result in a emcSendCommand(...) call.
Wouldn't it be easier to implement just that emcSendCommand as native Source and implement all wrappers as python code?
.

I mentioned it to the guys working on python 3 work but they seemed uninterested - I assume they have a different work around.

That implies that someone is working on python3 port.
I noted little to no rumors at forum on that issue - where does that development happen?

Anyway - its not obvious to search in axis subdirectories for core functions.
Could you please shine me a light, where the name change happens?

src/emc/usr_intf/axis/submakefile
directs the makefie to compile the code as a python module and puts it in lib/python
The lib/python directory is in the environment PYTHONPATH so python automatically searches for it there when loading modules.

Most commands from emcmodule.cc result in a emcSendCommand(...) call.
Wouldn't it be easier to implement just that emcSendCommand as native Source and implement all wrappers as python code?

That's above my pay grade
It would actual be nice to get rid of NML for something else but I don't see it happening soon.

That implies that someone is working on python3 port.
I noted little to no rumors at forum on that issue - where does that development happen?

As is common in the project advancements come from private work - there is almost no 'official' work.
IRC is the place to hang out for developers in general - most don't even read the forum.

Chris