Hey all, Ran a roughing job, did great. Went to load the finishing job, gcode loads: [ GCODE Parser ] GCODE File Loaded Go to run the jobL [ websocket ] Disconnected. OpenBuilds CONTROL probably quit or crashed Is there a size limit? Mine is a large file, 118MB, 4.6million lines I believe. Is this beyond the capabilities of tis software? Have had many smaller jobs go great, largest prior was some 2.1million lines of gcode. Any help would be greatly appreciated... got a beautiful piece of walnut that needs finishing lol. Thanks!
Hmmm. Have you tried disabling the simulation? That may help and honestly dont have experience with that large of file. Its worth a shot. Troubleshooting -> Application Diagnostics -> Disable 3d Viewer If you can, try doing the cutting in finishing in multiple files. If you are doing multiple passes to reach a certain depth, it should be easy to post out to separate files. If not, you'll have to separate in to sections.
I should have included more info, i did indeed disable 3d viewing, but that did not help. Tried on control version 1.0.252 and 1.0.270. And split into multiple files... definitely not what i wanted to hear, but can be done.
I did a search and other had issues with files 30MB in size. Obviously it will have a lot to do with the machine its running on. Peter should be awake soon. He'll probably have some better advice if there's any.
Good morning - awake but no coffee yet. Disable 3D viewer from Troubleshooting tab. The 3D view uses most memory, as it renders the segments, simulation data, and even time/checksize calculations. With 3D viewer disabled only the gcode file itself (118mb) is in RAM. When you click play its sent to the backend (another 118mb) - so not a lot at all. Try after a fresh reboot, with 3D viewer disabled, before loading a file.
Hey Peter! I did disable the 3D viewer.... but I did not think to restart the app (DOH!)! I got impatient, sliced and diced the GCODE into 3 separate files and its running now, looking beautiful! But.. as far as you aware, 118MB/sub 5mil lines should be fine? I will do another test in a few days when this finishing job is done. Trying to upload the code.... keeps failing? Like email, is there an upload size limit?
Put it in a Dropbox/google drive/etc I am optimising the 3D viewer code a little, so do add your file to the testing pile
https://drive.google.com/file/d/1nKeeLAcOf1FhI3JRAlMMycUGbcvUcvzT/view?usp=sharing Thanks Peter. Will report back later when I test again.
The in progress changes to the 3D viewer looks great Parsed your big file, rendered preview, only using 715MB of Heap space - was closer to 4GB before the changes to the code. I figured out your error message's cause - wasn't 3D view related after all Code: [20:57:22] [ websocket ] Disconnected. OpenBuilds CONTROL probably quit or crashed We can't send that much data between the frontend and backend in a single call - it takes too long, the Websocket server times out. So let me wrap up the 3D viewer changes (affects the simulator - got to catch it up to the new smaller data structures of the new lighter 3D view) and then I'll work on the transfer issue
Fixed, you can download the beta of v1.0.272 from: AppVeyor Note, beta, report any funny business please - there were quite a lot of changes (more changes = more chances to make mistakes) If you want to roll back, official releases are here Releases · OpenBuilds/OpenBuilds-CONTROL - New 3D viewer: More lightweight smaller memory footprint, maybe renders a little faster, supports larger files, shows Progress percentage while rendering, smoother anti-aliased graphics looks better - Simulator changed to work with new 3D viewer data - Prevent large files from loading to Gcode Editor (gcode editor uses a lot more ram than we thought, now files >20mb is not loaded into the editor) - new RunJob method for large files (http post instead of websocket)
The rendering, please wait message is a nice touch. It did say 100% for awhile before it actually loaded so I thought it may have crashed (chris' file). But it loaded fine and looks awesome. Chris, that carve is going to be awesome!
True, after generating the geometry there is a bit of a delay as we pull the data out of the webworker, and into the DOM. I'll see if I can make it account for that It's a pleasure, your slightly unique error message, found a cool bug - it's exciting to fix things like that!
Have done some testing.. and I am not finding any issues with build 272 on windows. Can this get pushed to mac/linux? Thanks again!
Soon! Just doing a little cleanup and testing before we take it out of BETA and actually release it as v1.0.273 I am leave tomorrow, so hoping to get it out before end of the day