Another strange problem…
-
1. Firmware is 1.17 Dev6
2. .9 Jugetek steppers (42JT47-1684A) / Onyx bed / E3D v6 / 24v Meanwell power supply (21 amps)
3. Last reset 04:25:00 ago, cause: software
Error status: 4For #2 I wanted to know which Duet you are using.
For #3 I also need to know what the last software reset code was.
Something of note. I typically do not home my printer before consecutive prints, therefore, do not have a home command in the start of the g-code for each file (because it's at the end). After a print finishes and homes, the duet does not consider that homed and bails on the print.
If you turn the motors off e.g. by sending M0 at the end of a print, the firmware considers that the motors are likely to move and are therefore no longer homed.
-
It is a duet wifi. I don't see the reset code, so I've pasted the M122 below. I've got what you're saying about the homing, that's my bad.
=== Diagnostics ===
Used output buffers: 2 of 32 (32 max)
=== Platform ===
Memory usage:
Program static ram used: 20204
Dynamic ram used: 84004
Recycled dynamic ram: 2288
Current stack ram used: 2896
Maximum stack ram used: 8084
Never used ram: 16492
Last reset 05:33:54 ago, cause: software
Error status: 4
Bed probe heights: 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 51.3ms
MCU temperature: min 42.9, current 45.5, max 48.5
Supply voltage: min 18.9, current 24.0, max 28.2, under voltage events: 0, over voltage events: 0
Driver 0: stalled standstill
Driver 1: stalled standstill
Driver 2: stalled standstill
Driver 3: standstill
Driver 4: standstill
Current date and time: 2016-12-06 16:49:03
Slowest main loop (seconds): 0.078125; fastest: 0.000000
=== Move ===
MaxReps: 16, StepErrors: 0, MaxWait: 77938ms, Underruns: 0, 0
Probe change coordinates:
=== Heat ===
Bed heater = 0, chamber heater = -1
Heater 0 is on, I-accum = 0.1
Heater 1 is on, I-accum = 0.3
=== GCodes ===
Move available? no
Stack records: 1 allocated, 0 in use
http is ready with "M122"
telnet is idle
file is doing "M190 S85"
serial is idle
aux is idle
daemon is idle
=== Network ===
WiFiServer is running
SPI underruns 0, overruns 0
=== Webserver ===
HTTP sessions: 1 of 8 -
may be related to this:
https://www.duet3d.com/forum/thread.php?id=489 -
Possibly, but I don't have to reset the duet, it does it by itself, I just have to reconnect to it. Seems like if a file tried to print without the printer being homed, that should be an easy error to trap and cancel the print, not lock things up and completely reset the controller.
-
Sorry but I'm having a job grasping what it is you are trying to do. It seems that you want to start a print without first homing the printer. Why would you want to do this? Generally the lines of ones gcode files tell the printer head to move to specific positions and these are generally regarded as being with reference to the home position. If the printer doesn't know where home is, how can it function correctly? Along the same lines, why would you want to home the printer after the print has finished? Wouldn't the print head crash into the part that has just been printed or do you remove the printed part, then do the homing and if so why?
-
It's a delta, and homes to the top of the towers, it's standard to home one after print. I don't want to print not being homed, but there seems to be a problem. Me end script happens to disengage the motors, therefore unhoming the printer. If you try to upload and print again, it seems to reset the duet instead of just canceling the print, as best as I can tell.
-
Ahhhhhh I think I see. You mean that you move the print head to the home position which is at Z max at the end of the print yes? I assumed by homing you meant determining the home position which I'm assuming even on a delta would mean probing the bed.
-
No, not at all, this was a mistake on my part, the result is just a little strange, homing on a delta is at the top of the towers.
-
Seems like if a file tried to print without the printer being homed, that should be an easy error to trap and cancel the print, not lock things up and completely reset the controller.
This is a known issue, the volume of error messages floods the web interface. It's on my list to fix. Meanwhile, avoid the problem by including G28 in your slicer start gcode.
-
Yup, already taken care of, just an oversight on my part really.
-
Meanwhile, avoid the problem by including G28 in your slicer start gcode.
I do not know if that helps to at least someone, but maybe it's possible to implement "conditional home" parameter for G28 ? Something like "home only if not already homed"?
I'm homing printer manually and I do not include G28 in my g-code files, so I'm also sometimes experiencing this issue.
