DuetWiFiFirmware minor release 1.15c

dc42

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.

curieos

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.

dc42

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

curieos

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.

curieos

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

Toddimus

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.

Sakey

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

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?

Sakey

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!

Toddimus

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

sga

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

lignumaqua

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.

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

lignumaqua

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

dc42

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.

deckingman

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.

lignumaqua

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

Toddimus

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

dc42

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.

guywinslow

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