New beta firmware 1.20.1RC2 and DuetWiFiServer 1.20+1

dc42 · 3 Jan 2018, 15:04

I have a 0.5mm nozzle on my Ormerod. I'll do some measurements on that one when I have time.

garyd9 · 1 Apr 2018, 00:48

Possible issue (and might not be related to the RC specifically):

(NOTE: I didn't test this properly. It happened once only, but I only ever created the circumstances for it once)

Steps:

1. Start a print from SD card. Let it go for a bit.

2. From the web interface, "G-Code Files" section, RIGHT click on the gcode file you are currently printing, and select "Edit"

3. Do whatever… I don't think you actually need to change anything in it... just open it and view the gcode.

4. Some time after saving/canceling the "edit", the print will STOP (in place, nozzle against plastic) with an error that the gcode file couldn't be read.

Error: Print aborts

Expected: Web interface should disallow any action on a file that would interrupt a print (edit, delete, etc)

dc42 · 4 Jan 2018, 07:34

I can see that editing and saving the file you are currently printing would disrupt the print, it would be the same as re-uploading the file while it is printing. Downloading the file or editing then cancelling it should be ok. Unlike earlier versions, RRF 1.20 does prevent you from deleting a file that is in use.

deckingman · 4 Jan 2018, 08:54

@dc42:

I have a 0.5mm nozzle on my Ormerod. I'll do some measurements on that one when I have time.

Thanks. If you get time, can you also try 10mm extrusion length at high speed. I appreciate that there will be some measurement error but if you pick the speed where you were seeing 11% difference over 50 mm, then you should see something like 9 mm instead of 10 mm which ought to be fairly obvious. I ask because I did some repeat tests at my "worse case" speed and I can't see any detectable difference. I haven't a clue why. I can only surmise that any pressure build up over the shorter distance is being absorbed by the filament deflection inside the Bowden tube? This is purely conjecture of course. If you see similar results then it could be that the algorithm needs further refinement to include a time or distance parameter.

Also, it would be interesting to see if using pressure advance has any effect on the results over the 50mm distance. If I get chance I'll try it but as we seem to be getting some differences in results, it would be useful if others can try it as well. I know that I have to use 0.5 to clean up the over extrusion issue at the end of long high speed moves so that's the value that I'll try.

dc42 · 4 Jan 2018, 12:41

@Guyaros:

Hi,

Where can I download the latest version of Duet Web Control?
currently, I am using DWC 1.20-RC3

I've just updated from 1.19 to 1.20.1RC2, also updated the DuetWifiServer to 1.20.1RC2.
after the update, I experienced frequent disconnections from DWC, and that's new because the 1.19 was very stable.
I think its too early to state that this is a firmware problem, because I only installed the new version an hour ago, so I will keep updating.

In case I will need to downgrade, can an I I downgrade from version 1.20.1 to 1.19 by just uploading the previous version binary files using the DWC?

Thanks,

I'm sorry I overlooked this post yesterday.

1. The latest DWC is still 1.20 so it's in https://github.com/dc42/RepRapFirmware/releases as well as in chrishamm's repo.

2. If the network problems persist, please try installing DuetWiFiServer.bin 1.20, which is in the same place as the latest DWC.

3. Yes.

Guyaros · 4 Jan 2018, 12:45

Thanks for the reply David,

The DWC disconnections do persist, so I will try to install DuetWiFiServer.bin 1.20 as you advised.
I will report if that solved the problem.

Thanks,

burtoogle · 4 Jan 2018, 15:23

I have done a few prints using the non-linear extrusion feature and can confirm that it's working OK. I no longer have the workaround in place that I did previously (extruder was set to 104% and first layer was printed at 95% extrusion). I now have the extruder set to 100% for all layers and can see no evidence of over or underextrusion. Looking good.

deckingman · 4 Jan 2018, 15:46

Glad it's working for you. Personally, I've never had a need for extrusion multiplier greater than about 98% but then, I'm seeing quite different results on the static tests. Do you by any chance have any pics of with and without?

JohnOCFII · 4 Jan 2018, 17:55

@dc42:

Please report good, bad or neutral feedback on this release here. Unless any serious bugs are reported, these binaries will be re-versioned as 1.20.1 by the end of this week.

I installed both DuetWifiFirmware and DuetWiFiServer yesterday. Basic WiFi connectivity was stable for 10+ hours of operation. Basic features (movement, heaters, fans, homing, calibration) all seemed fine on my Kossel mini

Dougal1957 · 4 Jan 2018, 18:07

installed yesterday about 15:00 printer has been on and stable connection since then currently 3+ hours into a print with no issues

burtoogle · 4 Jan 2018, 18:43

Do you by any chance have any pics of with and without?

Sorry, no.

To be honest, I don't think there's going to be much visible differences because we're only talking about a few percent here and there. Having said that, I do think that it's worth using because now I know that for any extrusion rate up to the point at which it starts skipping I can be reasonably confident that it will print the amount of plastic demanded by the gcode. Whereas, before, I was getting -10% at the high rates.

joestefano · 4 Jan 2018, 21:17

2 WiFi's and 1 Ethernet board all printing fine. No WiFi disconnects. Seems very stable

deckingman · 5 Jan 2018, 08:12

@burtoogle:

Do you by any chance have any pics of with and without?

Sorry, no.

To be honest, I don't think there's going to be much visible differences because we're only talking about a few percent here and there. Having said that, I do think that it's worth using because now I know that for any extrusion rate up to the point at which it starts skipping I can be reasonably confident that it will print the amount of plastic demanded by the gcode. Whereas, before, I was getting -10% at the high rates.

That's a shame (no pics I mean).

I'm a bit confused though. You said in a post above that you were running 95% extrusion on the first layer but 104% on subsequent layers and that now you use 100% throughout. The 104% I can understand because it indicates that you were seeing some under extrusion issue, presumably caused by slippage and for which you have now compensated a different way. It's the first layer that I'm trying to get my head around. It would indicate that you were seeing 5% over extrusion before, because you were using 95% extrusion multiplier. Yet you've added a positive compensation plus taken out the 5% negative compensation. Assuming you print the first layer at half speed of other layers, then the slippage compensation would be around 2% so you must be laying down 7% more filament on the first layer than you were before, which ought to be hugely noticeable. It would on my machine anyway. Even with no slippage compensation, changing the extrusion multiplier from 95% to 100% is a pretty big step. Something very odd going on….

burtoogle · 5 Jan 2018, 08:56

Look, it's simple. Before I started using this new feature, I noticed that at my typical infill/skin speed I was getting underextrusion. So I upped the steps/mm for the extruder to 104% but then because I print my first layer walls really slow (so little underextrusion was occurring), I was then getting fat lines. So in the slicer I reduced the first layer extrusion to 95% to compensate. This way I was getting closer to 100% for all layers. But it was a gross simplification. The non-linear extrusion provides a much more accurate means reducing the effect of feedrate changes on extruded volume.

burtoogle · 5 Jan 2018, 10:22

Hi David, I am now trying out M592 on my Kossel XL which is fitted with a e3d v6 and a flex3drive extruder. Filament is PETG at 240C. I'm getting very odd results:

 mm/s   A0 B0    A0.015 B0.0012
1        52.5        52
2        51          50.5
3        50          48
4        47          44
5        44          38

The larger I make A or B, the worse it gets!

I am not perceiving any extruder skipping or other odd noises.

The flex3drive extruder uses a lot of gearing so it's running at around 2250 steps/mm with the stepper set to 8 microsteps.

Any thoughts?

deckingman · 1 May 2018, 13:40

@burtoogle:

Look, it's simple. Before I started using this new feature, I noticed that at my typical infill/skin speed I was getting underextrusion. So I upped the steps/mm for the extruder to 104% but then because I print my first layer walls really slow (so little underextrusion was occurring), I was then getting fat lines. So in the slicer I reduced the first layer extrusion to 95% to compensate. This way I was getting closer to 100% for all layers. But it was a gross simplification. The non-linear extrusion provides a much more accurate means reducing the effect of feedrate changes on extruded volume.

Ahh, sorry. But you didn't make any mention in your earlier post that you'd changed the extruder steps per mm at the same time, hence the reason I was confused. So your 95% for the first layer was actually 95% of 104% which makes a lot more sense.

dc42 · 5 Jan 2018, 14:25

@burtoogle:

Hi David, I am now trying out M592 on my Kossel XL which is fitted with a e3d v6 and a flex3drive extruder. Filament is PETG at 240C. I'm getting very odd results:
 mm/s   A0 B0    A0.015 B0.0012
1        52.5        52
2        51          50.5
3        50          48
4        47          44
5        44          38
 
The larger I make A or B, the worse it gets!

I am not perceiving any extruder skipping or other odd noises.

The flex3drive extruder uses a lot of gearing so it's running at around 2250 steps/mm with the stepper set to 8 microsteps.

Any thoughts?

Yes, that looks odd.

1. If you revert to A=0 B=0, does it revert to the speeds you measured before at A0 B0?

2. If you send M592 D0 does it respond with the values you configured, and a sensible value for L?

3. Please confirm that when doing these tests, you are doing head movement as well as extrusion.

burtoogle · 5 Jan 2018, 15:22

Yes to all 3 of your questions.

I can't fathom what's going on here. I'm getting some variation in the results from run to run.

A question: do the A and B get scaled by the steps/mm value for the extruder? i.e. if the steps/mm value is large will that mean that the values for A and B will be larger compared to the values used for an extruder with lower steps/mm?

dc42 · 5 Jan 2018, 15:38

The calculation it does is:

 	const float dv = dda.directionVector[drive];
	float stepsPerMm = reprap.GetPlatform().DriveStepsPerUnit(drive) * fabsf(dv);
	const size_t extruder = drive - reprap.GetGCodes().GetTotalAxes();
 
#if NONLINEAR_EXTRUSION
	if (dda.isPrintingMove)
	{
		float a, b, limit;
		if (reprap.GetPlatform().GetExtrusionCoefficients(extruder, a, b, limit))
		{
			const float averageExtrusionSpeed = (dda.totalDistance * dv * DDA::stepClockRate)/dda.clocksNeeded;
			stepsPerMm *= 1.0 + min<float>((averageExtrusionSpeed * a) + (averageExtrusionSpeed * averageExtrusionSpeed * b), limit);
		}
	}
#endif</float>

Let me know if you spot a problem with it. dda.totalDistance is always positive, and dda.directionVector[drive] will be positive if a positive amount of extrusion is commanded. I guess the calulation would go wrong if you did a simultaneous movement and retraction.

burtoogle · 5 Jan 2018, 15:46

I did look at that code but I'm not familiar with the RRF source so I can only guess as to how it is working. I do agree that the calculation code looks like it is doing the right thing.

I will continue to play with my XL - let's assume that my odd numbers above are due to just clumsiness on my part. I'll get back when I have done more testing and have come to any kind of conclusion.

	mm/s A0 B0 A0.015 B0.0012
	1 52.5 52
	2 51 50.5
	3 50 48
	4 47 44
	5 44 38

	const float dv = dda.directionVector[drive];
	float stepsPerMm = reprap.GetPlatform().DriveStepsPerUnit(drive) * fabsf(dv);
	const size_t extruder = drive - reprap.GetGCodes().GetTotalAxes();

	#if NONLINEAR_EXTRUSION
	if (dda.isPrintingMove)
	{
	float a, b, limit;
	if (reprap.GetPlatform().GetExtrusionCoefficients(extruder, a, b, limit))
	{
	const float averageExtrusionSpeed = (dda.totalDistance * dv * DDA::stepClockRate)/dda.clocksNeeded;
	stepsPerMm = 1.0 + min<float>((averageExtrusionSpeed a) + (averageExtrusionSpeed * averageExtrusionSpeed * b), limit);
	}
	}
	#endif</float>