search

vlachoudis / bCNC

GRBL CNC command sender, autoleveler and g-code editor
GNU General Public License v2.0
1.57k stars 533 forks source link

[Feature request] Better support visualisation of large gcode files. #631

Open hb020 opened 7 years ago

hb020 commented 7 years ago

When using anything larger than a thousand G code statements, bCNC becomes extremely sluggish (on my MBP, no this is not on RPi). When switching off "display of paths (G1,G2,G3)", suddenly it becomes responsive again. Also there are no longer sudden long lags while milling. As most of my mills are way above 1000 statements, I have to switch that off all the time and I am missing a lot of functionality.

This might be solved for example by making CNCCanvas.drawPaths() run in separate thread, although I do not quite know if that would break a lot of things.

vlachoudis commented 7 years ago

Its already the case but in reverse. Since Tkinter is not compiled with multi-thread support in many OS is not possible to have any drawing operation in a background thread. Thus all drawing operations are performed on the master thread, and all I/O operations are performed in a background thread. Up to now I have never experienced any lags during milling, even on huge G-code files. On which OS do you run?

hb020 commented 7 years ago

I am running bCNC on latest OSX, the OS standard python. So I tested on other environments:

Still, the time needed for drawing is long. A 'small" 900kb gcode file takes 6 seconds to redraw on OSX, during which time the UI is non responsive. The lags during milling have happened to me several times (and when milling plastics that is a sure fire way to thrash the work). Will test from ubuntu. Also, with drawing disabled, I have not experienced those lags. I know I can set the timeout in the GUI, but then I get incomplete displays, which is misleading. I understand that with single threaded tk, things are difficult. There are several options though.

vlachoudis commented 7 years ago

Just to clarify, the milling runs on its own thread, so it is not affected at all by the drawing operations. There were some lags during some display operations (#632). I've "fixed" it by adding forced periodic updates to Tk. Try the new commit and let me know your comments.

hb020 commented 7 years ago

well, that didn't go well for OSX and native python: the display hangs. On Ubuntu and OSX brew python it all seems to work great, and I do not have the startup delay mentioned in 632.

vlachoudis commented 7 years ago

Can you send me your example of large g-code, so I can check directly on that.

hb020 commented 7 years ago

my example: (rename to .ngc) Counter-F.Cu.txt

vlachoudis commented 7 years ago

Unfortunately I cannot test on OSX. On Ubuntu that I have it works ok.

vlachoudis commented 7 years ago

Can you check what #613 did maybe it helps?

rfsouzax commented 7 years ago

Hello, I'm also experiencing the same problem when I use very large codes, I wonder if it would be possible to increase the loading time to render my file, here is the message: "RENDERING TAKES TOO LONG ... INTERRUPTED ...". Any idea how we can fix this? Thank you! fail_render_bcnc

I'm using Windows 10

lalo-uy commented 7 years ago

There is a parameter for that set to 5 sec by default. Enlarge it

2017-09-29 9:18 GMT-03:00 rfsouzax notifications@github.com:

Hello, I'm also experiencing the same problem when I use very large codes, I wonder if it would be possible to increase the loading time to render my file, here is the message: "RENDERING TAKES TOO LONG ... INTERRUPTED ...". Any idea how we can fix this? Thank you! [image: fail_render_bcnc] https://user-images.githubusercontent.com/17283251/31015542-14156e60-a4f7-11e7-8348-079d78c5f1d7.jpg

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/vlachoudis/bCNC/issues/631#issuecomment-333111024, or mute the thread https://github.com/notifications/unsubscribe-auth/AK4bcXRItQeE2SDl3ZJ1M4xHD7tIeCIyks5snOAFgaJpZM4OuHKb .