DuetWiFiFirmware minor release 1.15c


  • administrators

    I have just released this at https://github.com/dc42/RepRapFirmware/tree/dev/Release. Here is the change log:

    • Increased the maximum number of probe points to 64 on Duet WiFi and 32 on Duet 0.6/0.8.5
    • Added move debug facility
    • Added recording and reporting (via M122) of more types of move underrun
    • Use fabsf instead of fabs
    • M21 no longer re-mounts a drive that is already mounted and has open files on it
    • Added "volumes" variable in extended status response
    • Report card details after M21 is called to mount an SD card
    • After a heater gets to within 2.5C of its setpoint, the load-change PID parameters are used until the setpoint is changed. Previously the load-change PID parameters were used only while the temperature was within 1C of the setpoint.
    • Bug fix: corrected M37 reporting of simulation time
    • Bug fix: M220 speed changes were not being implemented as soon as they should be
    • Bug fix: lookahead was sometimes failing to join sequences of short decelerating moves together
    • Bug fix: at startup the thermistor readings were sometimes very high, which triggered a bug in strtod() called in PanelDue firmware 1.14 and earlier

    It's compatible with DuetWiFiServer 1.02 and earlier, and DuetWebControl 1.12.



  • It seems you changed the way the E endstops work (using them for FSR board). I no longer have to have a jumper to change it to NC. Almost had an issue during a print just now.


  • administrators

    No, I haven't made any changes in that area.



  • Then I'm not quite sure what happened. I made a print two days ago with auto calibration and it worked fine. I then loaded the new firmware yesterday, started another print, and it wasn't probing the bed anymore since it was already triggered. I didn't make any changes to my config file other than to adjust for the z offset.



  • After a restart the behavior has reverted back to normal. Not sure what caused it.



  • I just had the same problem with the FSR sensors (JohnSL board). With 1.15c when I try an auto bed calibration on my delta, it says the endstops are already triggered. No hardware change. Reverted back to 1.15b and it works again. I tried rebooting the duet wifi, but that didn't help.

    I do have a 17 point bed.g file. 10 points on perimeter and 6 points halfway in and one in the center. Don't know if that matters.

    I do have the jumper on the JohnSL board to make the board look like (I think) a normally closed switch. This didn't get changed between firmware.

    Not sure why but it is something different in 1.15c.



  • Having the same problem, going from 1.15b to 1.15c . Worked fine with 1.15b but 1.15c bring up " Z probe warning: probe already triggered at start of probing move" .


  • administrators

    Those of you who are having Z probe trouble going from 1.15b to 1.15c, what probe type do you have set in M558, and how do you have the probe connected?



  • Mines connected 3x fsr to JohnSL board to the duet via e0 endstop I think. Set at 4 on m558.

    Worked fine in 1.15b, upgraded to 1.15c no longer working so downgraded again and back up and running. Hope that helps DC!



  • Mine is connected to the E0 endstop.
    Jumper on JohnSL board is set for NC

    M558 P4 X0 Y0 Z0
    M574 X2 Y2 Z2 S0 // hall effect switches at the top of each delta tower
    G31 X0 Y0 Z0 P500

    Thanks DC



  • Do you ever sleep?Thx for the update!!!



  • Not sure if this is a Duet WiFi firmware issue, or chrishamm's web page. Running 1.15c with web interface 1.12 on a brand new Duet WiFi on a brand new CoreXY. All is working fine, very quiet and no problems! 🙂

    Very minor issue, the web page always reports that the build has 500 layers, no matter how many there really are. (This model actually has 236 layers.)

    EDIT: The root cause is likely that the model height is incorrect

    Always comes through as 100mm.



  • I seem to remember reading something somewhere about the firmware finding the object height by reading the last G1 Z command in the gcode file. If you have a G1 Z at the end of your print to lift the head, that can screw it up. You can still lift the head but use G0 instead of G1 (does the same thing I think).



  • @deckingman:

    I seem to remember reading something somewhere about the firmware finding the object height by reading the last G1 Z command in the gcode file. If you have a G1 Z at the end of your print to lift the head, that can screw it up. You can still lift the head but use G0 instead of G1 (does the same thing I think).

    Aha! Thank you, that is precisely the problem. I have a G1 Z100 in my ending script. I'll change that to G0 Z100.


  • administrators

    A workaround for that is to put a comment starting with upper case E on the end of that G1 line. I'm not sure that using G0 instead of G1 will make any difference.



  • Found where I'd read that about G0 - it was here https://miscsolutions.wordpress.com/2014/06/11/five-tips-for-using-dc42-firmware-on-the-reprappro-ormerod/. No offence intended but if G0 doesn't work, maybe you should amend you blog David.



  • Using G0 fixed the problem. Many thanks for the help.



  • @dc42:

    Those of you who are having Z probe trouble going from 1.15b to 1.15c, what probe type do you have set in M558, and how do you have the probe connected?

    Any more thoughts on this issue?
    I know you are quite busy, and hopefully have a life outside 3D printing, so I understand any delay. 🙂


  • administrators

    Sorry I won't be able to look at this for several more days. I've already looked at the code changes in 1.15c and I didn't find anything to explain it.

    If you wish, you could try connecting the fsr board to the Z probe connector instead of E0 and use probe type 5.



  • Just code my board in the mail 1 week ago. had to print a Case. Got wired and mounted today.

    Improvements:
    Stepper control vast improvement.
    Temperature control wall much stabler, terns off when the gcode changes the temperature wall its printing.

    Working on reproducing it right now


Log in to reply