Optimized gcode callbacks + improved rs274.gcode error reporting

[alex-scott]

rs274.gcode will try to get direct function call pointers of Canon object

it allows to implement optimized Canon base class in C/C++ that will
export some or all function pointers and handle traj points information
without going back and forth to Python code and double variable
conversion.

Results of this class (array of 3-d vertex lines + calculated extents)
can be used in Python code to draw trajectory.

To use this Canon class must have a method named "get_callbackp" that
will return dict of PyCapsule packed function pointers.

rs274.gcode module: improved error reporting

besides Python error, display Canon method that caused this

[andypugh]

This seems like quite a lot of work to do without apparentlly trying to discuss whether it was needed or not. Or was it dicussed on the Forum (which I am very behind on)

Can you explain why this is desirable?

[alex-scott]

This seems like quite a lot of work to do without apparentlly trying to discuss whether it was needed or not. Or was it dicussed on the Forum (which I am very behind on)

Can you explain why this is desirable?

I've started a topic in forum few days ago. https://forum.linuxcnc.org/38-general-linuxcnc-questions/53019-gremlin-rewrite-for-opengl-es-and-possible-optimization

In short, there is a known problem with Gremlin when handling big files. For example I have a sample file with 18 194 238 lines (~match number of traj points). It is real file really used by people. Currently preview is simply disabled for big files.

I checked gremlin source and the reason for this is is that it fills crazy big array with (partially) redundant information and traverse it in Python code at least 3 times. It will definitely kill PC of any power. It also anyway need access C++ code back (glvertex9) to cacluate vertex for each point.

So my intention is to rewrite this calculation part in C++ and use it as base class for GlCanon for effective points collection.

[alex-scott]

In short, the plan for entire rework is:

0. This merge.

1. Make that C++ python module that will collect points from rs274.gcode. While collecting, it will calculate extents and in same time convert {xyzabcuwv, offsets, rotation} to {opengl xyz, linetype, lineno} array buffers. That C++ module will also return pointers and length of these memory buffers up to Python code for use with opengl.

2. In python, we take these memory buffers and copy it to OpenGL ES GPU GL_ARRAY_BUFFER. That is in fact simply 1 function call (like memcpy CPU->GPU) and it is very fast. Another 1 gl function call draw all lines from this buffer. I've already have code for this, it works perfect, dots from the 500MB g-code file I mentioned above can be handled and displayed in few seconds. Line colors and scaling of all points can be effectively done on shader program level.

3. There is also an effective way to handle selection with mouse click without traversing all lines. It is enough to have vertex buffers I mentioned above. This part I have not tried yet, but I have plan for this too.

Only the slow point is interaction with rs274.gcode which I would like to get solved before go deep into it.

[andypugh]

OK. Sorry, I hadn't seen the discussion on the forum.

There was a suggestion on the forum to put this in a feature branch, which might be a way to handle it (as it feels like a fairly big thing to put into master as it stands)

I am not sure what the process would be for that now that we mainly work from pull requests on github rather than direct commits. If it helps I can create a separate branch for this in the LinuxCNC repository. The advantage of this would be that it would then get built into packages whenever a push is made. But that would require one of us to accept your pull requests to what is effectively your own branch. Which might be inefficient and onerous.

[alex-scott]

OK. Sorry, I hadn't seen the discussion on the forum.

There was a suggestion on the forum to put this in a feature branch, which might be a way to handle it (as it feels like a fairly big thing to put into master as it stands)

I am not sure what the process would be for that now that we mainly work from pull requests on github rather than direct commits. If it helps I can create a separate branch for this in the LinuxCNC repository. The advantage of this would be that it would then get built into packages whenever a push is made. But that would require one of us to accept your pull requests to what is effectively your own branch. Which might be inefficient and onerous.

I would appreciate this. Main question for me currently is if such change to gcode may be accepted atl all. All remaining staff can be made without big core code changes. So if answer for this pull request is "yes, it may be accepted if new gremlin code needs it", I will continue work on this feature.

When it is ready to go public, I will probably contact you to may be create a branch for those who interested. OK?

[hansu]

I also appreciate this change as there is no good workaround for big files. So let us know what is your working branch and let us know when you have something ready that we can test :)

[alex-scott]

I also appreciate this change as there is no good workaround for big files. So let us know what is your working branch and let us know when you have something ready that we can test :)

Thanks for your interest! I will write here once I get something more or less completed to show.

[c-morley]

Keep in mind the underlying code is used in AXIS and Qtvcp. Ie glcanon