RepRapFirmware 2.02RC7 available

dc42 · 22 Dec 2018, 13:44

I've just released this at https://github.com/dc42/RepRapFirmware/releases/tag/2.02RC7. This release includes bug fixes 12864 displays and for CoreXY machines, functionality improvements for CNC machines, and changes for future versions of Duet Web Control. As usual, see https://github.com/dc42/RepRapFirmware/blob/dev/WHATS_NEW.md for the change list.

If you are already running 2.02RC6 then there should be no significant surprises, otherwise be sure to read the upgrade notes.

Please provide feedback on this release as follows:

To report that this release is working well for you and/or that it fixes bugs you encountered in previous releases, please post in this thread.
To report an issue that is new to this release, or that a bug that should be fixed in this release (according to the whatsnew file) is still present, create a new thread with a title of the form "2.02RC7 issue: ...", or if someone else has already created such a thread describing the same issue, post in that thread.

Danal · 22 Dec 2018, 17:03

Testing on a small delta now.

By the way, love LOVE love the new "zip" package, avoids numerous problems with naming, browsers that put (1) in duplicate downloads, etc, etc.

Brilliant!

whosrdaddy · 22 Dec 2018, 19:01

@danal Yes, this is the way forward!
Loving it too. This will prevent unsupported DWC/RRF combinations.
Keep up the good work David!

patakopecek · 22 Dec 2018, 19:09

Testing it on my CoreXY HEVO, but I am using DWC2 (there are issues but it works) and the FW is flawless for now

kazolar · 22 Dec 2018, 20:46

I setup ditto tools for Tool 0 + Tool 1 = P4 and Tool 0 + Tool 1 + Tool 3 = P5 -- that works, there is an odd glitch with standby temperature.
I see now I can do G10 P4 R215 S215 and it sets the temperature for each heater -- so I don't have to specify it directly with colons, though standby temperature is working even more weird now.
I used to do the follow
G10 P5 R215:215:215 S215:215:215 -- all good
Then to do probing I switch to T0 -- (that would correspond with P0 -- P0 has no temperature set) -- so as it does the probing Tool 0 temperature drops even though it has gone into standby and standby has been specified for P5 which includes the heater for P0.
To get it to normal I have to re-issue the G10 command and do T5 and then M116. Standby temperature for T0 should be the same as of the P0 -- and the heater should honor the standby temperature component of P5 for tool 0 -- this worked a little better in 2.05 -- as the new command for the mixing tools has made them even more confusing.

kazolar · 22 Dec 2018, 21:35

Also progress in DWC for ditto printing is still wrong -- S3D reported 18000mm of plastic needed and 3 tools active each has used 1000mm, I see the count keeps going up as a sum of all 3 tools, so far and progress is at 20% which is wrong.
Filament usage estimate now makes sense, but progress is wrong

EDIT --
I commented out the section dwc.js which does progress bar calculation by filament usage and now the progress bar makes sense

changed it to the following:
around line 1400

 				//	progress = ((totalRawFilament / totalFileFilament) * 100.0).toFixed(1);
					var totalPrintTime = (status.printDuration - status.warmUpDuration - status.firstLayerDuration) + status.timesLeft.filament;
					progress = (((totalPrintTime - status.timesLeft.filament) * 100.0 / totalPrintTime) ).toFixed(1);
 
				//	var remainingFilament = (totalFileFilament - totalRawFilament);
					if (progress < 0) {
						progress = 0;
					} else if (progress > 100) {
						progress = 100;
						totalRawFilament = totalFileFilament;
						remainingFilament = 0;
						jobJustFinished = jobHasFinished = true;
					}
					progressText.push(T("Filament Usage: {0}mm of {1}mm", totalRawFilament, totalFileFilament));
 
					// TODO: Make this optional
//					progressText[progressText.length - 1] += " " + T("({0}mm remaining)", remainingFilament.toFixed(1));

now the progress bar in DWC is indicative of what the firmware thinks filament progress is. I don't know how to get actual expected filament usage in ditto mode, but this way the progress bar makes sense

Danal · 23 Dec 2018, 04:37

Printed a couple of things on the small delta with a .1mm nozzle. Outstanding results. No flaws that I've found.

I'll try the Mosaic Palette in a couple of days (big delta, which is where the Palette 2 is currently installed, is in the middle of a monocolor print that should finish tonight).

dc42 · 23 Dec 2018, 10:18

@kazolar said in RepRapFirmware 2.02RC7 available:

Also progress in DWC for ditto printing is still wrong -- S3D reported 18000mm of plastic needed and 3 tools active each has used 1000mm, I see the count keeps going up as a sum of all 3 tools, so far and progress is at 20% which is wrong.
Filament usage estimate now makes sense, but progress is wrong

EDIT --
I commented out the section dwc.js which does progress bar calculation by filament usage and now the progress bar makes sense

Thanks, I've passed this on to chrishamm.

dc42 · 23 Dec 2018, 10:19

@kazolar said in RepRapFirmware 2.02RC7 available:

I setup ditto tools for Tool 0 + Tool 1 = P4 and Tool 0 + Tool 1 + Tool 3 = P5 -- that works, there is an odd glitch with standby temperature.
I see now I can do G10 P4 R215 S215 and it sets the temperature for each heater -- so I don't have to specify it directly with colons, though standby temperature is working even more weird now.
I used to do the follow
G10 P5 R215:215:215 S215:215:215 -- all good
Then to do probing I switch to T0 -- (that would correspond with P0 -- P0 has no temperature set) -- so as it does the probing Tool 0 temperature drops even though it has gone into standby and standby has been specified for P5 which includes the heater for P0.
To get it to normal I have to re-issue the G10 command and do T5 and then M116. Standby temperature for T0 should be the same as of the P0 -- and the heater should honor the standby temperature component of P5 for tool 0 -- this worked a little better in 2.05 -- as the new command for the mixing tools has made them even more confusing.

AFAIR there has been no change to heater and tool management since release 2.01, and certainly none since 2.02RC5.

Mugga · 23 Dec 2018, 15:39

Hey guys,
today I updated to 2.02RC7 coming from 2.01. After the update I cant get my bed compensation working. Normally I would have done a G32 and from time to time G29 which I'm loading in gcode with G29 S1 before a print. This worked for me.

But now after a G32 I'm getting the message:
Warning: 3/4/5-point bed compensation is deprecated and will be removed in a future firmware release. Please use G29 mesh bed compensation instead.
Bed equation fits points [10.0, 10.0, 0.188] [10.0, 185.0, 0.324] [185.0, 185.0, 0.125] [185.0, 10.0, 0.246] [100.0, 100.0, 0.190]

After that I've just used G29 but the nozzle is about 1mm above the bed and z-baby stepping isnt working.
Can someone help me with that?

Never mind guys, just redid the z-probe height configuration. And its working!
But with no G32 anymore, what is the proper way for lvl a cartesian? Just from time to time a G29 and normally a G28 for all axis? Or do I have to do a G29 everytime?

dc42 · 23 Dec 2018, 18:00

Using G32 for bed compensation is still supported, but has been deprecated for some time. The suggested alternatives are:

Use mesh bed compensation in place of G32, with a 4-point mesh of you were using 3- or 4-point G32 bed compensation, or a 9-point mesh if you were using 5-point bed compensation;
Use a finer mesh spacing, but before most prints don't probe the bed, instead use G29 S1 to load the height map file generated the last time you ran mesh probing.

Phaedrux · 23 Dec 2018, 18:02

@mugga You can still use G32 and bed.g to do manual or automatic bed leveling with independant lead screws. The main change I think is to use the mesh grid of g29 since it's more flexible instead of the simple plane used with G32 and a few defined points.

Computiger · 23 Dec 2018, 22:56

where I can geht the DuetWebControl 1.22.6 ?

Phaedrux · 23 Dec 2018, 23:32

@computiger It should all be included in the unified zip file now. One download, one zip file, upload the whole zip file, and all the firmwares are updated together, including the DWC.

spunone69 · 24 Dec 2018, 09:53

It uploads fine until the very last file "dwc.js.gz" which errors out every time...

spunone69 · 24 Dec 2018, 10:10

@spunone69 Nevermind...I figured it out...but it still won't home any axes!

dc42 · 24 Dec 2018, 11:28

@spunone69 said in RepRapFirmware 2.02RC7 available:

@spunone69 Nevermind...I figured it out...but it still won't home any axes!

Any error messages? Which firmware version are you upgrading from?

Irwayz · 24 Dec 2018, 14:43

@dc42 I just installed this hoping it would solve my problem but I'm still getting the problem that the my Duet Wifi doesn't seem to understand G2/G3 commands in the R Form. For example G02 X-85 Y-63 Z4. R28207. It says that its missing the parameters (likely understanding it to be missing I and/or J). Am I doing something wrong here?

dc42 · 24 Dec 2018, 14:51

Nobody has asked for the R parameter to be supported in G2/G3 before, and until I did some research after reading your post, I wasn't aware of it. I can add it to the wish list for release 2.03.

Irwayz · 24 Dec 2018, 14:53

@dc42 Thank you very much.

	// progress = ((totalRawFilament / totalFileFilament) * 100.0).toFixed(1);
	var totalPrintTime = (status.printDuration - status.warmUpDuration - status.firstLayerDuration) + status.timesLeft.filament;
	progress = (((totalPrintTime - status.timesLeft.filament) * 100.0 / totalPrintTime) ).toFixed(1);

	// var remainingFilament = (totalFileFilament - totalRawFilament);
	if (progress < 0) {
	progress = 0;
	} else if (progress > 100) {
	progress = 100;
	totalRawFilament = totalFileFilament;
	remainingFilament = 0;
	jobJustFinished = jobHasFinished = true;
	}
	progressText.push(T("Filament Usage: {0}mm of {1}mm", totalRawFilament, totalFileFilament));

	// TODO: Make this optional
	// progressText[progressText.length - 1] += " " + T("({0}mm remaining)", remainingFilament.toFixed(1));