Done using two overlapping g code files so Chilipeppr did not barf. Seems to work pretty wel and is good enough to move to a rotational axis relief test.
Good technique
Any idea where in Chilipeppr the size limitation for g-code actually is? Does it try to read the entire g-code file into memory instead of memory-mapping it?
It reads the file and generates a line for the 3D viewer for each line of Gcode. It’s the 3D viewer that loads up.
And the 3D viewer is not a separate thread from the rest of the UI? Even if it saturates one core, everything should still react smoothly.
I recall that multiple widgets also hang on to the entire gcode too. For example the eagle widget stores the gcode internally and in the text area and then sends the text area to the gcode widget, which stores the code as a var and in the display (albeit formatted so a derived copy rather than direct).
Iirc the viewer widget also stores the gcode and its own rendering.
I’m sure we could optimise the gcode storage somewhere.
That sounds like a “my first program” excercise and not like scalable programming of anyone knowing memory mapped files, asyncronous IO and ByteBuffers.
None of that is the memory issue encountered. It’s just the 3D viewer that croaks. Storing a 20MB array is no problem for Javascript or the browser. Even storing it twice is no issue. It’s the 3D viewer with buffer geometry lines that overflows.
Are you sure @jlauer ? @Steve_Anken has said in another post that he reaches memory issues even with the 3D viewer turned off.
Because the 3D viewer turned off just means we turn off refresh to 0 fps. We still render the lines in the 3D viewer.
Ah. Ok.
So for @Steve_Anken and others like him we could perhaps create a very rough view from the gcode. Perhaps only rendering one in every xx g0/g1 lines. Or otherwise provide a switch that completely disables the rendering and the viewer.
Yes, Turning it off or even using http://chilipeppr.com/dchote does not change it at all. Very easy to replicate, Z moves are killer and I cannot do large piece with Chilipeppr because the larger the z the slammer the x and y but I am having problems at 50x50mm so forget about doing a full 4’x8’ panel. It amazes me that this is a problem in 2017, it really makes no sense. We did 100mb files on DOS with 640k memory using a swap file, and it was faster with a processor that was orders of magnitude slower. What the hell happened to go backwards like this?
You could try creating a new workspace where you fork the TinyG workspace like dchote did, but you don’t instantiate the 3D viewer at all so that it doesn’t render the Gcode. That could possibly solve your file size memory problem.
@Justin_Adie I agree another idea is to only render every Nth Gcode line so you get sort of a partial visualization.
@jlauer regarding rendering the lines in the 3D viewer, the disable option in the setting for the 3D viewer widget says “no cpu usage”. Based on what you say, it DOES use clock cycles to do the render, which is memory intensive enough to crash the browser…
I’m a little concerned about this as my intention is ultimately to be doing things in a very similar vein to @Steve_Anken . I appreciate there is a (fiddly) workaround, but this does seem like a pretty retro problem…
Remember, this is open source software so it’s made up of it’s community of contributors and users. For many users their Gcode files are 5MB or under. For folks who have larger files, that is a different use case, thus it will take some volunteers to help get the app there.
A fair point. Would that I had the skills to assist.
Sadly, the best I can do, most likely, is find some way to break it…
If i have a spare hour over the weekend i will have a look at tuning the renderer a little. From recollection it may not be a straightforward fix.
It might be better to attempt making a copy of the tinyg workspace and just not instantiating the 3D viewer.
Perhaps. I was looking at the “roughing” up solution though. Giving up on the viewer would seem a shame.