@crpalmer

Whilst I agree that preheat at a particular time would ideally be done by the firmware, Pending any potential changes It should be possible to write a M104.1.g macro - which collects the parameters, stores the required number of seconds plus the current state.upTime - then either using daemon.g or the 2nd motion system to asynchronously wait the right amount of time, minus enough time to kick off the preheat.

In my version of this I'm just doing a simple x degrees per second formula - but it probably wouldn't be that hard to build some sort of table of heat up times to derive the correct time to kick off the preheat.

@sbNielsen You're missing semicolons in front of some of the comment lines it should look like this...

;homex.g ;called to home the X axis ;generated by RepRapFirmware Configuration Tool v3.3.16 on Sat Jul 01 2023 14:29:49 GMT+0200 (CEST) G91 ; relative positioning G1 H2 Z5 F6000 ; lift Z relative to current position G1 H1 X-2015 F4500 ; move quickly to X axis endstop and stop there (first pass) G1 H2 X5 F6000 ; go back a few mm G1 H1 X-1015 F360 ; move slowly to X axis endstop once more (second pass) G1 H2 X5 F6000 ; go back a few mm G1 H2 Z-5 F6000 ; lower Z again G90 ; absolute positioning

Note the ";" in front of some of the lines.

If your homey.g and homez.g files are not generating errors, compare them against your homex.g file and check those comment lines.

@samlevy0515 That's rare. Does this insight come from chatGPT?

@Tech_Sam03 that plot suggests that the A term was too low or the maximum motor current too low.

I don't suppose you could update to 3.5.4 to test, or the recently released 3.6 release candidate?

@3DPMicro no I don't have any feel for the point at which resolution affects print quality. It will obviously depend on the nozzle size. With a 0.4mm nozzle the extrusion width is typically 0.5 or 0.6mm, so my guess is that 0.02mm may be sufficient XY resolution on a Cartesian or CoreXY printer.

Z resolution may be more critical because it could lead to Z banding. A typical leadscrew-driven Z axis probably has more than enough resolution; nevertheless it's probably wise to choose the layer height to be an exact number of Z microsteps.

On a delta, resolution is more critical because the nature of motion on a delta means that you can get a moire pattern on a flat side of a print. I did some tests years ago and found that under magnification I could see the difference between 100 and 200 microsteps/mm, but for practical purposes the moire was insignificant in both cases.

@sebastianwac said in Homing X triggers before reaching endstop:

I used M84 E0 at start of homing codes and it did the job. Now it is working correctly every time.

That confirms that the issue was caused by interference between the extruder motor cable and the endstop cable. You said they are routed separately, but do they run parallel and close together for an appreciable distance?

Using shielded cable for endstop wires offers protection against capacitively coupled interference, but not against inductively coupled interference. You can defend against inductively coupled interference by using twisted pair cable. Preferably, the signal and ground wires of the endstop switch should be connected to the Duet using a single twisted pair; and the stepper motor should be connected to the Duet using two twisted pairs, each motor phase using one pair.

@Phaedrux

While there is nothing wrong with doing that it is not needed, in my experience.

Here is the start code from Cura 5.10.0:

T0 M104 S0 M109 S0 M98 P"print_begin.g" M82 ;absolute extrusion mode M82 ;absolute extrusion mode M98 P"print_extrude_begin.g" M83 ;relative extrusion mode M83 ;relative extrusion mode G1 F1500 E-6.5 ;LAYER_COUNT:259 ;LAYER:0 M107

Note that the M104 and M109 are harmless as the call to user code follows them and there is no unwanted code that follows the call to the user code.

Here is the start code from Prusa 2.9.2:

M98 P"print_begin.g" G21 ; set units to millimeters G90 ; use absolute coordinates M83 ; use relative distances for extrusion M98 P"print_filament_begin.g" M107

Again there is no unwanted code that follows the calls to user code.

Not big deal, just thought I would mention it.

Frederick

@dc42 glad I asked. Would love to see the LaPlace transfer function because I am thinking about this wrong. I ended up with MZV @50 Hz with 0.05 because my X and Y have separate peaks and I can kill both.

@ash100 I guess you haven't run PID tuning since you were running firmware 3.4.x. I suggest you upgrade to either 3.5.4 or 3.6.0-rc.3 and then run PID tuning again. It has changed a lot since 3.4.x so read https://docs.duet3d.com/en/User_manual/Tuning/Duet_3_1HCL_tuning#manual-tuning for instructions.

@tcamguil thanks for confirming this.

@Macgyver see https://docs.duet3d.com/en/User_manual/Reference/Gcode_meta_commands#conditional-construct

Ian

@handyandy I think the Teaching Tech calibration guide is pretty good: https://teachingtechyt.github.io/calibration.html
Also the 'Califlower' yields good results, though at a cost: https://vector3d.shop/products/califlower-calibration-tool-mk2

Ian