Another strange problem…



  • So, if a print finishes, the printer homes. If I make the heaters active by hand and then try to upload and print, once everything is up to temp and the print is ready to start, the printer head moves for a split second and then the duet resets itself (verified by losing autocalibration settings). Sorry for all of the problems! I try a lot of nonstandard things to try to break stuff.

    Charles


  • administrators

    1. Which firmware version?

    2. Which electronics?

    3. After the printer has reset itself, what is the "Last reset reason" and reset time displayed by M122?



  • 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: 4



  • 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.

    Charles


  • administrators

    @heathmanc:

    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: 4

    For #2 I wanted to know which Duet you are using.

    For #3 I also need to know what the last software reset code was.

    @heathmanc:

    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





  • 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.


  • administrators

    @heathmanc:

    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.



  • @dc42:

    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.


Locked
 

Looks like your connection to Duet3D was lost, please wait while we try to reconnect.