New beta firmware 1.20.1RC2 and DuetWiFiServer 1.20+1

dc42

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

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.

Captain_sq

I'm not very familiar with C++ but should't a, b and limit be pass by reference rather than pass by value?

dc42

Passing them by value is best here because their values are read but not changed.

Captain_sq

@dc42:

Passing them by value is best here because their values are read but not changed.

Yes, I see, but are the variables initialized right here? My guess is that their values is supposed to be set in these two statements.
a, b and limit are passed by value here and not by reference. My guess is that the GetExtrusionCoefficients() method expects a pointer
to be able to write the values into the variables, like this:

    float a, b, limit;
    if (reprap.GetPlatform().GetExtrusionCoefficients(extruder, &a, &b, &limit))

dc42

I'm sorry, I forgot what that bit of code looked like. The a, b and limit parameters of function GetExtrusionCoefficients are already passed by reference, because they are declared as reference parameters in the declaration of GetExtrusionCoefficients. This is a C++ feature not available in C.

burtoogle

Hi David, as I said, I'm not familiar with the RRF code so these may be dumb questions but in this code snippet, why are you multiplying totalDistance by dv and not fabsf(dv) and why do that multiply at all? Isn't dv a distance also?

const float averageExtrusionSpeed = (dda.totalDistance * dv * DDA::stepClockRate)/dda.clocksNeeded;

dc42

Variable dv is the proportion of totalDistance that applies to the current drive, that's why totalDistance is multiplied by it. It shouldn't matter whether we multiply by dv or fabsf(dv) because nonlinear extrusion is only applied to extruding moves, for which dv is positive.

burtoogle

Understood - thanks.

Captain_sq

@dc42
May I ask what development IDE you are using, Arduino or Atmel Studio (or other)?

dc42

@Captain_sq:

@dc42
May I ask what development IDE you are using, Arduino or Atmel Studio (or other)?

We use Eclipse, see the BuildInstructions.md file in github.

Arduino is great for getting novices into programming microcontrollers, but truly awful for large scale firmware development. Atmel Studio is OK and I use it for the IR sensor and filament sensor firmware, but it offends those who think that only open source tools should be used or who want to develop under Linux.

Guyaros

I use VisualMicro - Its an add-on to Visual Studio that enables to program and upload code for Arduino.
I found it a very good environment for programming.

http://www.visualmicro.com/

Captain_sq

I'm familiar with it. I just can't come to terms with Atmel Studio. Professionally I use a derivative of Eclipse; Atollic True Studio which is hard to beat feature-wise.

burtoogle

Hi David, I think I have discovered why I am seeing underextrusion when I use M592 on my Kossel XL fitted with a flex3drive extruder. With A and B set to 0, the x/y motion and the extruder activity start/stop at the same time (as close as I can tell by eye/ear). When I set non-zero values (e.g A=0.015 and B=0.0012) I notice that the extruder stops before the x/y movement stops. The faster the feedrate, the more obvious the gap becomes.

Here's the relevant config lines:

[[language]]
M350 I1 X16 Y16 Z16 E16			; all axes use x16 microstepping with interpolation (steps/mm will get adjusted automatically)
M92 X160 Y160 Z160			; Set axis steps/mm (20 tooth pulleys, 0.9deg/step motors)
M906 X1000 Y1000 Z1000 E1000 I60	; Set motor currents (mA)
M201 X3000 Y3000 Z3000 E400		; Accelerations (mm/s^2)
M203 X18000 Y18000 Z18000 E1200		; Maximum speeds (mm/min)
M566 X300 Y300 Z300 E10			; Maximum instant speed changes

M92 E4320				; Set extruder steps per mm (flex3drive)

garyd9

There was a report earlier about DWC "layer X of Y" showing the wrong numbers for dual extrusion prints. I have a similar issue with the start (only) of a single layer print. At the end of this message, I'll include a link to the gcode file being referenced, but let me describe what is going on:

When the print starts (waiting for tools to heat), the DWC shows layer 0 of 111.

When the print moves to the part of the gcode that displays a message "Purging and Wiping T1", the DWC shows layer 2 of 111. This part of my startup code does two Z movements before moving on to the real print.

When the print moves on the build plate and actually starts printing the first layer (identified in the gcode with the comment "; layer 1, Z = 0.162"), DWC still shows "layer 2 of 111" and the head position Z is correctly noted as 0.16

When the print moves to the next layer (identified in the gcode with the comment "; layer 2, Z = 0.342"), DWC still shows "layer 2 of 111", and the head position Z is correctly noted as 0.34

Finally, when the print moves to the next layer (identified in the gcode with the comment "; layer 3, Z = 0.522"), DWC finally catches up showing "layer 3 of 111."

My WAG is that my startup gcode that does the "purge and wipe" is confusing the duet because of multiple Z moves up and down. However, if that's the case, I don't understand how it "catches up" at layer 3. If my guess is correct, is there something I can include in my gcode to let the duet know that "here is where the actual print starts, so reset the layer to 1"?

gcode file: https://drive.google.com/file/d/1MWXt1cxYU0ZMMG2RMMgH25-8_ynrjyHl/view?usp=sharing

Thanks
Gary

dc42

@burtoogle:

Hi David, I think I have discovered why I am seeing underextrusion when I use M592 on my Kossel XL fitted with a flex3drive extruder. With A and B set to 0, the x/y motion and the extruder activity start/stop at the same time (as close as I can tell by eye/ear). When I set non-zero values (e.g A=0.015 and B=0.0012) I notice that the extruder stops before the x/y movement stops. The faster the feedrate, the more obvious the gap becomes.

Here's the relevant config lines:
[[language]]
M350 I1 X16 Y16 Z16 E16			; all axes use x16 microstepping with interpolation (steps/mm will get adjusted automatically)
M92 X160 Y160 Z160			; Set axis steps/mm (20 tooth pulleys, 0.9deg/step motors)
M906 X1000 Y1000 Z1000 E1000 I60	; Set motor currents (mA)
M201 X3000 Y3000 Z3000 E400		; Accelerations (mm/s^2)
M203 X18000 Y18000 Z18000 E1200		; Maximum speeds (mm/min)
M566 X300 Y300 Z300 E10			; Maximum instant speed changes

M92 E4320				; Set extruder steps per mm (flex3drive)

Thanks, I look into it.

dc42

I found the problem. I'll get a new 1.20.1RC out soon with a fix.

burtoogle

A new 1.20.1RC would be most welcome!

burtoogle

Any chance of a new RC? I am keen to try out the fixed M592.

dc42

I am working through bug reports at the moment, trying to get some fixes implemented before I release it. However, there is a pre-release Duet Wifi build at https://www.dropbox.com/s/8pvnkzaf0hqxf7x/DuetWiFiFirmware.bin?dl=0.