GroundControl Crash on File Opening

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.

1 Like

‘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 :smiley:

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.

1 Like

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.


Help solve the problem. The GroundControl program does not start.
What could be the problem?

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

1 Like