QT C++ graphics display WIDGET

Hi Reinhard,

That looks cool !! You are far in progress.

Hi there,

O my god, my python knowledge sucks. I was doing struct's for Python. But in the end i ended up with a QVariant.

Today i managed to send multiple values in one Python function to the C++ widget.And i managed to talk to c++ function from Python directly without using the Qproperty system.
This Python code piece :
is most interesting and sent to the c++ opencascade widget.
By the c++ widget the value is recieved by a QVariant :Where above the QVariant is converted back to a StringList, but can be a type float, int, etc.
You can also sent different types in the stringlist.
This code example is nice when we have to setup multiple user defined DRO textlabels at once, when program starts.

Attached the current C++ Python code archive.

Now we are ready to design the DRO setup.

Ok. Have a nice day !




 

The actual Python gui :
 

Extra info for interested Python users:
1. Example python commands by QtProperty system:2. Example python commands by direct function call :

This is fantastic headway!

As for DRO input (IMHO):
I dislike HAL pins for DRO - it forces users to connect pins for an operating DRO -which makes changing GUIs more difficult for users and integrators.

You will need to connect to NML somehow to keep current with linuxcnc's other status anuways.

This leads us to another big problem in GUI code: sharing information.
included in this problem is:
Linuxcnc's one reader consumed error messages,
python's GIL,
the sharing of non linuxcnc status information between GUIs (like jog rate)

It was always the wish to rip NML out and use something more suited but I don't see that happening (even machinekit didn't finish that AFAIK)
One stop gap might be to build a c/c++ 'distributor' that read and talks NML but also something else like ZMQ messages.

I bring this up because if you create a NML channel for the widget- don't read the error channel and maybe this is the time to discuss this problem again.
Maybe you guys have better ideas.

Chris

Hi Chris,

Thanks for the feedback.

1.
I will integrate a nml channel in the c++ widget, no problem, this channel is then activated by a Python bool function and will update
dro's, feedrate, spindlespeed.
This will poll, load and display the current loaded gcode file and user defined 3dtool from a stepfile. The tool then follows the xyz nml pos and
will react to a m3 and m5. At a m3 the toolflame is on. At m5 the toolflame is off. So user can define 2 drawings for the tool,
tool_on and tool_off.

2.
Also a Python bool function for setting up hal pins for the widget. This is used by hal-core for updating dro's
and can read and display "user defined data" when connected to a component. If user selects this mode they will proplably
have a faster graphics experience. I don't now how fast nml updates btw.

3.
*Maybe you guys have better ideas.

* It was always the wish to rip NML out and use something more suited but
* I don't see that happening (even machinekit didn't finish that AFAIK)
Hal-core is free of NML and Python.

I don't have further idea's at the moment, maybe Reinhard or Udo have some idea's, i don't know.

One thing i like about Python is that is doesn't have to be compiled.

I did a test with a routine between 2 c++ program's.
The program's had the task to compile each other in a endless loop.
The idea is to add data between the compile events with FANN (fast neural network lib) to create an AI.
But with python you don't need such events !



 


 

Linuxcnc's one reader consumed error messages,
python's GIL,
the sharing of non linuxcnc status information between GUIs (like jog rate)

Yes, error handling could be improved.

It was always the wish to rip NML out and use something more suited but I don't see that happening (even machinekit didn't finish that AFAIK)
One stop gap might be to build a c/c++ 'distributor' that read and talks NML

NML is not the problem.
backend has many problems - the biggest problem is code evolution, interpreter misuse and that changes have been integrated from guys that don't understand backend.

Cleanup of status area and fix status handling would be the right task. Actually tool handling is wrong (among many other things).

Building a nml-distrubutor is not an issue - I did that in my sample app - no component knows anything about nml without the statusreader itself. I think, we should first talk about the requirements of gui communication.
May be I'm not up to date - for me, linuxcnc is a machine control and for so, only one gui.

I will integrate a nml channel in the c++ widget,

That's the wrong way. Definitely!
NML is just a communication protocol between frontend and backend.
buffer duplication at backend is stupid and error handling could be improved, but NML is not the problem.
Many clients could send commands over nml to backend and read status. That works fine.
What does not work, is problem in the backend, like tool handling or wrong status updates ...
But those problems should be fixed in backend.

Current linuxcnc workflow is write a workaround for a buggy workaround which was a workaround for a workaround for a misunderstanding ...

linuxcnc has lot of problems, but I believe, that nml is the smallest of all.

I will integrate a nml channel in the c++ widget, ...

That's the wrong way. Definitely!

Don't take me wrong.

I am convinced that the most flexible and maintenance-friendly variant is the one that assigns as few tasks as possible to a module. That is the strength of Unix/Linux: do one thing, but do it right.

Look - in my prototype there are over 60 files, but if you want to change NML for another protocol, or change linuxcnc for another backend, you have to change exactly one file.

Apart from that - could you please upload your last state of the graphic widget?
I'd like to see whether I could help in making the dros configurable.

Hi Reinhard,

Current status :
Can display a gcode file. (worked on today)
Can load a 3d stepfile. (working on displaying a tool_on and tool_off file)

For the dro's please take a look in the runtest.py file
There is a beginning made how to setup universal dro labels wich are sent by a variable of type : QVariant. to the c++ widget.
This seems to work nice.

Archive :
we.tl/t-PtJmdPFQor

 

Hi Reinhard,

The archive including the python libraries :
we.tl/t-TCVvTHtmll

In the Qt_Occ_Python/src/cplusplus_testgui i tested the widget today. It's handy to use this.
I forgot to remove the .pro.user files. And if you change the opencascade widget code, i did a "sudo make install" after it.

* you have to change exactly one file.
This sounds like c++ coding style !

In the Python code, nml is already available. And from there the Graphics Widget can be updated.
Sounds logic?

 

Hi Grotius,

Can display a gcode file. (worked on today)

its a really nice parser you used, but I'm quite sure, that it does not work identically to the linuxcnc interpreter. So better use linuxcnc interpreter to get reliable results (in the sense, that the grafical widget displays, what the backend tries to work out).

In the Python code, nml is already available.

Ok, I only referred to you proposal to add nml functionality to the grafical widget.

cheers