When Maslow loses connection it stops (good).
Can’t Reconnect browser after WiFi restored until power Cycle (Bad)
Comes back in Extended after power cycle (good)
Can restart job after Apply Tension
Can not resume where it stopped without manually modify GCode
No indication of where it was up to when it failed.
I think the problems identified make the application more robust and the downside of bad WiFi needs to addressed as a separate issue.
When Maslow loses connection it stops (good).
Can’t Reconnect browser after WiFi restored until power Cycle (Bad)
Comes back in Extended after power cycle (good)
Can restart job after Apply Tension
Can not resume where it stopped without manually modify GCode
No indication of where it was up to when it failed.
even with a serial console?
enable debug logging (on the fluidnc side, not the maslow.yaml side)
this should give you logs showing when a connection/disconnection happens
I think the problems identified make the application more robust and the
downside of bad WiFi needs to addressed as a separate issue.
yes, this doesn’t avoid the root cause that is triggering the problem, it just
keeps that problem from resulting in the machine running away when it’s stopped.
Tried again this morning. Different behavior. Logs below.
Ran several short files. No bit in Maslow.
On interruption to browser connection, the job completed each time. Could not retake control until job completed.
Note this is a browser computer disconnect from WiFi not Maslow disconnect from WiFi.
Additional short log using early version Haven’t loaded latest yet. This is without a job running, just interrupting the WiFi signal momentarily puttyb.log (8.2 KB)
Still on earlier version
Home always goes to Xm0Ym0
Disconnecting serial port also drops browser puttyc.log (20.9 KB)
Got this message when tried to reconnect while job running from browser
@bar I think these change needs to be incorporated ASAP. It prevents the runaway condition (at least I haven’t been able to reproduce it with this version), if WiFi fails the Maslow continues. You can reconnect browser (sometimes have try multiple times), with an option to pause the job, or wait until it completes. If paused, you then have the option of continuing or halting run.
I just finished cutting a small student project. It cut out perfectly. The only problem I had was that after cutting it ran away again.
When the cut is finished, the default jog distance is generally like .7 mm. It will successfully jog that distance. So I set it up to 50 mm this time and it ran away. I had to cut the power to get it to stop.
It looks like you are already working on this from the updates above, but here is some more data if you wish to look at it.
Then when I restarted it was in unknown state. I tried to just loosen and tighten the bents, but it would only allow me to loosen them, not to tighten them.
Are you cutting in inches or mm. If your last cut was in inches and you set it to 50mm, maybe it was actually 50 inches. This should display on the front screen.
The log file confirms it was in inches
[MSG:INFO: Program End]
[MSG: /sd/Coaster_AC_JG.nc file job succeeded] JogTo: $J=G91F98.43Y-0.787 (inch)
[MSG:DBG: Belt positions saved to NVS: TL=1572.02 TR=1487.84 BL=2067.07 BR=2013.21 state=7] JogTo: $J=G91F98.43Y-50 (inch)
Stop Maslow and Gcode
Stop Maslow and Gcode
After a power down in the middle of a move, the Maslow has no way of knowing where it really is. So you need to Retract, Extend and Apply Tension to get to a known state. Otherwise, it’s starts running with the belt settings it has in NVS which will be out of date.
