RepRapFirmware 2.02RC7 available

kazolar

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

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

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

@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

@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

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

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

@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

where I can geht the DuetWebControl 1.22.6 ?

Phaedrux

@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

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

spunone69

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

dc42

@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

@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

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

@dc42 Thank you very much.

brandonh

David, thanks for all the work you've done to make Dynamic Acceleration Adjustment (M593) available. Seriously, if you're ever in the Bay Area, I'm buying the beer (or offering my homebrews).

I've spent hours and dollars making changes to my large Kossel to chase out ringing issues, as documented here:
https://groups.google.com/forum/#!topic/deltabot/d_JHfa4qFck
... changing out the frame (1515 -> 2020), carriages, effector (printed -> Smart Effector), rods, extruder style (bowden -> flying), cooling, 12v->24v, hotend, you name it.

In 10 minutes, with a single command (M593 F51.6), I have possibly the single most obvious print-quality bump I've seen in 5 years on this printer. The pic below is a 10mm double-wall multi-test cube print; the face shown is one where the head makes a long travel move to the shown left face, then moves right, for a 40 mm/s external perimeter.

The motion is not 100% gone, but it's obviously vastly reduced. I don't know if this is due to frame flex, rod flex, the weight of the extruder connected via a bowden time above, or something else. But whatever, it's really good now. Going to try out pressure advance next.

Also, I'm very excited that the WiFi continuously tries reconnecting in post-2.0.0 builds! That was the single biggest annoyance from the past. The upgrade to 2.0.2RC7 is great.

(The original thread covering this is locked - including this link for anyone who comes across this post):
https://forum.duet3d.com/topic/5951/periodicity-of-ringing

spunone69

@dc42 It was 2.01, I realized I had to install 2.02 RC2 first...

Marine85

This post is deleted!

dc42

@brandonh, thanks for the feedback! I'm glad it is working well for you. May I re-post your before/after image elsewhere?