A Story About the GFUI


#1

Ive been putting a lot of laser projects off lately because Ive been waiting on my GF Pro. However, I have a convention this weekend that I have to display at, so it’s time to make some new stuff to show/restock sellables. In my absence Ive found that a lot of things have changed in the software. Some for the better, and some for worse. Raster print size has gone down dramatically, thats no fun, so most of my pieces now are about half the size they used to be. Im optimistic theyll fix the size thing eventually.

Tonight I was working on a semi-intricate map that was going to be in multiple pieces. I put everything into a single file, all my layers are separated properly. I did a test run. Everything seemed to be ok. I had one sliver of proofgrade left to do the final piece. Everything went swimmingly until the last cut. It didnt go through, at all. For me this is pretty normal, its a PRU blah blah.

Well the problem is the UI is frozen. I can barely or never, ever fix these bad cuts. Its getting to be a real struggle. 4 pieces today I had to take to my table saw to cut them cleanly out where they should be (thank god most are square), and then sand the side down smooth and color it with a sharpie to match the other sides. Not fun.

So I havent removed the piece from the bed yet. The failure occurred when I hit print in the UI, and the app is stuck on “Uploading”. I initially had to move the design around a little to get it right on the piece of proofgrade (because the optical alignment is off a bit), which means I cant leave the page or it will lose position. If I lose position, its never going to cut properly to fit the other pieces.

You can see by this screenshot that it says ‘uploading/scanning your material’. I cant cancel. I cant restart it. Im trying to look for a tricky way to get back to being able to print this properly without closing the window and having to start from scratch. AGAIN.

Now I can see the position here in the redux state, but the plugin crashes notoriously, so keeping it open is running a huge risk, as it would take the browser window with it if it crashed. If I cant find another way around this, ill have to open it though, to make sure I get back to the exact right position.

To get to the point, I shouldnt have to be doing all of this to try to salvage a cut that didnt go all the way through. The UI should account for these things. The first and easiest would be numeric positioning. I shouldnt have to be pulling out my tablesaw at 4AM to try to fake “laser cut edges” because Im not allowed to type numbers into the UI for some reason, or go into the dev tools to pull a value from state to try to recreate and praying the app doesnt crash.

I know it has been asked a lot of times. Im asking again. Please, please, add numeric readouts/entry for positioning/rotation/scaling to the UI.


#2

P.S. Moved this to ‘everything else’ in hopes of a conversation without thread locking.

I was also able to find a way to get around the stuck upload/scanning by opening another window and sending another job through, then cancelling it and restarting from the window I was in ( I had already repositioned the piece in the other window by that time however.)

Unfortunately, it still didnt make it through on the second cut attempt, and once you pick the piece up out of the bed of the GF youre pretty much done. ill be making a new one tomorrow I guess


#3

A lot of us have run into this bug in the past few weeks.

The trick with starting a job in another window is the most reliable way to fix it, but it doesn’t always work.


#4

With cancel greyed out, I have been able to restart the machine to break out of that situation. Just don’t close the UI or move the material and scan again. Numerous times across two days a week or so ago I had this happen, and the second scan always went through.
Good Luck with your convention!


#5

I had this happen several times last night. I was doing some engrave testing for depth. Got stuck on the scan / forever uploading part and finally closed the browser (Chrome). Placement issues weren’t of the importance to me, as to @takitus or someone else, so that part wasn’t a big deal, really. I did however see, when I reopened the browser, that the file it had hung up on was loaded into the workspace. It’s like it really did upload it, but that there was no way to know because the scan screen, (with greyed out cancel button) was still there. It was the first time I’ve experienced this.


#6

So you powered down/ restarted the GF, and when it came back up the GUI was unfrozen?


#7

This happened to me also. They said they fixed the problem.
Obviously not.
Lost my position and project.


#8

Has this already been reported to support?


#9

When you restart the machine it cancels that operation. When the machine came back online the UI (that still has your file right where you left it) reports ready, and you click print again, and it begins that operation again. 4 times I did this and the subsequent scan went through.
I had also been stuck ‘Preparing’, and then the cancel is not grayed out so I just canceled it and gave it another go. The second attempt worked in both cases.
In this case it was a simple file that I was repeating, so I knew my file was clean and how long processing should take. When it exceeded that by a significant amount I would cancel ‘preparing’ or restart the machine when stuck on ‘scanning’.
Some files take a while to process, so my advantage was I knew how long it had taken previously so I knew when something was amiss.

@Xabbess, when this was happening to me, there were numerous examples posted in P&S for a couple of days, so I’m sure support is well aware of it. :+1:


#10

I tried this when you told me, it didn’t work. Had to shut down the UI. Happened to me twice and was reported.


#11

Dang. Too bad.
Had you ever done this file before? In my case I had, so I knew the file was clean and when it was taking longer than it should.
So if there is another reason for the op to hang, this solution isn’t going to work.


#12

Yes, I had done a few. And this happened to me twice with different files that I had done before. It hasn’t happened since and sorry that it’s happening to others, especially since support told me they found the problem and fixed it.


#13

My test was but a simple, filled line…no more, no less. Couldn’t have been the file, no way, no how.