Yesterday I ran the auto-leveler and clicked the "send auto-leveled data to workspace" button.

Yesterday I ran the auto-leveler and clicked the “send auto-leveled data to workspace” button. It seemed like it did do that but after starting the milling I noticed that the actual job being milled was the previous one I had loaded, a very different job than the one I prepared!!!
In other words, the 3d viewer was showing my new job but the machine was milling the previous job, because that’s what the gcode widget contained…
Also worth noting, I tried to drag’n’drop new gcode in chilipeppr and it didn’t work. No message to let me know what was wrong, it just didn’t do anything after dropping the file.
After taking a breath (and some swearing in the meantime), I tried to find out what was wrong. Opening the javascript console revealed a single error line with the following text in it:

“Uncaught QuotaExceededError: Failed to execute ‘setItem’ on ‘Storage’: Setting the value of ‘last-imported’ exceeded the quota.”

Me not being a web developer this didn’t make much sense but it was clearly pointing to a (the?) problem.
Anyway, to cut this short, after some fiddling around with the browser settings (Chrome, btw) I found a place in the settings where I could delete the local storage for and, after doing that, everything started working correctly again :slight_smile:

Still, shouldn’t this error be caught by chilipeppr and, at least, let the user know, if not being able to circumvent it by itself (e.g. by requesting more storage or freeing some up by removing old stuff)?

I have seen this issue before when upon finishing a run, a drag and drop will update the 3d viewer but the gcode widget will not update. Ever since I have been careful to refresh the app every time I finish a job. Just a normal f5 will do.

Tried F5, Ctrl-F5, Ctrl-R. Nothing worked until I deleted the local storage.
I haven’t tried it though after finishing a job, I don’t know if that matters.

I have also experienced the same thing but did not check the logs as I was to busy swearing of my ruined MDF stock :slight_smile:
This file:
…seems to cause the problem both in Chrome and Firefox.
Sometimes the 3D viewer updates and the Gcode not but most of the time nothing happens as I drag it into the view.
When I Copy the code into the Gcode widget it will run but the 3D view is all blank.

Ok, I hate hearing that somebody ruined some perfectly good stock because of the software. That pains me greatly. This problem you guys are seeing is due to that “Quota Exceeded Error”. The browser only allows 5MB of files to be saved per domain. I think what’s happening is that error is hitting and the subsequent code that actually creates the backing array of data then never gets created.

What I could do ask the quick fix is wipe the backing data arrays to set them empty before writing the file to localstorage. Then at least you’ll see emptiness in your Gcode widget and know something went wrong.

Long term asking the user if they want to remove enough files to make room for the new one is the way to go, but that is tough as well since you may need those old files and there’s no export built yet except the macro you can run manually, which should turn into an official button.

On the positive side, I ran some acrylic milling jobs this weekend and ChiliPeppr worked like a champ.

Hi John, I have plenty of MDF so that’s no problem :slight_smile:
Usually I do air cut’s but Chillipeppr actually have been working so good that I got lazy :slight_smile:

My Firefox seems to have problems with Chillipeppr after the last update a week ago. (Firefox update) Prior to this update the only problems was the flickering when using tool head shadows and some trouble with the webcam.
Now it seems to have lost it totally as most of my Gcode is impossible to load.
Embarrassing enough I can’t find how or where to reset the “quota” in the settings…

Anyway… this made me test Chrome and it just works 100% even my webcam issues are gone!
So I might go lazy again :slight_smile:

How many lines do you typically have in your gcode? I’m getting worried that somebody will overflow the 25000 line buffer that spjs has right now. I need to add code in chilipeppr that watches the high level buffer and waits. Love hearing that chilipeppr is working so well you’re getting lazy. I too run air cuts to test but have been skipping because it’s so reliable. I will also add that writing spjs in golang is really paying off.spjs is super fast.

The one that i linked is 11224 lines and I’ve sucessfully done one with 20564 lines. I think the limit of 25000 might be a problem for a complex part with toolchanges and several operations.

The code was posted this weekend that closed out this bug. So shouldn’t be a problem anymore.