Break signal for 3Dsurface

Here's the place for discussion related to CAM/CNC and the development of the Path module.
User avatar
freman
Posts: 1173
Joined: Tue Nov 27, 2018 10:30 pm

Break signal for 3Dsurface

Postby freman » Sun Jul 05, 2020 8:17 am

Hi,

3Dsurface ops can get very long to calculate. Sometimes just adding one more face or extra option can turn a manageable 30s to 1min run into and indefinite hourglass, seemingly locking up FC. ( I don't know if it is really in an indefinite loop but suspect so. )

When this gets to be unreasonably long we need a better way to breaking in than "kill FreeCAD" to kill the process and restart from a crashed state.

Could we have polling of mouse and key pad at some suitably low level to trap Esc-key , Cntl-C or something similar to provide a break out in an orderly fashion.

TIA.
User avatar
sliptonic
Posts: 1834
Joined: Tue Oct 25, 2011 10:46 pm
Contact:

Re: Break signal for 3Dsurface

Postby sliptonic » Sun Jul 05, 2020 2:53 pm

I believe we're limited to what opencamlib can do. I'm not aware of a way to break a recompute once opencamlib has been called.
User avatar
freman
Posts: 1173
Joined: Tue Nov 27, 2018 10:30 pm

Re: Break signal for 3Dsurface

Postby freman » Sun Jul 05, 2020 3:17 pm

Thanks for the probable explanation.

OCL is OSS now so it remains possible to dig in a put a hook. Maybe the number of C fluent folks here limits that.

Maybe if that call was done as a separate thread from FC, there could be a watchdog in the main thread with the option to kill it.
User avatar
<Charlie_root>
Posts: 36
Joined: Mon Aug 12, 2019 8:01 pm
Contact:

Re: Break signal for 3Dsurface

Postby <Charlie_root> » Thu Jul 16, 2020 9:44 pm

I think we need this for every operation

I was doing an adaptive clearing face for a rather complex model of a small PCB and with a 0.5mm mill and 75%steopver with the A/P slider cranked all the way to the right it succesfully generated the toolpath for the entire face in about 6 minutes or so ... then it just halted completley after it was done.

you know how you can still move around the viewport while an adaptive is generating and you can also stop it with the [STOP] button at the bottom (also fun fact if you click the cancel at the top while it's generating it will delete the adaptive operation but it will keep generating anyway lol :))))))))

but after the path itself is done ... as it gets "converted from blue to green" during that phase it's completley impossible to stop and I like left it there for 30 minutes and nothing happened so it's pretty safe to say it halted (i'm using a ROG Strix G).

also fun fact if I try to do a pocket face on it it halts immediatley after I press the button.
RETRIBUTION IS AT HAND
User avatar
freman
Posts: 1173
Joined: Tue Nov 27, 2018 10:30 pm

Re: Break signal for 3Dsurface

Postby freman » Thu Jul 16, 2020 11:19 pm

Yes, after some basic experimenting with adaptive, I gave up on it for those reasons.

All these computationally heavy paths need a kill button of some kind. All we have right now is killing FC process itself.
etrombly
Posts: 135
Joined: Thu Dec 05, 2019 6:50 pm

Re: Break signal for 3Dsurface

Postby etrombly » Thu Jul 16, 2020 11:23 pm

I was hoping mnesarco would do a PR for his threading module https://forum.freecadweb.org/viewtopic. ... 38#p395238 and we could use that. Should allow us to launch background tasks that you can cancel. Would need to figure out how to lock objects that are being worked on though, may end up with some weird bugs otherwise.
User avatar
freman
Posts: 1173
Joined: Tue Nov 27, 2018 10:30 pm

Re: Break signal for 3Dsurface

Postby freman » Fri Jul 17, 2020 6:54 am

Ah yes, python is a thread challenged language. You need a separate instance of python for each thread.

mnesarco's repo may provide a solution but sadly the link in that thread is broken. Do you know where that file is now?
schnebeck
Posts: 127
Joined: Thu Jun 22, 2017 8:04 pm

Re: Break signal for 3Dsurface

Postby schnebeck » Fri Jul 17, 2020 8:38 am

etrombly
Posts: 135
Joined: Thu Dec 05, 2019 6:50 pm

Re: Break signal for 3Dsurface

Postby etrombly » Fri Jul 17, 2020 11:21 am

I would probably modify it to use the global thread pool so it would be a little easier to interoperate with c++ code. Need to test though to see if that would even work, all the examples I can find are either purely python or purely c++. I haven't found any examples that mix the two with the same threadpool.

The main problem I see is with locking objects. I can't find any built in way to do this. Say you kick off a background 3D surface task, then part way through adjust the placement of your model. It's going to end up giving you invalid results. Same thing if you edit the operation properties (This might be easier to solve by keeping track of running jobs and not recomputing, or cancelling the current job and kicking off a new one). The only built in way I can think of is hiding the model and stock, but then the user could always just unhide it.
User avatar
freman
Posts: 1173
Joined: Tue Nov 27, 2018 10:30 pm

Re: Break signal for 3Dsurface

Postby freman » Fri Jul 17, 2020 2:48 pm

I think the way to do it would be to lock the main thread which will end up inoperative while the calculation is going on. ( As you say you can't do much at the same time unless you open another model and start working on that). Start the calculation as a separte thread and use a mutex to block the main thread while it's running.

What could then be done is spawn another watchdog thread which maintains an active dialogue box on the screen with a cancel button. This thread is closed once the operation is finished or cancelled.

That was the basic requirement here.