Break signal for 3Dsurface

[Russ4262]

There are alternatives to modifying OCL source code.

OCL is not the only location for inserting code to cancel the operation.

Use a different perspective of the overall process for 3D Surface. 3D Surface is like a train. OCL is like the furnace when lit - it wants to consume all the fuel within.

One alternative to which I alluded above is to pre-process the data to be fed to the "OCL furnace," feeding only small "shovel loads of data," since this is the existing work flow anyhow, and checking for a cancel signal between "shovel loads."

One could use a combination of total model facets, (edit)sample interval, step down, and total length and count of line segments in the processing region to create a "shovel size" factor.

Existing models could be used to gather some baseline data for determining the to-be-hard-coded "shovel factor."

Another place to add such a signal-check interrupt is the post-OCL processing of point data into g-code.

Just my two bits worth.
Russell

[RatonLaveur]

What I like a lot with this proposition (BRILLIANT) is that by feeding small amounts of data, you may be able to get feedback from OCL for each shovel load, you can therefore estimate the time the whole process is going to take to calibrate your coffee maker or, alternatively, take the decision to stop.

It's akin to changing the spinning wheel of death into a windows progress bar

[freman]

That's great. I had the impression that it was just one big job thrown at one OCL call and that was why it was hard to break into.

If it can be done in shovel loads, then displaying a %age of how much has been shovelled in should be simple.

One thing that is annoying is never knowing where you are. Are you nearly there, 10min to wait or stuck in an infernal loop. It is much easier to wait for road work traffic lights when they display how long is left

[etrombly]

Along those lines I just did a test of throwing in a few status bar messages and FreeCADGui.updateGui(). It doesn't give you a percentage of progress like doing it in chunks would, and the gui is still unresponsive, unlike threading. But at least you get a little feedback on the progress and it doesn't seem like the GUI is totally locked up. You can grab https://github.com/etrombly/FreeCAD/blo ... Surface.py and https://github.com/etrombly/FreeCAD/blo ... Support.py if you want to try. Currently it just tells you when the operation starts, when it is doing the conversion to the opencamlib mesh, and when it is performaing the opencamlib scan, since those two steps are typically the longer ones.

[<Charlie_root>]

Wait, how did we get here ? Why are we using Python for generating CAM Paths anyway ?

I mean isn't it just a bunch of math that ends up creating a plaintext file ? shouldn't it be relativley easy to switch to C++ ?

< this may have been a very stupid question, in which case I apologise >

[etrombly]

Wait, how did we get here ? Why are we using Python for generating CAM Paths anyway ?

I mean isn't it just a bunch of math that ends up creating a plaintext file ? shouldn't it be relativley easy to switch to C++ ?

< this may have been a very stupid question, in which case I apologise >

The majority of the heavy lifting is done in C++, libarea does some of the shape and path processing, OpenCascade does the tessellation of the shape, and Opencamlib does the actual processing of the path (for 3D operations). We just use python to do some pre-processing and call in to those functions.

[<Charlie_root>]

The majority of the heavy lifting is done in C++

well let's just say that's a huge dissapointment ... I mean I always assumed it was slow because of python ... is CAM processing generally that slow ? like, even in non-floss software ? That can't be true

I mean howcome Slic3r can just eat through a huge complex model at 0.2mm layer height basically instantly ?

what if we ditch G2 interpolation and just use linear piecewise ? would that speed it up ?

[chrisb]

what if we ditch G2 interpolation and just use linear piecewise ? would that speed it up ?

As an option that would be ok, but please not in general. For one, I like to have Gcode that is as near as possible like handcoded; for two, old machines don't have the memory to hold lots of tiny straight lines.

[freman]

The majority of the heavy lifting is done in C++

well let's just say that's a huge dissapointment ... I mean I always assumed it was slow because of python ... is CAM processing generally that slow ? like, even in non-floss software ? That can't be true

I mean howcome Slic3r can just eat through a huge complex model at 0.2mm layer height basically instantly ?

what if we ditch G2 interpolation and just use linear piecewise ? would that speed it up ?

In reply to a model I posted which was having problems, etrombly has just made a couple of very simple changes which get rid of unneccessary loops. I suspect a lot of optimisation can be done. The 3D code is still pretty new.
https://forum.freecadweb.org/viewtopic. ... ad#p417068

Russ has done an amazing job adding a huge amount of functionality, the number of parameters makes 3D very flexible already and etrombly had been fixing bugs quicker than I can post them.

If the main task can be split into "shovel loads" as Russ suggested, maybe those can be run in parallel.

I'm equally suspicious of using a clunky, single thread, interpreted language like python for this kind of work. Maybe more can be moved to c++ with time.

[etrombly]

There are a few things that can still be done to speed it up. There are some steps that can be done in parallel, but I just did a quick check with mnesarco's threading module, and due to pythons GIL it doesn't actually speed anything up. Those sections would need to be ported to C++ (which would be a big task, it's a large chunk of the current python code).

Originally the meshing was done using brepmesh, it's currently done using part.tessellate. I can do some tests because it seems like tessellate is a little slower. I had added a much faster method, but it didn't create an accurate enough result. Maybe we can still use that for a preview pass, before generating the final operation.

Opencamlib is the slowest part. It's supposed to support multi threading, but I've noticed 3D surface seems to just be pegging 1 core most of the time. Maybe there are some improvements that can be made upstream. It might not be something that could be made parallel easily though.

edit: just looked around with opencamlib, the docker build I'm using doesn't turn on openmp (multithreading) support. I have a feeling this is true for most people. I turned it on and recompiled, but need to test more if it makes a difference.