I got fed up of constantly tweaking the K-Factor calibration for Marlin that you can download, so I wrote a little Macro that can be run from the Duet.

This is also by far the most reliable method for me for determining pressure advance.

https://gist.github.com/bernhardberger/555c4913d492a5213b49b2efa4f0b24e

This should work for Delta printers with the origin (0,0) at center and also cartesian printes with origin at the edge of the bed.

There are no sanity checks (yet), so be careful.

Any suggestions welcome.

Please use the code from the Gist, somehow the forum feature breaks the pasted code (adds {1} instead of newlines..?)

; adjust values to your needs

var temp_nozzle = 195
var temp_bed = 55

var nozzle_diameter = 0.6
var layer_height = 0.1618
var line_width = 0.6

var pa_start = 0
var pa_end = 0.05
var pa_step_size = 0.002

var print_speed_slow_mms = 30
var print_speed_fast_mms = 200
var travel_speed_mms = 300
var travel_speed_z_mms = 300

var line_spacing = 5

var origin_x = 0
var origin_y = 0
var bed_center = true

var line_length_slow = 40
var line_length_fast = 100

var fan_speed = 0.0 ; range 0.0...1.0
var dwell_time_milliseconds = 2000

var prime_nozzle = false
var prime_nozzle_macro = "0:/macros/_Printing/prime_nozzle.g" ;set to "" (empty string) if you don't want to prime the nozzle, otherwise enter the macro location

M291 R"Pressure Advance Calibration" P{"Start Factor: " ^ {var.pa_start} ^ ", End Factor: " ^ {var.pa_end} ^ ", Steps: " ^ {var.pa_step_size}}

; [!!!!!] DO NOT CHANGE VALUES AFTER THIS LINE [!!!!!!]
;------------------------------------------------------
; calculated values start
var print_speed_slow = {var.print_speed_slow_mms * 60}
var print_speed_fast = {var.print_speed_fast_mms * 60}
var travel_speed = {var.travel_speed_mms * 60}
var travel_speed_z = {var.travel_speed_z_mms * 60}




; extrusion calculation taken from slic3r docs (https://manual.slic3r.org/advanced/flow-math)
; A = rectangle + circle = (line_width - layer_height)*layer_height + pi(layer_height/2) * pi(layer_height/2)
var e_per_mm = {(var.line_width - var.layer_height) * var.layer_height + (pi * ((var.layer_height/2) * (var.layer_height/2)))}
; calculated values end


G21 ; Millimeter units
G90 ; Absolute XYZ
M83 ; Relative E
T0 ; Switch to tool 0
M104 S{var.temp_nozzle}
M190 S{var.temp_bed} 

G1 Z5 F{var.travel_speed_z} ; move nozzle down
M109 S{var.temp_nozzle} ; Wait for nozzle temp
;M204 S5000 P5000; Acceleration
G92 E0 ; Reset extruder distance
M106 S{var.fan_speed} ;turn off fan
G1 X0 Y0 F{var.travel_speed} ; move nozzle to center
G1 Z{var.layer_height} F{var.travel_speed_z} ; Move to layer height
M572 D0 S0 ;reset pressure advance

; ==== PRIME NOZZLE START ====
if var.prime_nozzle == true
   if var.prime_nozzle_macro != ""
      M98 P{var.prime_nozzle_macro}
; ==== PRIME NOZZLE END ====

var line_length_total = {2 * var.line_length_slow + var.line_length_fast}

var pos_x_start = 0
var pos_y_start = 0

if var.bed_center == true
   set var.pos_x_start = {-1 * (var.line_length_total / 2)}
   set var.pos_y_start = {-1 * var.line_spacing * ((var.pa_end - var.pa_start) / var.pa_step_size) / 2}


var pos_x_end = {var.pos_x_start + var.line_length_total}
var pos_y_end = {var.pos_y_start + var.line_spacing * ((var.pa_end - var.pa_start) / var.pa_step_size)}

var anchor_y_start = {var.pos_y_start - var.line_spacing}
var anchor_y_end = {var.pos_y_end + var.line_spacing}

var anchor_y_length = {sqrt(0 + (var.anchor_y_end - var.anchor_y_start) * (var.anchor_y_end - var.anchor_y_start))} ; we only move in the y plance



; ==== ANCHOR FRAME START ====

G1 X{var.pos_x_start} Y{var.anchor_y_start} F{var.travel_speed} ; move to start
G11 ; un-retract
G1 X{var.pos_x_start} Y{var.anchor_y_end} E{var.e_per_mm * var.anchor_y_length} F{var.print_speed_slow} ; print line
G1 X{var.pos_x_start + var.line_width} Y{var.anchor_y_end} F{var.travel_speed} ; move to start
G1 X{var.pos_x_start + var.line_width} Y{var.anchor_y_start} E{var.e_per_mm * var.anchor_y_length} F{var.print_speed_slow} ; print line
G10 ; retract

G1 X{var.pos_x_end} Y{var.anchor_y_start} F{var.travel_speed} ; move to start
G11 ; un-retract
G1 X{var.pos_x_end} Y{var.anchor_y_end} E{var.e_per_mm * var.anchor_y_length} F{var.print_speed_slow} ; print line
G1 X{var.pos_x_end - var.line_width} Y{var.anchor_y_end} F{var.travel_speed} ; move to start
G1 X{var.pos_x_end - var.line_width} Y{var.anchor_y_start} E{var.e_per_mm * var.anchor_y_length} F{var.print_speed_slow} ; print line
G10 ; retract

; ==== ANCHOR FRAME END ====

G4 P{var.dwell_time_milliseconds} ; Pause (dwell) for specified milliseconds

; ==== TEST PATTERN START (loop) ====

var pa_current = {var.pa_start}
var pos_y_current = {var.pos_y_start}

while {var.pa_current <= var.pa_end}
	G1 X{var.pos_x_start} Y{var.pos_y_current} F{var.travel_speed} ; move to start
	M118 S"M572 D0 S " ^ {var.pa_current} L1
	M572 D0 S{var.pa_current} ; set PA factor

	G11 ; un-retract
	G1 X{var.pos_x_start + var.line_length_slow} Y{var.pos_y_current} E{var.e_per_mm * var.line_length_slow} F{var.print_speed_slow} ; print slow line
	G1 X{var.pos_x_start + var.line_length_slow + var.line_length_fast} Y{var.pos_y_current} E{var.e_per_mm * var.line_length_fast} F{var.print_speed_fast} ; print fast line
	G1 X{var.pos_x_end} Y{var.pos_y_current} E{var.e_per_mm * var.line_length_slow} F{var.print_speed_slow} ; print slow line
	G10 ; retract
	
	set var.pa_current = {var.pa_current + var.pa_step_size}
	set var.pos_y_current = {var.pos_y_current + var.line_spacing}

; ==== TEST PATTERN END ====

M0 ;finish

I'm already looking forward to 3.5 Been a happy 3.4 early adopter for quite some time now and Input Shaping brings so much to the table. Exciting times! Hopefully the IS Plugin gets to the point of comfort and ease-of-use as in Klipper!

Hopefully the trend to better motion planning continues, keep up the good work!

I just created a pull request..
https://github.com/chrishamm/DuetWebControl/pull/226

Based on PrismJS. The only one I could find that reliably highlights gcode. Also is pretty lightweight.

Needs some testing though and I also propose a UI setting to turn it on/off, but I don't have the means to translate it to all the supported languages.

Doesn't do much besides syntax highlighting based on file extensions, but at least to me it's already a great help to have comments greyed out and commands/params highlighted..

If there's a full tree of (maintained) RRF gcodes acailable then maybe CodeMirror could be an option for a more polished WebIDE.

I also think a slight rework of the FileEditor would be helpful (custom Route instead of the Dialog so a page refresh or the back button doesn't break the Dialog), but that's a topic for another day..

If there's interest I'm open to do some slight refactoring of that feature to make it work.

bernhardberger opened this pull request in chrishamm/DuetWebControl

closed Feature/prism #226

Edit:

A few thoughts later: I could however just mount a 3.5" HDMI screen and drive it off a Raspberry/cheap Android Device and adjust the DWC for that resolution.. I'm a webdev after all..

Edit2:

Actually the DWC looks like it meets exactly my competence.. Vue.js + Vuetify.

@bot said in XY Acceleration / Speed / Resolution on a Delta:

https://reprap.org/mediawiki/images/b/b5/Rostock_Delta_Kinematics_3.pdf

It's been a while, but thanks! That's exactly what I was looking for.

Let's see if I got this right:

1. if you care about XY accuracy don't print in the center but along the long sides. For Z go for the middle.

2. If you need equal accuracy on 3 parts either print them one by one or rotate each them by 120 degrees and place them at opposite towers.

Did I get that right?

Now that I know the expected max errors for different parts of the bed, is there something similar regarding resolution?

@jay_s_uk I have the same on a Duet Wifi (Standalone), but it's been like that for quite a while.

But in my case it's like 30% or sometimes even more progresss. The times and estimates are correct, but it completely screws with the percentage.

I'm trying to get my head around why 2 motors per axis isn't a thing (ignore the fact for the need of more stepper drivers and higher cost).

With all the nitpicking of low interia, high torque motors I'm wondering what the downside of using 2 motors per axis would be?

1. Let's say on a delta tower: what's the downside to mounting a motor on top and on bottom of the tower? Aren't they synchronized 'per default' due to the belt?

2. Imagine a Makerbot style cartesian (on quality linear rails instead of rods and a sturdy frame). What's keeping me from just mounting 2 motors on Y and dragging around another motor directly on the X axis? Shouldn't the sturdyness of the frame and the precision of the rails kind of equalize the added weight and make the racking force insignificant? If you synchronize the Y motors via the rod shouldn't that also erase any concerns about the gantry becoming skewed?

The first one on the Delta is purely out of curiosity because of the achievable speeds.

The second one however is what currently keeps me up at night.. I'm not too much into CoreXY as I have my delta for real speedy stuff.
However I'd like another (400x400ish) printer that can drag around a direct drive extruder, preferrably with the option for IDEX later on (print + support material).

I studied the Annex Engineering K1/K2 a bit that basically is a linear rail cross gantry. However - why would I drag a 350g linear rail around when I could just drag a 300g (or less) Nema 17 around?

I hope someone can explain to me what I'm missing here..

@nikscha absolutely would love an SE revision with an accelerometer built in.

@fred-y said in New FLSUN Super Racer, ideas for upgrades?:

@oliof The Smart Effector can work with Klipper, I installed this firmware on my Predator for a few months to test it but I rolled back to RRF during be beta of 3.4 for Input Shaping.

I don't think it's possible to adjust the sensibility.

That's been solved by now. It's merged in the latest Klipper.

@Anon1337 my concern would be the rigidity of the PCB tbh. It's just borderline fine on the default size.l and I'm thinking of reinforcing it because it DOES flex on my delta (I can twist it slightly by hand).

Which direction are the pins? Left/Right or Top/Bottom if you view the connector from the bottom and the connector pin is at the top?

How do I get the pin out of this mess?

@adrian52 said in Orbiter 2 extruder mounting for Smart effector with Magball arms:

@fred-y Its 1.5mm.
You do need to be able to rotate your hot end - would be difficult with a v6 where the heater block really has to be aligned with the part cooling fan

It actually depends. The earlier versions that shipped with the metal nut had a fine pitch..

@fred-y though about exactly that multiple times. Problem is that it's pointless with 55mm magball spacing as you need some real nasty vertical offset and tilt to jot collide with the arms which then puts a lot of direct force onto the hotend itself.

@fred-y I don't have a solution that I'm happy to share tbh (80mm rod spacing adapter + a pain in the butt mount for the LGX lite).

That LGX Lite is a pain to mate to the smart effector and any adapter I had thought of. The pain of a need to screw them from the bottom is real.

BUT: on the SR I suspect you could probably get away with this without losing print volume:
https://www.thingiverse.com/thing:5255358

It doesn't print really well though and needs supports.

@ignacmc the needle bearings suggested here are super thin though.

But yes, with the suggested tension of Gates for their belts in linear positioning applications we're at the upper end of what Nema 17 bearings usually are rated for. On my Moon's it just barely within "extended" spec (they're in the rated "can be up to this load, but expect reduced bearing life).

Haven't looked up the Wantai specs though. I don't think that they'll be a problem in our application. At least not for the lifetime of the printer unless it's maybe running 24/7 in a farm.

The thing with pillow blocks / bracings is: they need to be accurate or they will introduce crooked sideload themselves on the motor bearings.

Has anyone been able to find the Wantai with a D-Shaft and connectors? That's the primary reason why I have been to lazy to switch back to them.. I know they exist as they can be ordered to spec that way, but haven't seen any retailer carrying them

@ignacmc I'd happily take the F360 files

I've settled on a solution for me now. Still undecided if I want to go back to the flying orbiter v2 though as the input shaping graphs don't look too bad, but compared to the flying extruder don't look too good either.. and I'm kinda into getting prints done as fast as I can:

Direct Drive Orbiter v2 on 80mm adapter:

Flying Orbiter v2 on stock 55mm Smart Effector:

Flying Orbiter v2 on 80mm Adapter for reference what the 80mm adapter alone does to my input shaper graph:

//Edit: the graphs only tell half the truth. I can't even get close to max suggested accelerations on the direct drive without having motion artifacts (no ringing, but "smoothing" from hell). Need to go down to about 2.5k to have comparable print quality to the flying extruder on 8.5k acceleration.

I'll be reverting back and just get a second printer for printing flexibles.

@ignacmc don't forget to share you enclosure please Still trying to get away from the parabolic resonance hell the CarstenD enclosure gives me (it also is too narrow for my cooling solution).

I know Chris W. in the Advanced Predator group has designed a flat enclosure with more spacing from the same panel sizes that Carsten used, but haven't gotten around to print the parts yet..

Thank you for the quick response! Sounds like ~50-60C would be the reasonable target then.