Posts made by PeterH1500

@Al_Capwn This may be a too simple explanation for the lack of input shaping effect in your prints, but I can't see an M593 in your config.g. You may have issued this input shaping command through the console, or included it in your gcode (you haven't said, or I've missed it in the thread), but you won't see any input shaping effect on your prints unless you've included M593 somewhere. I would guess that you'd intend
M593 P"EI2" F50
in order to replicate the effect in your accelerometer graphs.

@sonderzug
Ah! I see. Thank you very much.

@sonderzug
I'm sorry that this is off topic, but I noticed from your screen shots that you have Fan RPM showing in your Status panel, with the usual Vin, MCU Temperature and Z-Probe. This doesn't display on my DWC, please could you explain how you have achieved this?

@phaedrux
Stefan's method has the nozzle in close proximity to the extruded material throughout the extrusion, by tracking upwards, which I've interpreted as maintaining a reasonably constant back pressure on the extruder. DC42's code (as far as I've found it in various posts on the forum) doesn't set the Z height and can be used extruding into mid air without any back pressure from printed material. I suppose that, in DC42's gcode I could set the Z height and allow the X movement to spread the filament on the build plate at a constant back pressure. However, I was about to declare that the extrusion lengths from DC42's method, and the weight of the nuggets (they're more blobs than coils!) from Stefan's method yield results that differ from each other in respect of the required A and B coefficients in M592, but now that I've looked at my data again, they're almost identical when expressed in percentage fall off of extrusion length / volume with speed of extrusion. I may be closer to a solution (for PLA at least) than I thought!
As an aside, I tried using G2 in place of the G1 in my gcode based on Stefan's method, to extrude a circle, so that there was an X and Y movement as well as a Z (it gave me helical nuggets!). This seemed to work OK but when I looked more closely, the duration of the extrusion was not what I anticipated for the circle circumference or for the length of the Z move, so I couldn't work out a feed rate to set an accurate volumetric extrusion rate! Have you any idea how RRF handles a simultaneous XY&Z move with extrusion?!
I'm grateful that you've made me think about it again, and more carefully, & re-examine my data.

@phaedrux
Now I'm puzzled...
According to their respective gcode dictionaries, both Marlin & RRF use feed values in mm/min for G1 commands.
In the extrude command generated by Stefan's spreadsheet, there is no specified X or Y move only a Z move from 0.5mm to 10.5mm. My understanding is that the feed rate applies to this Z move and not to the extruder move. The 200mm extrusion takes place over the time taken for the 10mm Z move, which would take 2 minutes at 5mm/min. Extruding the 481mm³ of filament (200mm of 1.75mm diameter) over 2 minutes would therefore take place at 4mm³/s.

I've now uncovered another problem because I'm now trying to calibrate for A and B in M592 for non-linear extrusion. In RRF, non-linear extrusion seems to be only applied in conjunction with an extruding X or Y move, so I now can't measure what effect it has with Stefan's method, which only has a Z move during extrusion! The forum has a method with a gcode attributed to DC42, whereby one measures the length of filament entering the extruder, but this doesn't have the extrusion back pressure that Stefan's method has & the factors generated seem to be unhelpful. This is now off the topic that I started, but I'd be grateful of any suggestions?

@phaedrux
Thanks for responding.
I agree, it's slow, but Stefan's gcode generating spreadsheet, to extrude a nugget at 4mm³/s, generates the following segment:

;####### 4mm3/s
M117 240°C // 4mm3/s
G0 X5 Y5 Z15.5 F6000
G4 S30; Stabalize
G0 Z0.3 ; Drop down
G1 X30 E20 F300 ;Prime
G1 E-3.5 F7500; Retract
G0 X45 F6000 ; Wipe
G0 Z0.5 ; Lift
G1 E3.5 F7500 ; De-Retract
G1 Z10.5 E200 F4.99 ; Extrude
G1 E-3.5 F7500 ; Retract
G0 Z15.5; Lift
G0 X5 Y5 F6000
G92 E0 ; Reset Extruder

It only seems to be a problem for RRF2.03 and later, and not for Marlin, which is what I think he's using.

I've recently been struggling to determine the maximum volumetric flow capability of my hotend using the spreadsheet produced by Stefan of CNC Kitchen. Firstly, Stefan's spreadsheet doesn't work with delta printers (or any other type that has X=0, Y=0 in the centre of the build plate). Secondly, having written my own spreadsheet based on Stefan's, my next problem has been that all the printed "nuggets" were the same size and almost half the weight that they should be with a range of volumetric flows from 6mm³/s to 20mm³/s. Visually, the extruder was spinning at the same rate for each setting.

Looking further, I discovered that, for RRF2.03 and later (I'm on 3.4.0), M203 used to set maximum feed rates, has a default minimum feed rate of 30mm/min. This can be changed with the I parameter (that's capital i) once one knows of its existence (it's clearly shown in the Duet3D GCode dictionary!) At the default feed rate, with Stefan's method, all volumetric flows will be constrained to a minimum of about 24mm³/s, which is optimistic for a V5/V6 hotend (hence my 50% extrusions)! This will apply to all printer types running RRF2.03 and later, not just deltas.

I've now set M203 I6 and the gcode runs my extruder at much more sensible speeds, producing printed nuggets with weights that are where I would expect them to be (and I now know how bad my hotend is!)

Hopefully, this note will help others.

@Veti Thank you. That worked (confirmed by M122).

I'd assumed from the upgrade instructions (Users running RepRapFirmware 3.0 or later should be able to upgrade by uploading file Duet2and3Firmware-3.2.zip. The individual files are also included here in case of difficulty.) that everything needed would either be in the "Duet2and3Firmware-3.2.zip" or in list . The list does not include a copy of "Duet2CombinedIAP.bin" and it doesn't seem to have been retained on my DUET SD card from my previous update to RRF3.0. But, my problem solved in double quick time. Thanks again.

Thank you for your hard work in producing this update.

Unfortunately, I have a problem when attempting to install RRF 3.2 that results in the following error message -

Error: M997: In-application programming binary "Duet2CombinedIAP.bin" not found.

Sure enough, a file named "Duet2CombinedIAP.bin" is not present in the downloaded "Duet2and3Firmware-3.2.zip".

Please could you advise what I should do?

I have a Duet 2 WiFi successfully running RRF3.1.1, & I've updated to DWC3.2. The "Duet2and3Firmware-3.2.zip" successfully uploads & unzips and I'm asked if I wish to install the new firmware.