This is SUPER interesting. That is phenomenal feedback. I’m almost 100% certain that this is something that we can fix, although it might take some tinkering. Great job figuring out the root of the issue!
The first thing to try would be just to turn off the notification. You can do that here:
I’ve run into the issue with it timing out when uploading a large file too. I think that we need to automatically disable connection monitoring while the file upload is in progress.
Disabling that check box might also fix your issue while cutting, but I’m not 100% sure. The UI shouldn’t require too much processing power so I’m surprised that it’s lagging, but that is excellent to know about and I will work on seeing if I can understand what’s going on and fix it.
One thing I’ve been doing while uploading files that I know are large ahead of time- going to the file management portal and uploading it there. It has a little loading bar so you can watch the progress, which is why I like it.
oh, I need to clarify, it is not the upload of the file to the Maslow where I receive the timeout, it is when choosing a file to cut either from the dropdown under the Maslow tab or the play option in the screen you are displaying.
I think that this is still worth a shot. I think that what is going on isn’t that the machine isn’t responding, it’s that displaying the gcode on the display is taking so long that the browser thinks the machine isn’t responding.
On my todo list is to have the computer load that gcode in chunks so it doesn’t try to do it all at once.
It interprets the gcode but just so that it can be displayed, it doesn’t impact the machine in any way, but it does take a fair amount of local processing power which depending on the computer’s speed means it can take several seconds for the file to display
I have another issue I need to fix first. I have two belts that won’t retract all the way. After reading the forums I am going to try to loosen the bolts around the two offending arms. During this process I found some of the inner posts and top and bottom clamps have broken pieces that hold the nuts in place. They were not able to come off easily. I ordered two new top and bottom clamps and 8 more inner posts to rebuild that part of the Maslow. I will try to mess with the monitoring once I have it back together. I may try to use the broken parts until the new ones come in. I will find a way to keep the nuts tight. Cheers!
Hmmm not good. Ill refund your order and send you some discount codes to get the replacements for free, if you don’t mind placing the order a second time
I do not mind. I don’t mind supporting the cause if you would rather. Also, I think I missed the 4.1 thing. I didn’t pay attention for a few weeks, my fault. Will the team be having enough parts for me to complete the upgrade, once they arrive?
I have it back together enough for now, until I receive the new parts. I will be able to test taking off the monitoring to see if that helps.
I just tested opening the longest file I have, it still took some time, and no disconnection. Yay! It came up. What does the connection monitoring actually look for? Is it possible while the monitoring is on and the computer is calculating the points for the display a pause happens in the communications? Cheers!
Yes, we will absolutely have those parts available after the kickstarter in our shop!
Excellent! That is great to hear!
The connection monitoring looks for regular messages from the machine to say that it’s still connected, if it doesn’t get a message for 20 seconds it will give you that alert. The problem is that if there is ever a lag (for example when the computer is opening a large file) it can trick the computer into thinking that it hasn’t heard from the machine for 20 seconds, when in fact the computer has gotten messages from the machine, it just has been too busy to process them.
I think that the real solution is probably to change how the connection monitoring works. It used to be off by default and maybe we should turn it off again.
