Minor firmware release 1.17c

This is now in the usual place on github. The purpose of this release is mostly to fix bugs but it has a few minor improvements too. Here is the change list:

New features:

• The layer height comment in gcode files produced by Matter Control is now recognised
• M101 and M103 (firmware retraction commands generated by Simplify3D) are now recognised
• G20 bed probing now prints the mean height error and RMS deviation to 3 decimal places

Bug fixes:

• G30 with no parameters now sets the machine position to the Z probe trigger height instead of the user position. This means that running G28 (home) and G29 (bed probe) alternately no longer causes the bed height map to creep up or down in average height when Z homing uses the Z probe. However, it means that the Z height displayed after a G30 command is no longer always the same as the Z probe trigger height.
• In firmware 1.17 the speed change command by the M220 command got delayed until the next G1 or G0 command with an F parameter was read.
• In firmware 1.16 and 1.17 the acceleration used in G11 un-retraction commands was sometimes incorrectly reduced if pressure advance was configured on a different extruder.
• In firmware 1.16 and 1.17 when pressure advance was configured, the extruder acceleration limit implied by pressure advance used the pressure advance value for the wrong extruder.
• Firmware retraction did not work if additional axes had been configured e.g. for an IDEX printer.
• G29 commands using the P parameter with an upper case M in the filename were recognised as M commands instead

I have also updated the DuetWebControl files to chrishamm's latest 1.14a release.

Edited 1 time(s). Last edit at 01/14/2017 04:56PM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Thanks David!

Quote
dc42

• G30 with no parameters now sets the machine position to the Z probe trigger height instead of the user position. This means that running G28 (home) and G29 (bed probe) alternately no longer causes the bed height map to creep up or down in average height when Z homing uses the Z probe. However, it means that the Z height displayed after a G30 command is no longer always the same as the Z probe trigger height.

Are you saying that a G92 Z0, with a subsequent G30 S-1 will no longer report trigger height?

Edited 1 time(s). Last edit at 01/16/2017 11:37AM by PDBeal.

Quote
PDBeal

Quote
dc42

• G30 with no parameters now sets the machine position to the Z probe trigger height instead of the user position. This means that running G28 (home) and G29 (bed probe) alternately no longer causes the bed height map to creep up or down in average height when Z homing uses the Z probe. However, it means that the Z height displayed after a G30 command is no longer always the same as the Z probe trigger height.

Are you saying that a G92 Z0, with a subsequent G30 S-1 will no longer report trigger height?

If you have bed compensation enabled, then yes. So disable bed compensation before measuring trigger height.

Edited 1 time(s). Last edit at 01/16/2017 01:34PM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

I have found an issue, connected to the bed leveling, but I am not sure if this has something to do with 1.17c, or a general problem. I just didn't want to start a new thread.
It seems like with bed leveling activated (loaded with G29 S1), my delta stops at X=-20, Y=100 with a high pitch sound from XYZ motors. This also happens with a Y coordinate higher than +100, and aroun X-20.
If I disable the G29 command, Printer has no issues to reach every point (or at least I was not able to find any). What is also interesting, that the Z coordinate doesn't seem to play a role here, I.e. This happens with Z=0.1 and Z=50.
The heightmal is attached to this post, and it does seem to have a 'hole' close to the region in question... i guess there are some coordinate system transformation issues in the present Firmware...

I also had a few oddities when first using this new release... after homing everything and loading the transformation file the print would start somewhere around X180:Y20 instead of X100:Y100 as usual. I hadn't raised this before now as I cannot reproduce it - it happened a few times, since when I've run G29 S0 a few times, printed a few objects, and everything has behaving normally (fingers crossed it'll continue that way).

This is either a case of misbehaviour due to some remnant of the previous release (1.17) or some random problem that's gone away.

I saw you added G2 and G3 support in 1.17c+1. Is that just for the sake of making this CNC compatible, or are you trying to future proof the board in case we ever manage ditch the STL file format and have slicers capable of generating arc moves?

I'd love to use arcs for 3d printing. Better surface finish and smaller gcode file sizes.

Edited 1 time(s). Last edit at 01/24/2017 10:40PM by Masterjuggler.

I added it to support CNC applications. I agree that it would be good to use in 3D printing too. Btw there is a bug fix to G2/G3 in 1.17c+2.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].