the firmware doesn’t know what the safety height is.
I’m not even sure that the firmware can know when you loose the USB connection.
but retracting to just above Z=0 seems like a good thing.
Say 0.1" above zero, you don’t need much room, just not in contact. For that matter Z=0 would leave just the very corner of the bit contacting the wood, that’s probably something that could be sustained for a long time if the rest of the bit is in the air to dissipate the heat from the bit
The ‘USB connection lost’ error is from the GC software. GC will not be able to help in this instance. On the other end of the cable the machine really isn’t frozen, the firmware is just waiting for the next gcode to arrive. I can’t see a way that the firmware could know that the connection is faulty, though. No easy way to continue on cutting from where it left off either - GC will send commands that reset the Arduino when it re-connects.
Is there a legitimate reason why the bit would be down into the material and not be moving for say 5 seconds? Could the firmware know that the bit is down and if it doesn’t receive a command in a short time frame it could automatically raise the bit and pause GC? I’m clueless to how things really work so this might be a long shot.
There are times when it is reasonable to have the z axis less than zero. Too, the firmware doesn’t know whether the router is running. I think that there really is no better safety than an attentive operator. Every additional layer of automation adds one or more modes of failure.
‘legitimate’ is a hard thing to define. If a pocket has been cut, it’s very
possible for the bit to be below zero with no problems.
It would be a really nice thing to have the router turn off if it’s not moving
and turn on for X seconds before motion starts after that.
But Bar was too nervous about potential liability if the maslow turned on the
router unexpectedly to include that as a default feature. At this point I think
it’s turning into competing liability concerns, the liability of hurting someone
turning on vs the liability of starting a fire because it doesn’t turn off 
Don’t forget the liability of tempting complacent disregard of safety. The operator is responsible but might mistakenly put too much trust in the automation. We’ve already seen a fire started that way, adding more layers of ‘protection’ will tempt more ill-advised trust.
Agreed, but I can’t think of a scenario when the g-code would have it sit in one spot, without moving all while having a negative z direction for 10 plus seconds.
I am just working on getting my Maslow set up and while debugging saw this thread. Maybe setting up a watch dog timer/kill switch in the firmware that sets z to the safety height and pauses gcode operation if not kept alive every X seconds. I think Marlin uses a M113 Host keep alive command to to perform something similar to this.
It looks to me like the program is running in a place where it doesn’t have permission to create a new file. I would try either running it from somewhere like the desktop where it doesn’t need permission to create files, or running in administrator mode
launched, only the older version
Right click, run as administrator? Move it out of the repo. Create c:\Masow\ install here
Thank you
GC crash on file opening. This is happening to with any character on the file name, even naming my file “a.gcode” or “1.gcode”. Even with others file formats like .nc .ngc .text. I have tried moving GC to Program Files, System32, User file,… I have read a lot of posts in this forum and tried a lot of things but nothing works.
This is the console message where I find the error.
Someone can help me please?
File “C:\Users\Bar\Git\GroundControl\UIElements\viewMenu.py”, line 96, in load
UnicodeEncodeError: ‘ascii’ codec can’t encode character u’\xed’ in position 26: ordinal not in range(128)
[18292] Failed to execute script main.
I attached some files I have been trying in case the error is on my files.
monkeytext_0001.ngc (140.5 KB)
TEXTOmonkeydoV2_0001.ngc (140.5 KB)
TEXTOmonkeydoV2_0001.ngc (140.5 KB)
TEXTOmonkeydoV2_0001.ngc (140.5 KB)
TEXTOmonkeydoV2_0001.ngc (140.5 KB)
Have you considered using WebControl? That might be an easier option than figuring out exactly what is going on
are you using the newer version “groundcontrol2022” put out by eastbay source? it is a nice update and should work. I’m curious if you would see this crash on that version.
Thank you all. I figure it out with webcontrol and also with groundcontrol2022. Thank you for your help
If I may ask, what was the cause and how did you fix it? I only ask so if there is someone else that ends up with the same problem, then they (and by that I mean us here on the forums) know something that can be suggested if they ask. Just trying to help all around!!
Cheers!
