@mrehorstdmd Thank you for your answer.

I made another test at the same speed with a triple-layer perimeter circular pattern.
My setup is a Revo Six hot end with a Titan extruder driven by a slightly underpowered Nema motor than the one suggested by E3D for Titan.

The pulleys and belts are okay, and the hot end attachment seems rock solid. My concern lies with the mini V wheels or the wheel bearings, which could deteriorate over time. I am searching for a reliable European seller to buy good-quality V wheels.

This is the result of the print at 130 mm/s. During the print, I could hear a rhythmic noise pattern coming from the Y-axis. This is the reason I am considering a wheel problem.

Immagine WhatsApp 2024-01-25 ore 08.40.18_8390771b.jpg

Is TAMV still working?

this is very odd

i flashed firmware 3.4.6 and dwc 3.4.6 and the www files that match

now it homes perfect

did not touch the config

@DocTrucker To elaborate a bit more, in Prusa Slicer, in the custom code section for filaments I have just one macro call - e.g M98 P"prePrintAbs". That macro sets things like retraction, pressure advance, speeds, etc and it resides in the .sys folder. So each machine has it's own .sys folder and therefore it's own "prePrintAbs" macro. So any gcode file becomes machine agnostic and by editing the single macro call at the beginning of the file it becomes filament agnostic too.

@rex_sl From the release notes, the M593 L factor is described as:

... the minimum fraction of the original acceleration or feed rate to which the acceleration or feed rate may be reduced in order to apply input shaping. The default is 0.25 and the acceptable range is 0.01 to 1.0.

ie if the commanded feedrate is F1000, L0.25 would allow the feedrate to reduce to F250, while L0.75 would only allow it to reduce to F750. So the least amount of reduction of acceleration or feed rate is from the highest L value.

I have updated the M593 Gcode dictionary entry to show this has changed in RRF 3.5.0-rc.2.

Ian

@dc42 when I when to use the printer again, I saw the message "Input Shaping is not configured. Record a new Motion Profile to set it up" seems I lost it, it happened before and I thought I deleted it by accident, but not this time. printer was off for awhile and don't see how to recall the last motion profile. I already removed the input shaping sensor, but if I do this again what is the proper way to save and make it stay?

@dc42 Hello ! I found the place in gcode.cpp where i could add a G11 or a G1 E10 at the end of ressurect.g . Not sure I want to go down the path of compiling a custom firmware though, but:
Would this work ? : adding

// Now unretract filament buf.catf("G11");

after

// Now move down to the correct Z height buf.catf("\nG0 F6000 Z%.3f\n", (double)pauseRestorePoint.moveCoords[Z_AXIS]);

in

if (ok) { // Build the commands to restore the head position. These assume that we are working in mm. // Start with a vertical move to 2mm above the final Z position buf.printf("G0 F6000 Z%.3f\n", (double)(pauseRestorePoint.moveCoords[Z_AXIS] + 2.0)); // Now set all the other axes buf.cat("G0 F6000"); for (size_t axis = 0; axis < numVisibleAxes; ++axis) { if (axis != Z_AXIS) { buf.catf(" %c%.3f", axisLetters[axis], (double)pauseRestorePoint.moveCoords[axis]); } } // Now move down to the correct Z height buf.catf("\nG0 F6000 Z%.3f\n", (double)pauseRestorePoint.moveCoords[Z_AXIS]); // Set the feed rate buf.catf("G1 F%.1f", (double)InverseConvertSpeedToMmPerMin(pauseRestorePoint.feedRate));

@Manuel207 said in Printing ovals instead of circles:

@deckingman I tested a 400mm move and it is nearly perfect (maybe 0,2-0,3mm if even measurable?).

I also printed the same part with the second tool and voila perfect circles. So you are on the right path. It has probably something to do with the external driver. I am going to test different microstep settings and currents on the external driver? Do you have other suggestions what it could cause?

Well at least that's narrowed it down to the external driver. Sorry I have zero experience of external drivers so can't offer any other advice. Maybe someone more knowledgable than me about these things will step in.

@deckingman I'm going to close this post and start a new one, I think I've mischaracterized some things and would like a fresh start on the convo

@Tobi_innit your max speeds in M203 are 100mm/s so you won't print any faster than that

Are you going to print airplane wings with this LW PLA? If yes, even and stable extrusion factor is important, I.e. you should look into vase mode. Recent Prusa Slicer has updated their vase mode to match the spiralize outer contour algorithm of Cura which should help with keeping extrusion more equal... and as always, printing slower will also help.

You could still use pause at height plugin and find and replace the M226 with notepad++

Curious if it has a custom gcode option under method dropdown?

for the life of me, I cannot understand what is going on here.

After having a look at the thread I posted, I got my printer homing perfectly every single time. I was so happy. here is my homey.g file:

; homey.g ; called to home the Y axis M913 Y70 ; drop motor current to 70% G4 P100 ; wait 100ms M915 Y S-3 R0 F0 ; set Y sensitivity, do nothing when stall, unfiltered G4 P100 ; wait 100ms M400 ; wait for current moves to finish G91 ; set relative movements G1 H2 Z5 F1200 ; lift Z ; tune drivers ; relative positioning G1 H2 Y0.4 F3000 ; power up motors to ensure they are not stalled G4 P100 ; wait 100ms M400 ; wait for current moves to finish ; home Y G1 H1 Y5 F1200 ; move slowly away G1 H1 Y-300 F6000 ; move to Y axis endstop and stop there (first pass) ; eren 3600 G1 Y5 F1200 ; go back a few mm G1 H1 Y-10 F6000 ; move to Y axis endstop once more (second pass) ; eren 3000 G1 Y10 F1200 ; go back a few mm M400 ; wait for current moves to finish M913 Y100 ; restore motor current to 100% G4 P100 ; wait 100ms G1 H2 Z-5 F1200 ; reset Z G90 ; reset absolute movements

Now, I came yesterday from my winter break. Today I wanted to try a new method of steps calibration I though out. I moved the printer over the bench so I can have better access to it (the calibration involves having a pen attached to the extruder, a piece of paper and so on).

I start up the printer and I home it. The Y homing starts failing miserably again in the same fashion it did before.

I cannot understand how come it worked perfectly before, I change absolutely nothing at all and starts failing again. It did work perfectly. Nice homing, nice prints, reliable... and all of the sudden it stopped working again.

Any insights?

@curieos said in M911, Print not Resuming After Voltage Threshold is Reached:

That is highly unlikely, the buffer provides enough power for the M911 codes to be run to completion

Sorry, I forgot:

this is supposed to be a large, industrial machine that offers power loss recovery as a selling point.

As a Pro, you sure have monitored the 24V and 3.3V rails’ behaviour on the event of sudden power loss - a cheapo two-channel scope is all you need. What I know for sure is that the resume.g file is generated by RRF on an undervoltage event as long as the Duet’s electronics have sufficient power to stay alive long enough. And I can assure you: 4 secs are long enough.

OTOH, your 3-4 seconds buffer supplies 22V, so it is meant to feed all steppers and heaters (excluding the bed) as well? These devices are operated by strong pulses - a voltage plot over these 3-4 secs might be interesting 😊

@Arminas theres no limitation regarding duex as its basically part of the mainboard

Can you give us some more information?
What kind of heater is it? Wattage?
What is the input voltage from your power supply?
What were the tuned results?
Did you use M500 to save the PID tuning and put M501 in config.g to load the saved results at startup?
What does the temperature graph look like?
Is it a consistent 10c offset from the requested temperature at all set temps?
What firmware version? What Duet board?
Please share your config.g and the results of sending M122 and M98 P"config.g" in the gcode console.

@Thorodinsson

What slicer are you using?

What are the settings for the first layer (height, speed, etc.)?

Frederick

@Sindarius sure!
heightmap.csv