search

machinekit / machinekit-cnc

CNC stack split out into a separate package
Other
60 stars 37 forks source link

GCode preview speed/data size/quality too slow #11

Open ArcEye opened 6 years ago

ArcEye commented 6 years ago

Issue by machinekoder Wed Apr 16 10:03:08 2014 Originally opened as https://github.com/machinekit/machinekit/issues/134

The speed of the currency available GCode previews is insufficient for files generated by tools like Slic3r for 3D printing. A small object can result in a very big GCode file (80.000+ lines) due to layer height of 50 microns or smaller. This results in a very slow preview loading process and unclear preview output (many line resulting in a big white blob).

Even when deactivating the preview the interpreter seems to somehow process the GCode file for preview. The slow preview window may also cause slow exution performance due to the lack of powerful graphics hardware on most embedded platforms.

ArcEye commented 6 years ago

Comment by cdsteinkuehler Wed Apr 16 11:34:21 2014

This has bothered me for some time, and the preview window is generally useless for 3D printing even on x86 machines (there is just too much going on with a typically complex 3D print to make much of the preview image). I would like to have an option to totally disable the preview window, and ideally to do something like a 2D layer preview as used for instance on pronterface: https://github.com/kliment/Printrun/blob/master/screenshots/pronterface2.png

ArcEye commented 6 years ago

Comment by micges Wed Apr 16 20:19:26 2014

There was quite big speed up of processing gcode between lcnc 2.4 and 2.5 but still part of preview code is in python. Also deactivating preview only don't draw it on opengl window.

ArcEye commented 6 years ago

Comment by mhaberler Wed Apr 16 20:21:35 2014

Ah - of course; that's what Alex saw: the interpreter in the UI still runs, the callbacks just dont do GL painting.

ArcEye commented 6 years ago

Comment by mhaberler Wed Apr 16 20:55:32 2014

Alex and me worked on the issue yesterday, and since this relates to the Interpreter API I added notes over here: https://github.com/machinekit/machinekit/issues/106#issuecomment-40650556

this lays out some options how to deal with the performance issue, and in step 1 of the migration will provide a testbed for improvements and validation.

See the notes link there for details.

ArcEye commented 6 years ago

Comment by mhaberler Tue Apr 22 20:05:42 2014

we now have a preview module (derived from the rs274.gcode module) which produces preview command encoded in protobuf, and delivered via zeromq. for testing/performance estimates only. needs to be redone properly when reworking canon.

this enables Alex to get some lines into the QtQucikVcp preview control.

ArcEye commented 6 years ago

Comment by gmoccapy Fri May 2 14:57:14 2014

I just tested around with my BBB. I installed the following image debian-7.3-machinekit-armhf-2013-12-28.tar.xz, as it is very old, I pulled machinekit and build it on the BBB (took very long ;-) After solving some depency problems, I was able to run some simulations.

IMHO non of the GUI's can be used to operate a system based on the BBB. The BBB is so slow, that you must click and than wait for a reaction.

I realy doubt that we will be able to run a GUI on that platform, even if we change any code to C++ or what ever. IMHO the GUI must be on an other device and the BBB is just a controler.

Alex, will QTQuick Vcp be fatsre than glade and python? I ask, because of my 3D Printer GUI plans. At the moment I do beleave it don#t worse the time to think about it, till the "remote zeromq" stuff is completely embedded.

Norbert

ArcEye commented 6 years ago

Comment by mhaberler Sat May 3 07:09:00 2014

please read https://github.com/mhaberler/asciidoc-sandbox/wiki/interpreter-API---meeting-notes-20140415 . Running remote will certainly not make things faster per se. What we can do is make preview brighter.

As for the BB as a graphics platform - there are reserves: once the kernel supports hardware OpenGL things might improve a bit.

As for the preview process per se: that is usually fine for hand-written gcode programs with limited complexity. Once you get into CAM output like from Slicr, that picture changes: the preview process scales rather badly here.

So I dont think throwing hardware at the problem is a helpful approach. It might help to think outside the box for 'preview next generation' to pare down the complexity. Some thoughts are outlined in the above link.

ArcEye commented 6 years ago

Comment by gmoccapy Sat May 3 10:33:51 2014

Hallo Michael,

I did read the mentioned notes. If I do understand correct, the preview will still be generated on the "host", not the remote system, and only displayed there. Independent of the preview code you will use.

My idea is different. The complete preview and GUI stuff is done on the remote system, only the controlled motor movement is done on the Host, in this case the BBB. It should be done like controlling a plotter or a printer, ones the code has been generated, I just say "send to machine", and the machine will start the work. As the machine knows the code length, it will return in a adjustable time the advantage, so the GUI can sync with that.

So just giving a command from the GUI "Jog x positive" should lead in a direct movement without the actual delay.

I do not know if that will ever be possible.

I agree, that BBB will work faster once in support hardware GL, but I am sure it will never be able to replace a ATOM ITX Board or similar.

I am just finishing my 3D printer, so within a near future I will be able to make the first tests. I am going to get as much information from Alex stuff as possible and will try to base the new GUI on QT-Quick.

Norbert

ArcEye commented 6 years ago

Comment by mhaberler Sat May 3 19:29:24 2014

here are some ideas:

specific to OpenSCAD/slicr: instead of using the insane tool path as preview, use the OpenSCAD solids proper. Find a way to pass through the OpenSCAD solids; or use OpenSCAD per se as a progress display vehicle by making it monitor x/y/z from machinekit.

reduce number of layers displayed: modifiy slicer to output say a custom M-code when a new layer is started. Modifiy interpreter/preview to understand that M-code, plus add another M-code which essentially says 'only display every N-th layer' in the preview. performance effect: huge.

3d-printer independent: partial preview - like only display the next 30 seconds of 'cutting'.

Any combination of the above.

ArcEye commented 6 years ago

Comment by cdsteinkuehler Sat May 3 22:32:43 2014

On 5/3/2014 2:29 PM, Michael Haberler wrote:

here are some ideas:

You left out: "Bounding Box", as used on old-school 3D programs. I think this could work well when combined with:

3d-printer independent: partial preview - like only display the next 30 seconds of 'cutting'.

...or perhaps the next 'X' lines of gcode, with X tuned to the system performance.

Charles Steinkuehler charles@steinkuehler.net

ArcEye commented 6 years ago

Comment by mhaberler Wed Jul 30 02:06:15 2014

I did some ballpark figures of raw interpreter speed, i.e. without canon/preview overhead (see the nullcanon layer commit in machinekit-preview-2):

jallwine commented 4 years ago

Has there been any progress on this issue? At Pocket NC we're interested in previewing G code from MachineKit as well. We've developed a standalone WebGL-based G code simulator with a rudimentary interpreter (it can handle most basic 5 axis G code generated by Fusion 360). It can handle very large files, too. We've tested it with G code programs that are well over a million lines (it might take a few minutes to parse and plot, but it does so without locking up the interface, and all on the front end). We'd like to tie in to the actual MachineKit interpreter and feed the output over time to the simulator without locking up the Beaglebone while doing so. It would be great to be in control of some kind of preview object that could interpret a chunk of G code at a time rather than parsing a whole file at once, so we could be in control of throttling the output.

I read through the notes posted back in 2014 and there were a few mentions of the technologies we're using. We forked Rockhopper and have made improvements over the years. The Beaglebone only runs as a controller and a web front end communicates with Rockhopper over WebSockets using JSON messages. Like I said before, we're looking into integrating our web simulator with Rockhopper in such a way to leverage MachineKit's full blown interpreter rather than the partial implementation we have now.

Any info that could point me in a direction would be appreciated!

cerna commented 4 years ago

@jallwine,

Has there been any progress on this issue?

Unfortunately not. As far as I know, the most work done on the original Machinekit was in the HAL theatre and the CNC part was always lacking behind. Given the shortage of manpower willing to adopt and develop new functionality for Machinekit-CNC, new endeavour was created which allowed to run the maintained Enhanced Motion Controller from LinuxCNC atop the Machinekit-HAL. It is called EMCApplication. (I haven't yet looked at what it would mean for QtQuickVcp.)

But as there were changes to Machinekit-HAL to allow the adoption of the EMCApplication, currently Machinekit-CNC@master cannot be build on Machinekit-HAL@master. I started working on porting Machinekit-HAL to CMake - machinekit/machinekit-hal#200 (it was discussed many times in Machinekit annals and I think it is a high time to finist it), so with help of exported targets I hope that the Machinekit-CNC will be buildable against Machinekit-HAL again. However, that is only repair of what is currently broken.

(It probably isn't what you wanted to hear. Sorry. Problem is, most people, myself included, were/are interested in the HAL part.)

jallwine commented 4 years ago

I’ve been keeping my eye on EMCApplication. I like the idea of using LinuxCNC’s improvements to the CNC side of things along with MachineKit’s improvements to the HAL side of things. I appreciate your efforts, Cern! As always, thanks for the info and for all the work you put into this project. I’ll do my best to help where I am able as I look more into this.